[Pkg-opencl-devel] pocl ITP, and opencl-icd selection
Rebecca N. Palmer
r.palmer at bham.ac.uk
Wed Apr 23 07:58:23 UTC 2014
==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
More information about the Pkg-opencl-devel
mailing list