CUDA For GPUs
The optional CUDA packages should be deployed in order to take advantage of the computational capabilities of NVIDIA GPUs. The packages may already be in place, and ready for deployment on the cluster, depending on the particular BCM software that was obtained. If the CUDA packages are not in place, then they can be picked up from the BCM repositories, or a local mirror.
9.1 Installing CUDA
9.1.1 CUDA Packages Available
At the time of writing of this section (April 2026), the CUDA 13.1 package is the most recent version available in the BCM YUM, zypper, and APT repositories. The available versions are updated typically in the next point release version of NVIDIA Base Command Manager after the upstream changes are made available. An up-to-date list of packages available for a particular distribution and architecture can be viewed at https://service.bcm.nvidia.com/packages-dashboard/.
Thus, for example, at the time of writing, Rocky Linux 9.6 has many CUDA versions available, in the range from CUDA 11.7 to CUDA 13.1 for the x86_64 architecture, while Ubuntu 24.04 just has CUDA 12.5, CUDA 12.6, CUDA 12.8, CUDA 12.9, CUDA-13.0, and CUDA 13.1 for x86_64.
9.1.1.1 Example: CUDA Packages Available For Ubuntu 24.04
At the time of writing of this section (April 2026), a cluster administrator can manage these packages for Ubuntu 24.04:
* optional, intended only for hardware containing an NVSwitch, such as a DGX system
** installed by default on software images, not on head nodes
† the driver typically has a version number tag such as -590.
-
The packages of type
sharedin the preceding table should be installed on the head nodes of a cluster using CUDA-compatible GPUs. -
The packages of type
localshould be installed to all nodes that access the GPUs. In most cases this means that the-
nvidia-driver(NVIDIA driver metapackage) -
cuda-dcgm(NVIDIA Data Center GPU Manager) -
nvidia-fabricmanager(Fabric Manager for NVSwitch based systems) -
nvidia-fabricmanager-dev(Fabric Manager API headers and associated library)
packages should be installed in a software image (section 2.1.2 of the Administrator Manual). By default, BCM software images already have these packages, which means that an explicit installation by the cluster administrator should not be required.
If a head node also accesses GPUs, then the
nvidia-driverandcuda-dcgmpackages should be installed on it, too. -
For packages of type shared, the particular CUDA version that is run on the node can be selected via a modules environment command. For example, to select CUDA SDK version 13.0, the user can run:
Example
Release notes and features list for the CUDA packages:
-
Release notes for the NVIDIA toolkit can be found at:
https://docs.nvidia.com/cuda/cuda-toolkit-release-notes/index.html -
The features list for the NVIDIA toolkit can be found at:
https://docs.nvidia.com/cuda/cuda-features-archive/index.html
CUDA packages that the cluster administrator normally does not manage: As an aside, there are also the additional CUDA DCGM packages:
At the time of writing of this paragraph (April 2026) the latest DCGM version supported by BCM was 4.5.2. Running a
-
dnf info cuda-dcgm; dnf list cuda-dcgmfor RHEL-family distributions -
apt show -a cuda-dcgmfor Ubuntu distributions
should reveal the currently installed and available versions for the cluster.
- Release notes for the DCGM versions are available at https://docs.nvidia.com/datacenter/dcgm/latest/release-notes/changelog.html.
9.1.1.2 CUDA Package That The Cluster Administrator May Wish To Install For CUDA Programming
CUB is a CUDA programming library that developers may wish to access. It is available for some distributions for some older CUDA versions, and provided by the package cm-cub-cuda.
9.1.1.3 CUDA Package Installation Basic Sanity Check
-
The NVIDIA GPU hardware should be detectable by the kernel, otherwise the GPUs cannot be used by the drivers. Running the
lspcicommand on the device with the GPU before the CUDA package driver installation is a quick check that should make it clear if the NVIDIA hardware is detected in the first place:Example
running
lspcionnode001. Here 4 GPUs are detected:If the hardware is not detected by the kernel already, then the administrator should reassess the situation.
The
Device 2941part of the string can be tallied against the identifiers in theREADME.txt.gzfile of thenvidia-driver-580package series, at the node where it has been installed.Example
The output of the
lspcicommand can be more directly informative for some hardware:Example
-
Only after CUDA package installation has taken place, and after rebooting the node with the GPU, and allowing CMDaemon some time (a few minutes) to detect the change, are GPU details visible using the
sysinfocommand:Example
running
sysinfoonnode001, which is where the GPUs are, viacmshon the head node, whilecuda-dcgmis not yet ready:Example
running
sysinfoonnode001, viacmshon the head node, aftercuda-dcgmis ready. 4 GPUs are detected
9.1.1.4 CUDA Package Installation Guidelines For Compilation With Login Nodes
-
CUDA compilation should take place on a node that uses NVIDIA GPUs during compilation.
- Using a workload manager to allocate this task to GPU nodes is recommended.
-
Cross compilation of CUDA software with a CPU is generally not a best practice due to resource consumption, which can even lead to crashes.
-
If, despite this, cross compilation with a CPU is done, then the
nvidia-driverpackage should be installed on the node on which the compilation is done, and the GPU-related services on the node, such as:-
nvidia-persistenced.service -
nvidia-fabricmanager.service -
nvidia-dcgm.service
should be disabled.
-
-
9.1.2 CUDA Package And Modules
The CUDA packages require access to the BCM repositories and to the distribution repositories.
The nvidia-driver packages replace the older cuda-driver packages that were used in versions of BCM prior to version 11. The newer packages do not compile the driver modules source at boot time, but during package installation. The newer packages are also open source.
Example
For example, on a cluster where (some of) the nodes access GPUs, but the head node does not access a GPU, the following commands install the CUDA 13.0 packages on the head using APT:
The nvidia-driver-, cuda-dcgm, cuda-dcgm-nvvs, and nvidia-fabricmanager are already installed by default on the default software image, which is default-image on a newly-installed default cluster.
Carrying out an explicit installation or imageupdate for these is therefore normally not needed.
In cases where it is required, then manual installation into a software image is described in section 9.4 of the Administrator Manual, while running the imageupdate command (section 5.6 of the Administrator Manual), for example on nodes 1 to 10, can be carried out with:
Example
If the CUDA packages have been set up on the cluster, then the end user typically just switches between CUDA environments with a module change (section 2.2 of the Administrator Manual and section 2.3 of the User Manual).
Example
9.2 Verifying CUDA
The cuda*-sdk packages provide CUDA SDK sources that can be used to compile libraries and tools that are not part of the CUDA toolkit, but used by CUDA software developers, such as the deviceQuery binary (section 9.2).
An extensive method to verify that CUDA is working is to run the verify_cuda <version>.sh script, located in the CUDA SDK directory. The value of <version> can be 13.0, for example.
This script first copies the CUDA SDK source to a local directory under /tmp or /local. It then builds CUDA test binaries. To build the makefiles, the compilation may need cmake, installed from the cm-make package into the image (section 9.4 of the Administrator Manual).
These binaries clutter up the disk and are not intended for use as regular tools, so the administrator is urged to remove them after they are built and run.
A help text showing available script options is displayed when “verify_cuda <version>.sh -h” is run.
A typical run output is as follows (some output elided):
Example
One of the binaries compiled is the deviceQuery command. This can be run on a node accessing one or more GPUs. The deviceQuery command lists all CUDA-capable GPUs that a device can access, along with several of their properties (some output elided). It can be run in CUDA 13 as follows:
The query can detect if there is more than 1 GPU, and display output for each GPU that it finds.
The CUDA programming guide (https://docs.nvidia.com/cuda/cuda-programming-guide/) has further information on how to run compute jobs using CUDA.
9.2.0.1 Further Information On CUDA Verification
More on verification can be found in the NVIDIA CUDA INSTALLATION GUIDE FOR LINUX at https://docs.nvidia.com/cuda/pdf/CUDA_Installation_Guide_Linux.pdf.
9.3 Verifying OpenCL
CUDA 12.8 contains an OpenCL compatible interface. To verify that OpenCL is working, or failing, the binaries can be compiled from the provided OpenCL source and run. For example:
Example
The binaries made using the Makefile can then be run from their directory:
…And so on. The other binaries listed should also run and pass.…
9.4 NVIDIA Validation Suite (Package: cuda-dcgm-nvvs)
The NVIDIA Validation Suite (NVVS) runs diagnostics to validate the NVIDIA software components. Running the nvvs binary directly is deprecated. The diagnostics for CUDA 12.8 are run instead as part of the dcgmi diag command.
The package for NVVS is not installed by default. It is also not available for RHEL8 and derivatives.
If the package is not installed, then an attempt to run the dcgmi utility fails:
Example
The package can be installed with:
Example
After it is installed, the node on which the installation is done must be rebooted.
Running the diagnostic after the reboot should display output similar to:
Example
9.5 Further NVIDIA Configuration Via The Cluster Manager
After the installation and verification has been carried out for CUDA drivers, further configuration as part of CMDaemon management can be carried out, as explained in section 3.17.2 of the Administrator Manual.