[Pkg-opencl-devel] opencl-icd selection

[Giuseppe Bilotta]

On Fri, Nov 14, 2014 at 1:21 PM, Vincent Danjean <vdanjean.ml at free.fr> wrote:
> On 14/11/2014 12:41, Giuseppe Bilotta wrote:
>> I'll try to find the time to work on a proof of concept patch for the
>> proposal, but I think the discussion for that would best be done on
>> the ocl-icd ML
>
>   I'm a bit short of time. I just answer to this point :
>
>   There is not really activities on the ocl-icd ML and very few
> subscribers. It is probably better to keep the discussion here
> (where it began). Both ocl-icd authors (Brice and me) are also
> subscribed here and there will be more eyes to look for the
> proposals.

Ok, sure.

So, my plan is to change ocl-icd so that when it loading platforms
from ICDs, it doesn't just append them to the list, but rather does an
insertion sort (I think in this context it's probably the
fastest/easiest to implement), with a sort based on (at least) the
number of GPU and CPU devices it exposes. (Should we also consider
ACCELERATOR and CUSTOM devices? If so, how?). Of course, this means
that the platform_icd structure has to be extended to include this
additional data, and the data should be  queried during ICD load.

I've been going over the code and I notice that there is a field in
the vendor_icd structure that stores the index of the first
platform_icd for each vendor. This seems to be part of something that
assumed all platforms of a vendor ICD were consecutive in the list of
platforms, but I can't find where in the code this property is used.
Is this a leftover from a previous ICD loading algorithm, or is it
still relevant? If it's a leftover, I would like to remove it, since
platform sorting by number of devices might break any assumption on
platforms from the same vendor being consecutive in the global array.
Or should we still keep them together? This would make sorting quite
more complicated.

(Of course, this is largely idle speculation, I'm not aware of any
existing vendor ICD that exposes more than one platform. But still, we
should probably design for the possibility.)

-- 
Giuseppe "Oblomov" Bilotta