Re: opencl-icd virtual package(s)?
(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.
Reply to: