NVIDIA Transitions Fully Towards Open-Source GPU Kernel Modules

Open-sourcing GPU kernel modules sounds like handing the hardware to the community — but the modules are only the bridge between Linux and GPU firmware, and that firmware still runs in closed silicon. What changed is where the trust boundary sits, not how far it extends.

Source

NVIDIA Transitions Fully Towards Open-Source GPU Kernel Modules

By: Rob Armstrong, Kevin Mittman, Fred Oh
Published: Jul 17 2024
Type: Engineering announcement

Worth noting for anyone managing CUDA deployments or Linux GPU workloads — the package names, metapackage structure, and installer defaults all changed in CUDA 12.6 and R560.

What the R560 default flip actually changes

NVIDIA’s GPU driver has two distinct layers. The kernel modules run inside Linux kernel space and handle the interface between the OS and the hardware; user-space components — the OpenGL libraries, CUDA runtime, NVCC toolchain — sit above and stay in user memory. When NVIDIA open-sourced the kernel modules in May 2022 with R515, only that bridge layer became visible. The firmware executing inside the GPU itself remained closed, as it does today. The transition is about auditability and distribution packaging, not about opening the full GPU stack.

For two years after R515, the open modules were opt-in and recommended only for datacenter compute GPUs. GeForce and Workstation users could use them, but the designation was alpha. That interval added heterogeneous memory management (HMM) support, confidential computing features, and the coherent memory architecture used on Grace platforms — enough progress to close the performance gap with the proprietary driver.

With R560 and CUDA Toolkit 12.6, the defaults change by architecture. Grace Hopper and Blackwell now require the open-source modules — NVIDIA dropped proprietary driver support for those platforms entirely. For Turing, Ampere, Ada Lovelace, and Hopper, the recommendation shifted from proprietary to open, and all standard package manager paths now deliver the open driver by default. Maxwell, Pascal, and Volta are the holdouts: the open modules are incompatible with those architectures, and those GPUs continue on the proprietary driver.

Mixed systems — a machine with both an older GPU (Maxwell/Pascal/Volta) and a newer one — are the most operationally awkward case. No single driver covers both generations simultaneously, so NVIDIA’s recommendation is to keep the proprietary driver for the whole system. This is a real constraint for workstations assembled across hardware generations: an older compute card alongside a newer display adapter, for example. It isn’t automatically detected and requires knowing your GPU inventory.

For teams managing CUDA through package managers, the concrete change is in the top-level cuda metapackage. Before CUDA Toolkit 12.6, installing cuda via apt or dnf pulled the proprietary driver bundle. Starting with 12.6, it pulls the open driver. On Debian and Ubuntu the package is nvidia-open; on RHEL/Fedora the module stream is nvidia-driver:open-dkms; on SUSE it’s nvidia-open with optional suffixes for Azure or 64k kernel flavors. .run file installs query hardware automatically and default to the best-fit driver; --kernel-module-type=proprietary overrides when needed. CUDA Toolkit itself installs unchanged.

WSL is a clean non-change. Linux on WSL uses the Windows-side NVIDIA driver, so the kernel module distinction doesn’t apply there and nothing about WSL installation changes.

The less-discussed benefit is in Linux distribution packaging. Proprietary kernel modules ship as external blobs, which keeps them out of mainline distribution channels and forces users onto vendor repositories. Open modules can be patched, audited, and updated against new kernel versions by distribution maintainers working independently of NVIDIA’s release schedule. For deployments that need to track a Linux LTS kernel aggressively — air-gapped systems, security-sensitive environments — this changes what “supported kernel version” practically means. Kernel ABI compatibility problems that previously required a new blob from NVIDIA can now be addressed upstream or locally. That’s the unglamorous part of the announcement, but it’s the part that matters most for long-running infrastructure.

What I want to remember

Remember: The open/proprietary choice is architecture-gated in R560+: Grace Hopper and Blackwell require open modules, Maxwell/Pascal/Volta can’t use them, and mixed-GPU systems stay on proprietary — check your GPU inventory before upgrading a CUDA metapackage.