Should the DEB package recommend nvidia-opencl-icd?

[marcosfrm]

The DEB package currently recommends nvidia-opencl-icd. For users with the contrib and non-free repositories enabled, it pulls in over 80 packages with the Nvidia graphics stack. While this likely enables seamless CUDA support for Nvidia GPU users, it adds unnecessary bloat for those with AMD or Intel GPUs. Would it be better to remove this recommendation and let users install the appropriate packages for their GPU, perhaps with improved documentation to guide them? One could also ask why the package doesn't recommend ROCm for OpenCL support on AMD GPUs, either from distribution repositories or AMD's own ROCm repository.

[muziqaz]

Now it is only a recommendation, so much better, than before, where it would ask as hard dependency.
Client not having any recommendations for AMD side of things is also ok, because stuff, which AMD needs, is not available in distro repos

[marcosfrm]

The --no-install-recommends option in apt serves as a workaround for users without Nvidia hardware.

Starting with Debian 13, ROCm is available in the repository, but it's an older version (5.7.1). Whether it works is unclear. The rocm-opencl-icd package is more or less equivalent to AMD's rocm-opencl-runtime. However, ocl-icd-libopencl1 must be installed manually (along with ocl-icd-opencl-dev, due to the need for the unversioned library still required by the cores, but no longer required by the client thanks to recent changes in cbang), as there's no explicit dependency between them.

The same applies to Intel GPUs. Why does only Nvidia receive "special treatment", pulling in a stack of unnecessary packages for users with AMD or Intel GPUs?

[muziqaz]

ROCM 5.7.1 works, but is old (as per Debian ethos), and this is just one distro. The rest of the world is too fragmented. Though 90% of distros are in agreement to not have certain things on tap. We would get constant questions from AMD users if they installed the client which also recommended some AMD package, and they would say that even with recommended package fah is not working.
I have a guide, which works 99.9% of the time, and once (if) HIP hits the streets, there probably is going to be another round of guides, which will most likely be spread much wider across forums than opencl has ever been able to. Plans are already in place, all is missing is HIP fahcore :D :D

[jcoffland]

I think we should leave this as is. It may not be "fair" to AMD and Intel GPU users but it maximizes scientific throughput. If /when AMD has a package that works out-of-the-box then we should make it a recommended package as well.

[marcosfrm]

I don't think there's a way to recommend all possible packages for the three vendors, such as

nvidia-opencl-icd, rocm-opencl-runtime | rocm-opencl-icd, intel-opencl-icd, ocl-icd-libopencl1, ocl-icd-opencl-dev

without pulling in even more unnecessary packages.

One option would be to recommend only ocl-icd-libopencl1 (and unfortunately ocl-icd-opencl-dev, which pulls in a lot of unnecessary components). The former suggests the opencl-icd metapackage, which is provided by any implementation listed at https://packages.debian.org/trixie/opencl-icd (note that Intel is absent due to packaging issues in Debian 13: https://www.reddit.com/r/debian/comments/1mm7cjm/so_what_happened_to_intelopenclicd_in_trixie/). However, users would need to install the specific package for their hardware.

[muziqaz]

Let's not recommend anything. Things are worked out now, let's not complicate things. Otherwise, I'll lose the rest of my hair when explaining why things are not working or package is not available, etc.

[marcosfrm]

Let's not recommend anything.

So you agree, at least in part, with me 😄, because today the package recommends nvidia-opencl-icd, and I think it shouldn't.

But I understand that if the user base with Nvidia GPUs is larger, which I suspect might be the case, it increases the chance of out-of-the-box compatibility, which has its advantages, even if it means unnecessary packages on machines with GPUs from other brands.

Anyway, we can leave things as they are.

[muziqaz]

I posted the question about nvidia dependency back when it was introduced. And now it is no longer a dependency, but recommendation, so I don't really care about it too much. It would be neat that client stayed away from suggestions, but it doesn't break anything, so let it be. However, I wouldn't want client to try and recommend AMD packages, since these have multiple obstacles in the way, and they would bring more questions than solutions.

[Artoria2e5]

Recommending anything that's vendor-dependent is bad. Suggesting is fine (yes there is a "suggests" thing that gets displayed), but it's of dubious usefulness -- I don't think it actually does any useful informing of a user.

Not recommending isn't great either because we all know most of the compute power is in the GPUs now and we do want stuff to work kinda out-of-the-box. So just recommend the vendor-neutral thing.

Ideal case

There should be a semi-hard dependency (recommend) for libopencl.so.1, which would be libopencl1.

Recommends: libopencl1

This is a virtual package that can be provided by either ocl-icd-libopencl1 or nvidia-libopencl1. Personally I believe the civilized way to do opencl is via the One True ICD, but if someone wants Nvidia's ICD implementation then by all means go for it.

Now ocl-icd-libopencl1 (nvidia-libopencl1 too) has a RECOMMEND for the virtual package opencl-icd, which can be provided by any of the opencl impls that register an ICD (nvidia, rocm, whoever). That's good and should remove the need for FAH itself doing any recommending or suggesting.

But the cores!

right, marcosfrm also said that the cores want the lib without the ".1", so the actual dependency for now should be libopencl.so + libopencl.so.1. Nvidia can't do that! So really what you want is:

Recommends: ocl-icd-libopencl1, ocl-icd-opencl-dev

And that's it, no vendor deal.

Or

Or we should just fix the cores. It's some simple patchelf job (see manpage at https://man.archlinux.org/man/extra/patchelf/patchelf.1.en). Just do patchelf --replace-needed so that the cores depend on the .1 thing. No recompilation needed.

Or the postinst script can get naughty and just create the /usr/lib/x86_64-linux-gnu/libOpenCL.so -> libOpenCL.so.1 symlink itself if it doesn't exist.

Or the Debian version can use a wrapper script on the client that sets LD_LIBRARY_PATH containing a known-good libOpenCL.so symlink; the core, being a child of the client, would inherit the variable and be fine. It works for porting steam to a bunch of distros, it's gotta work for us too.

[marcosfrm]

The issue where cores require unversioned libraries has been addressed in recent cbang. However, the change will only apply to future cores.

CauldronDevelopmentLLC/cbang@e890707
CauldronDevelopmentLLC/cbang@e5c0fa9

It would be great if previous cores could be patched using patchelf, but even if the dynamic section has the proper dependency, I think libOpenCL.so is still loaded with dlopen() via cbang. Therefore, this approach may not suffice.