[Pkg-opencl-devel] opencl-icd virtual package(s)?

[Rebecca N. Palmer]

(beignet's FTBFS is #974792, my previous attempts to fix it are in 
Salsa, and I was planning to remove it and accept that older hardware 
would only be able to use CPU (pocl) OpenCL.  Please use that bug for 
further discussion of that.)

I'd leave the loader packages alone, i.e. ocl-icd-libopencl1 stays the 
default, and the libopencl1 virtual package continues to exist.  (And 
yes, loaders are not ICDs, so libreoffice Suggesting them as 
alternatives to each other is probably a bug.)

For the actual ICDs themselves, yes, my proposal was to have a 
metapackage depending on all the DFSG-free ones, and also keep the 
existing opencl-icd virtual package.

Paul Wise wrote:
 > maybe now is the time
to do this, so that the problems can be found via bug reports?
Simon Richter wrote:
 > Yes, but the others correctly report that no hardware can be found, 
and it's up to the application to disregard them. This generally works, 
because pocl also reports "no hardware can be found" if you ask for a 
GPU, so this is a well-tested code path.

Not necessarily: not every application asks for a GPU (rather than 'any 
OpenCL device'), and if the application silently falls back to running 
without OpenCL on failure, it might not be obvious that it didn't find 
OpenCL when it should have done.

Since ocl-icd 2.2.5, ocl-icd-libopencl1 sorts the ICDs to make the first 
one a reasonable default choice, which fixed some issues of this kind, 
but not all of them.

These look like they'd still have issues:
https://sources.debian.org/src/asl/0.1.7-4/src/acl/aclHardware.cxx/#L70
https://sources.debian.org/src/erlang-cl/1.2.4-1/c_src/cl_nif.c/#L6759 
(maybe)
https://sources.debian.org/src/ocl-icd/2.3.2-1/ocl_icd_loader.c/#L1249 
(if the device type you ask for isn't the first platform's type)
and there may be more.