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

[Simon Richter]

Hi,

On 6/19/23 19:04, Simon McVittie wrote:

> - in GLX, EGL, VA-API and VDPAU, only one ICD gets loaded (hopefully the
>    right one)

> - in Vulkan, every ICD gets loaded, and ICDs for hardware you don't have
>    are expected to report "no supported devices" in a graceful way; and
>    if you have more than one ICD supporting the same hardware, or more than
>    one GPU, or a software driver like lavapipe, then the application is
>    offered a choice between all the possible devices and will hopefully
>    choose an appropriate one to render on

> It sounds as though OpenCL is more similar to Vulkan here?

Yes.

> It seems unfortunate that ocl-icd-libopencl1 has "icd" in its name,
> but is not an ICD (instead it's an ICD loader). I believe that's because
> ocl-icd is the source package name?

Yes.

>> Since these provide a shared library with a fixed name, the ICD loaders
>> either need to conflict or provide alternatives.

> Is there an obvious "best" loader - perhaps ocl-icd-libopencl1 - that
> we can choose to be the only one that Debian supports, similar to
> the way we use GLVND for GLX/EGL and the reference Vulkan-Loader for
> Vulkan? It seems to me that the ecosystem would be simpler if the ICDs,
> which should in principle be the only thing that is hardware-specific,
> were the only thing that involves a choice.

If the free implementation supports the highest version, then IMO that 
is the best choice.

 From Debian's PoV, that is the only one we can reasonably support at 
all. If we also want to allow users to install another implementation 
(IMO, yes), then we get to choose how the user should resolve the 
conflict -- through the package manager or through update-alternatives.

The latter gives us priorities, which we can use for some kind of 
"highest supported CL version wins, if there is a tie, we go with the 
free software version."

 From a support perspective, we should probably also have defined 
behaviour in case the highest priority is tied between proprietary 
loaders, maybe run piglit cl tests with either and compare number of 
crashes when just the CL loader is different. :P

> Perhaps it should be the loader that has a Recommends or Depends on
> a selection of suitably high-quality Free ICDs?

Yes. There are dozens of packages using CL, but only four loaders. Maybe 
another layer of indirection through a metapackage that we can update 
without changing the proprietary ICD loader packages.

> I'm not sure this is a good idea: having multiple versions of the
> NVIDIA proprietary driver installed at the same time doesn't seem very
> supportable, since only one of them (the one that matches the loaded
> kernel module) will actually work.

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.

> Are there any significant proprietary OpenCL drivers other than NVIDIA's?

AMD's, and I believe those have CPU support as well -- so if you have an 
AMD card, you can create a mixed queue with CPU and GPU commands and 
dependencies between them, and if you don't have an AMD card, the CPU 
device still works.

>> Unfortunately intel-opencl-icd can't replace beignet-opencl-icd
>> because the former doesn't support old hardware. At least on my
>> system, clinfo says only pocl and beignet have supported devices.

> If beignet-opencl-icd no longer builds, then we can't ship it, however
> much your older hardware might benefit from it.

I'll take a look (my laptop has an HD4000 that is supported by Beignet).

> Older Intel integrated GPUs are not very fast anyway, so this might not
> be a particularly significant loss.

Also true.

    Simon