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

[Tomasz Rybak]

I've subscribed to the mailing list; I'm not sure why I was not
getting mails from it while being member of Alioth team.

BTW - I'm looking for sponsor for PyOpenCL. I've prepared
new version, ready to be uploaded to main (not contrib), so it needs
to go through NEW. My usual sponsors do not have time, so any
DD ready to look at PyOpenCL?

Dnia 2014-04-23, śro o godzinie 08:58 +0100, Rebecca N. Palmer pisze:
> ==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:
> 

I'm not sure whether I understand your proposal.
Are those mutually excluding options from which we should choose one,
or are those steps to make while changing all packages related
to OpenCL?

> #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

I've added dependency on specific libopencl1
(ocl-icd-libopencl1) to ensure that free library, and the one
that works (unlike nvidia-libopencl1) gets installed.

As for ICD dependency - there is a risk that wrong ICD gets
picked, and e.g. causes installation of full NVIDIA stack on AMD
machine, so your initiative is important here.

> 
> #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

So this new package should both depend on and recommend all ICDs?

> 
> #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?

I'd keep discussion here (debian-devel already has to much traffic ;-)
but you might send email to debian-devel pointing interested people
to this discussion.

Best regards.

-- 
Tomasz Rybak  GPG/PGP key ID: 2AD5 9860
Fingerprint A481 824E 7DD3 9C0E C40A  488E C654 FB33 2AD5 9860
http://member.acm.org/~tomaszrybak

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/pkg-opencl-devel/attachments/20140429/3b32331a/attachment.sig>