Is libcuda.so mandatory for the driver to work?

[debarshiray]

I am curious if libcuda.so is mandatory for the proprietary NVIDIA driver to work? eg., purely for driving the display with OpenGL and Vulkan.

I am asking because, I am the maintainer of Toolbx and I received a bug report from a user who expects to be able to use the NVIDIA Container Toolkit with the proprietary NVIDIA driver without having libcuda.so. See containers/toolbox#1694

I don't know enough about the driver to conclude if this expectation is valid or not.

[debarshiray]

Ping

[elezar]

@debarshiray from the point of view of enumerating the devices on the system to generate the CDI specs that we inject, only libnvidia-ml.so is required. We do, however, use libcuda.so.VERSION as an indication of where the driver libraries are expected and this is what is failing in your case.

As to the question of whether libcuda.so is REQUIRED for graphics applications to work, I would assume yes but I will follow up with the driver team.

Update: We could in theory relax our checks as is done in #1451 (note that libnvidia-ml.so is currently REQUIRED to allow us to enumerate the device nodes etc. that are required).

[debarshiray]

I see. Thanks for the explanation.

Did I understand #1451 correctly that it tries to use the suffixes of either libnvidia-ml.so or libcuda.so, whichever is available, to infer the version of the driver? So, if libcuda.so is absent, it will work with libnvidia-ml.so, which is already mandatory for the NVIDIA Container Toolkit to work, right?

[elezar]

I see. Thanks for the explanation.

Did I understand #1451 correctly that it tries to use the suffixes of either libnvidia-ml.so or libcuda.so, whichever is available, to infer the version of the driver? So, if libcuda.so is absent, it will work with libnvidia-ml.so, which is already mandatory for the NVIDIA Container Toolkit to work, right?

Yes, that's correct. There are CDI spec generation modes that don't use NVML (--mode=management for example), but this still requires the suffix to get the driver version. Are you in a position to test the changes from the PR (or would you be once they are available on main?)

[debarshiray]

Did I understand #1451 correctly that it tries to use the suffixes of either libnvidia-ml.so or libcuda.so, whichever is available, to infer the version of the driver? So, if libcuda.so is absent, it will work with libnvidia-ml.so, which is already mandatory for the NVIDIA Container Toolkit to work, right?

Yes, that's correct. There are CDI spec generation modes that don't use NVML (--mode=management for example), but this still requires the suffix to get the driver version.

Okay, great!

Are you in a position to test the changes from the PR (or would you be once they are available on main?)

Yes, I can test #1451 in a few hours, once I wrap up some other work.

[elezar]

Yes, I can test #1451 in a few hours, once I wrap up some other work.

@debarshiray were you able to validate the changes on your end?

[elezar]

@debarshiray I have merged #1451 and it will be included in the next minor release (v1.19.0). If your testing shows that it is required to unblock other users, we could consider backporting it to the release-1.18 branch.

[elezar]

@debarshiray I have included the logic that also checks libnvidia-ml.so.* to extract the driver version. Please see whether this works the way you expect it.