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