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

[Samuel Thibault <samuel.thibault@ens-lyon.org>]

Hello,

Chris Hennick, le Sun 13 Apr 2014 19:38:32 -0400, a écrit :
> the only differences that leaves unadjusted-for are the APU's heat
> conduction to and from the CPU

You mean actually physical heat?  We don't really take that into account
in StarPU.  What we can take into account with some modifications,
however, is the power consumption: I guess using the integrated GPU is
less expensive than using the discrete GPU

> Can StarPU actually impact whether or not tradeoffs are made to avoid 
> partition
> camping while running a given OpenCL codelet,

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.

> How can I find out how many memory controllers my R7 240 card has, and
> therefore how susceptible it is to partition camping anyway?

I don't know :)

> And how much
> difference would it make if I could upgrade to an A10-7850K to get full HSA 
> (as
> well as the extra cores to ensure that STARPU_OPENCL_ON_CPUS would be a
> realistic option)?

> Correction: Apparently there is cache snooping, through the Fusion Compute
> Link, but I don't see what good this does when the CPU and GPU can't address
> any of the same physical memory (I have to set aside a chosen amount of RAM 
> for
> the integrated GPU in BIOS, and Linux sees that much less RAM). Can anyone
> clarify this, and/or comment on how hard it would be to make StarPU aware of
> the FCL?

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.

Now, to get benefit from common memory, in principle it is just a
matter of telling StarPU that the opencl device uses just the main RAM
memory node, and not its own memory node.  I don't know the details
about how that translates into OpenCL calls, perhaps something like
a clCreateBuffer with CL_MEM_USE_HOST_PTR.  That would probably mean
having to deal with both the void* host pointer, and the cl_mem OpenCL
object.  But perhaps one could only keep the void* host pointer in the
StarPU core, and use clCreateBuffer just before executing the kernel
to turn the void* host pointer into a cl_mem object to be given to the
kernel.

The last question I'm wondering is whether OpenCL gives any clue whether
memory is shared or not...

Samuel