Re: [Starpu-devel] APU optimization: is partition camping enough of a difference?

[Chris Hennick <christopherhe@trentu.ca>]

On 14 April 2014 05:01, Samuel Thibault <samuel.thibault@ens-lyon.org> wrote:

I'm not sure what idea you mean.  StarPU already measures the kernel
execution time independently, so it will notice that some GPU has less
troubles, through execution time.  Another interesting thing is that you
can provide StarPU with several variants of the kernel, with or without
code to avoid partition camping, and on each GPU the StarPU scheduler
will use the variant which performs best.

That answers my question -- if StarPU is unaware of partition camping, then this is indeed an implementation detail of the codelet.

I don't know the details there, but I don't think setting aside RAM for

the GPU necessarily means the CPU can not directly address it by just
mapping it.  I guess it's more a way to get things working with OSes
which are not aware of integrated GPUs.

I've just tested setting the UMA framebuffer to 32MB (the minimum my BIOS allows). When I do, fgl_glxgears takes up only slightly more memory according to top, but the frame rate and CPU usage are lower by about half. I suspect that the APU can actually access all of main memory, but that accesses to the framebuffer are faster because they bypass the Linux kernel's address translation (since the BIOS excludes them from what the kernel sees). The lower CPU usage would probably be due to the CPU having to wait on RAM accesses (possibly including the addressing table itself?) instead of calling OpenGL functions (which would explain why the CPU usage seems to be linear with the frame rate). Is this plausible?