driver setup for compute only use How to install the nvidia driver for compute-only use?

As I need the nvidia driver for compute-only use with various cards, but not for display, I have installed it and load it manually. However, although the kernel module gets loaded on OS startup, it does not get initialized (?) as the devices are not present in /dev. Therefor nothing can be executed unless and until I run any binary in superuser mode that uses CUDA. After this everything works just fine.

$ lsmod | grep nvidia 

nvidia			   9630504  0

$ sudo tools/NVIDIA_GPU_Computing_SDK/C/bin/linux/release/deviceQuery

[...]

$ ls -l /dev/nv*

ls: cannot access /dev/nv*: No such file or directory

$ ls -l /dev/nv*

crw-rw---- 1 root video 195,   0 2010-01-26 21:19 /dev/nvidia0

crw-rw---- 1 root video 195, 255 2010-01-26 21:19 /dev/nvidiactl

I assume this is because some kind of initialization is missing that is normally done when X loads, I just could not find neither in the “NVIDIA Accelerated Linux Graphics Driver README and Installation Guide” nor in other online Linux kernel module loading related guides/documentations. Any ideas how to fix this?

OS: Ubuntu 9.10 AMD64

Kernel: 2.6.31-17-generic

NVIDIA driver: NVIDIA-Linux-x86_64-190.53-pkg2.run

If I am right and I did not miss the section that talks about how to install and use the driver for compute-only purposes, then I guess this is something that would be really useful for many people.

Suggestion for NVIDIA:

    the readme would badly need a section which details how to install the driver for compute-only use;

    the driver installer should have some built-in mechanism for choosing compute-only installation (which would obviously disable the installation of nvidia-xconfig, vdpau libs, etc.) and also selecting which of the other non-essential components are needed.

If I did miss any of the above suggested features, and in fact these do exist then please let me know where can I find the appropriate information and also disregard my requests.

The device creation issue is discussed in the toolkit release notes, which you can see here. There is even a prototype init script included to create the devices at boot time.

And the driver installation package does already have a driver only installation mode which won’t install X11 and OpenGL support libraries. If you run the installer program with the --advanced-options argument, you will see a vast number of installation customization options, including very fine grained control over what to install and where to install it.

Thanks for the quick reply!

I somehow missed this part of the release notes, I was focusing too much on the readme. As this is listed as a “known issue” I hope it will be fixed in future versions. Maybe it’s even fixed in 3.0b, is it?

It didn’t even cross my mind that this options should be used. Thanks again.

My previous suggestion (partially) still holds, it would be good to have the above information explicitly stated in the guide.

It isn’t anything to do with the CUDA toolkit or its installer, it is a driver installer “feature” and I very much doubt it will change with CUDA 3.0. The fraction of driver installs without X11 is probably a minute fraction of the total user population, and the consequences of “fixing” it are potentially lethal. I don’t know about you, but I am not so keen on having a distribution agnostic installer rummaging around and making changes to init settings on my operating system so that I might not actually even be able to boot afterwards.

I don’t seem to find options to disable the installation of components except for the OpenGL headers (–no-opengl-headers), not for the vdpau, nvidia-tls, OpenGL, and XvMC libs as well as X modules.

I even thought at some point that I will just give /dev/null for options like --opengl-libdir but it might not be the best idea… :)

Am I missing something or this is the only thing that can be disabled?

Sure, I mostly agree with you! However, as the X driver does the job without causing too much trouble, the same way there could be a properly tested mechanism included in the driver that - at least for the supported distributions - creates the /dev entries without a causing any problems. This can’t be that big of a deal…

Bump. I am still very much interested in this.