[Pkg-opencl-devel] pocl ITP, and opencl-icd selection

[Rebecca N. Palmer]

==pocl ITP (#676504)==
(OpenCL on the CPU, i.e. slower but works everywhere, including the 
buildds (for test suites))

Any comments on my work so far?
I am thinking of dropping the symbols files completely, as they are 
useless when the package is used via the ICD.

==Defaulting to installing all ICDs?==

Currently, OpenCL-using applications Depend: on opencl-icd, which means 
"whichever ICD apt happens to pick, often not one that actually works on 
that hardware".
I suggested earlier [0] that we solve this problem (at least for the 
~40% of users whose hardware has a free ICD [1]) by making it instead 
mean "all ICDs unless the user explicitly chooses one", similar to the 
video drivers:

#application/library that needs OpenCL
#do *not* depend on any specific ICD (i.e. #739176 is not a bug), as 
doing so prevents automatic installation of the others
python-pyopencl Depends: libopencl1, opencl-icd

#new metapackage, and also still the virtual package
#list the CPU implementation first, so --no-install-recommends picks it 
opencl-icd Depends: pocl-opencl-icd | beignet | mesa-opencl-icd
Recommends: pocl-opencl-icd, beignet, mesa-opencl-icd

#ICDs keep the Provides, so if the user does explicitly install one, the 
system won't waste space on installing the others
pocl-opencl-icd Provides: opencl-icd
beignet Provides: opencl-icd
mesa-opencl-icd Provides: opencl-icd
nvidia-opencl-icd Provides: opencl-icd

For this to work, both ICDs and applications need to properly handle the 
case of an ICD being installed without the corresponding hardware:
-ICDs must report CL_DEVICE_NOT_FOUND, not crash/hang/exit.
-Applications must then try the next platform, not assume that OpenCL 
isn't available at all.  They should preferably look for GPUs before 
CPUs, but as the default platform order appears to be alphabetical 
(placing pocl last), with the current free ICDs the GPU happens to be first.

Currently, one ICD (beignet #745363) and roughly half the applications 
(pyopencl #745456, vxl #745535, erlang-cl, bfgminer, clinfo, hwloc, oce, 
gegl) do not do this, but they all appear to be easy to fix; I have 
filed patches for the first 3, and can do so for the others if we agree 
that this is a good idea.

As it is likely that OpenCL is also being used with applications 
obtained outside the Debian archive (which we hence can't fix), should 
we patch whatever decides the platform order (ocl-icd-libopencl1?) to 
put the working-on-this-hardware platform first, or is it reasonable to 
say "if you're doing that, choose the right ICD manually"?

Is this the appropriate place to be discussing this, or should it go to 
a wider audience such as debian-devel?

[0] 
http://lists.alioth.debian.org/pipermail/pkg-opencl-devel/Week-of-Mon-20140203/000076.html
[1] Popcon installs: nvidia-opencl-icd (non-free) 2502, amd-opencl-icd 
(non-free but replaceable by mesa-opencl-icd+pocl-opencl-icd) 1570, 
amd-opencl-icd-legacy (non-free) 197, beignet 137, mesa-opencl-icd 38