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

[Simon McVittie]

At the risk of stating the obvious, OpenCL seems to be "the same shape"
as many other GPU-related APIs like GLX, EGL, Vulkan, VA-API and VDPAU:

- applications link to a loader library
- the loader library dlopens a concrete implementation of OpenCL
  (an "ICD", Installable Client Driver)
- hopefully it chooses an ICD that will work on your hardware
- most ICDs are specific to a class of hardware, for instance one for all
  AMD GPUs
- there is one ICD that runs on the CPU and has no special GPU requirements
  (for GL this is llvmpipe, for Vulkan it's lavapipe, for OpenCL it's pocl)

Given that, it would probably make sense for the packaging of OpenCL to be
"the same shape" as the other GPU-related APIs.

As far as I understand it, there are two different models in the
graphics world:

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

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?

On Mon, 19 Jun 2023 at 13:01:21 +0900, Simon Richter wrote:
> 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.

(In particular, NVIDIA ship their own binary build of an unknown and
possibly patched version of GLVND with their drivers, but we don't
package that: we use the one built by us from src:libglvnd instead.)

On Mon, 19 Jun 2023 at 12:10:22 +0800, Paul Wise wrote:
>    Package: some-opencl-using-package
>    Recommends: opencl-icd-all | opencl-icd

Presumably it should also depend on ocl-icd-libopencl1 | libopencl1,
via ${shlibs:Depends}, since it will link to libOpenCL.so.1 and that's
usually going to be a hard dependency?

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

In GLX and EGL, the loader Depends on Mesa's ICD.

In Vulkan, the loader Recommends Mesa's ICDs (there are several in one
package).

OpenCL is a bit more complicated than GLX/EGL/Vulkan here because the
Intel and on-CPU OpenCL drivers aren't part of Mesa, so there is no
completely obvious choice; so I agree that a metapackage that pulls in
all the (sufficiently high-quality) Free ICDs is probably useful to have.

>    Depends:
>     opencl-icd-all-free,
>     nvidia-legacy-340xx-opencl-icd,
>     nvidia-legacy-390xx-opencl-icd,
>     nvidia-opencl-icd,

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.

Instead, I think nvidia*-driver-libs should probably pull in the
appropriate NVIDIA OpenCL ICD as a Depends/Recommends/Suggests (depending
on how important Debian considers OpenCL to be), the same way it currently
pulls in GLX and EGL as Depends, and GLES and Vulkan as Suggests.

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

> > 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.)
> 
> Since we just opened trixie for development, maybe now is the time
> to do this, so that the problems can be found via bug reports?

As mentioned above, I believe Vulkan works this way.

> > intel-opencl-icd = Intel integrated GPUs (replacing beignet-opencl-icd, 
> > which as you note, no longer builds)
> 
> 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 think for trixie your
older hardware will have to fall back to running OpenCL on the CPU (pocl),
the same way that for very old GPUs, OpenGL falls back to llvmpipe and
Vulkan falls back to lavapipe instead of using GPU-accelerated rendering.

(There is in fact a "friendly fork" of Mesa to get accelerated 3D on
somewhat older GPUs than the oldest ones supported by our current Mesa,
but it never got into bookworm and is still stuck in NEW:
see #1006202 and https://ftp-master.debian.org/new/mesa-amber_21.3.9-1.html.)

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

    smcv