NVIDIA’s Linux GPU kernel modules have shipped as open source under a dual GPL/MIT licence since May 2022, but the driver that comes out of them is not wholly free: it depends on a proprietary firmware loaded at runtime and on a closed user-space stack. The difference makes itself felt the moment you have to decide which layer of the stack you can actually get your hands on.

Context

For nearly two decades NVIDIA’s Linux driver was a blob: a small open wrapper (nvidia.ko) hooking a proprietary binary into the kernel. Anyone running machines with these cards knows the practical consequences well — the module taints the kernel, will not recompile, follows the vendor’s release cycle, and distributions cannot package it the way they do the Mesa drivers for AMD and Intel. In parallel there is nouveau, the free driver born from reverse engineering, long held back by the inability to do reclocking: without the power-management tables the GPU stayed pinned to low clocks and delivered a fraction of its rated figure.

On 15 May 2022, with the R515 release, NVIDIA published the kernel modules as source under a GPL/MIT licence, in the NVIDIA/open-gpu-kernel-modules repository. It is a genuine change of policy, but it is worth reading precisely how far that openness reaches.

Architecture

What makes the opening possible is the GSP, the GPU System Processor: a RISC-V coprocessor that appeared in the GPUs from the Turing architecture (2018) onward. Functions that had always lived in the host driver — chip initialisation, clock and power management, low-level scheduling — moved into the firmware that runs on the GSP.

The move has two consequences. First: the code NVIDIA treats as sensitive no longer sits in the kernel module but in the firmware, so the module could be opened without exposing that code. Second: the open driver requires the GSP firmware to be active. The open-gpu-kernel-modules run only on Turing and later, because on older hardware there is no GSP and those functions would have to go back into the driver. The repository documentation says it plainly — the open modules do not cover pre-Turing GPUs.

The GSP firmware is a binary blob, on the order of tens of megabytes, distributed separately and versioned in lock-step with the kernel modules and the user-space libraries. The three components must match exactly in version.

The critical point

“Open-source driver” does not name a single artefact but a three-layer stack, and the openness stops at the first:

  • Kernel module (nvidia.ko and related) — open source, GPL/MIT, recompilable.
  • GSP firmware — proprietary blob, executed on the GPU’s coprocessor. Closed.
  • User space (the CUDA runtime, OpenGL, the compiler, the compute libraries) — proprietary. Closed.

The code that really weighs for anyone running GPU workloads is not in the kernel module: it is in CUDA and the libraries tied to it, all closed. Opening the kernel module sorts out the packaging and kernel-integration problems — the module stops being an obstacle for distributions and can follow the kernel’s internal interfaces — but it does not make inspectable or modifiable the layer where the real work runs.

There is a gradation inside the first layer too. At the R515 release the open modules were declared production-ready only for the Turing and Ampere data-centre GPUs; for GeForce and Workstation parts the support was alpha-quality, to be enabled as opt-in. The GPU under a desktop and the GPU in a training node were not at the same level of maturity.

Implications

For system software the GSP changes the genuinely free driver too. nouveau has begun adopting the GSP-RM firmware published by NVIDIA: instead of reimplementing clock and power management in kernel space, it loads the same firmware blob and talks to it. The concrete result is automatic reclocking on Turing and later — the GPU runs at full clocks under a free driver, which was not possible before. The price is that the free driver now also depends on a proprietary blob, the same one the NVIDIA driver depends on.

On the graphics side, in early 2024 NVK — the open-source Vulkan driver for NVIDIA hardware inside Mesa, written by Faith Ekstrand, Karol Herbst and Dave Airlie — reached Vulkan 1.3 conformance on Turing, Ampere and Ada, and was declared ready for real-world use ahead of Mesa 24.1. For those generations there is, for the first time, an NVIDIA graphics stack open from kernel to user space — built, though, on top of the closed GSP firmware. For compute there is nothing equivalent: no free CUDA runtime exists, and the inference and training stacks (PyTorch, the vendor libraries) talk to CUDA.

A note on the day: today, at GTC, NVIDIA announced the Blackwell architecture — B200, GB200, rack-scale systems for trillion-parameter models. The software stack that drives that hardware remains CUDA, closed. The 2022 opening of the kernel module does not touch that layer, and nothing in today’s announcement shifts it.

Limits

All of this concerns the Linux driver. On Windows the model stays wholly proprietary, and none of it applies. On Linux too the open modules cover only Turing and later: anyone with Pascal or earlier hardware, on the NVIDIA driver, still uses the legacy blob.

Opening the kernel module is not freely reversible — the 2022 source stays public — but it implies nothing about the rest of the stack. The closed components (GSP firmware, CUDA runtime, compiler, libraries) remain so, and in 2024 the open module’s maturity varies between data-centre and consumer. “Open” describes one layer of the stack, not the stack.

Cover image: Macro photograph of the silicon die of the NVIDIA Turing TU106 GPU (GeForce RTX 2060), with the processor’s functional blocks visible… — photo by Fritzchens Fritz, CC0 — https://commons.wikimedia.org/wiki/File:Nvidia@12nm@Turing@TU106@GeForce_RTX_2060@S_TAIWAN_1844A1_PM4F79.000_TU106-200A-KA-A1_DSC07437-DSC07591_-_ZS-DMap_(50914099198).jpg