Re: [Pkg-opencl-devel] opencl-icd virtual package(s)?
Le 18/06/2023 à 08:28, Rebecca N. Palmer a écrit :
On 18/06/2023 03:37, Paul Wise wrote:
Presumably any of the OpenCL ICDs work for most packages?
For most OpenCL-using *packages* but not most *hardware*. (Except for pocl-opencl-icd, which works nearly everywhere but is slow.)
Perhaps there should be a default-opencl-icd virtual package?
Hence, such a package would need to Depend on or Recommend *all* the ICDs, similar to xorg-xserver-video-all.
I have proposed this before (see 31-Jan-2015 pkg-opencl-devel), but never actually did it, partly because there are applications that implicitly assume that all the installed ICDs work, and may fail to find the usable ICD if there are unusable ones installed. (I consider this to be a bug in the application, but finding and fixing these would take time.)
This is problematic, because some icd are in main (pocl), others are in non-free (nvidia).
In fact, there is a problem since the beginning with OpenCL dependencies.
When a program uses OpenCL, it links against a ICD Loader that will dynamically load the available ICD.
There are different versions of OpenCL.
An ICD Loader supporting OpenCL x should also support OpenCL y<=x (there are a few exceptions, but I will ignore them for now)
This is provided by the virtual package libopencl1 (and the ocl-icd-libopencl1 in main).
All OpenCL programs should only depend on the (versionned) libopencl1 virtual package. If using ocl-icd-opencl-dev, this is done automatically.
An OpenCL program can suggest/recommend one/some ICD packages but the ICD selection is done at runtime.
Reusing the commands from the first mail (but restricting to Depends only), only 4 packages really depends on a specific ICD:
$ grep-aptavail --no-field-names --show-field Package --field Depends --whole-pkg '(' --pattern .*opencl-icd.* --and --not --pattern '^opencl-icd(-1\.[1]2-1)?$' ')' | sort -u
hashcat
hashcat-nvidia
libhmsbeagle1v5
python3-pyopencl
For python3-pyopencl, it seems a false positive (depends on pocl-opencl-icd | mesa-opencl-icd | opencl-icd). However, it might be better to move this to a recommends (one can install a ICD without using a Debian package).
For libhmsbeagle1v5 also (depends on mesa-opencl-icd | opencl-icd), however it does not depends on an ICD Loader! (libopencl1)
Same for hashcat (depends on pocl-opencl-icd | opencl-icd) and it also does not depend on an ICD Loader!
hashcat-nvidia seems a metapackage forcing the installation of nvidia-opencl-icd or nvidia-legacy-390xx-opencl-icd (but, as it depends on the hashcat package for the program, I doubt that the nvidia implementation will be used if another one is presented by default to the program)
An ICD Loader supporting OpenCL x means that it provides all symbols required for OpenCL x (that are a supersede of symbols for OpenCL y<x) and is able to load any ICD supporting OpenCL y<=x
BUT if a program links against an ICD Loader supporting OpenCL x, at runtime, when the program start, it will get the list of all available ICD on the machine, whatever their versions are.
So, we can have an opencl programs using OpenCL 2.2, running with an ICD Loader supporting OpenCL 2.3 (no problem here), but trying to use an ICD supporting only OpenCL 1.1
There are nothing we can do with the Debian dependencies system because it occurres at runtime.
With the previous (non-working) situation, we can have another programs using OpenCL 1.1, running with an ICD Loader supporting OpenCL 2.3 (no problem here) and using the ICD supporting OpenCL 1.1 (all good).
So, we rely on the OpenCL programs to correctly select the required ICD.
All we can do with the dependency system (not yet done) would be to force a dependency on a new virtual package to ensure that at least one ICD with the correct minimal version is available.
I'm not sure if this is really possible (is it possible to install several packages providing the same virtual package ?)
But, even with this, we rely on the OpenCL program to select the correct ICD (through the ICD Loader).
And some ICD supports only some parts of a openCL version (most functions but a few less used ones). So, it would be difficult to set a correct supported OpenCL version for this ICD.
If the ocl-icd-libopencl1 ICD Loader is used, the selection can also be done externally with an envvar (the ocl-icd-libopencl1 ICD Loader only shows the selected ICD to the program)
Regards,
Vincent
PS: I noticed this because beignet-opencl-icd is RC-buggy. This is the
only OpenCL ICD implementation package I can see that supports Intel
Ivy Bridge, but it is hard to tell which other packages support this,
because some descriptions don't mention which hardware is supported.
I think of it as
intel-opencl-icd = Intel integrated GPUs (replacing beignet-opencl-icd, which as you note, no longer builds)
mesa-opencl-icd = ATI GPUs (including AMD integrated GPUs)
pocl-opencl-icd = CPUs
but that might be out of date.
Reply to: