# NVIDIA open GPU kernel modules: what the source release actually contains

> NVIDIA publishes the Linux kernel interface layer and the OS-agnostic GPU driver code for Turing and later cards. Here is what builds, what ships as a binary, and where the split between the two halves matters.

**NVIDIA/open-gpu-kernel-modules** — NVIDIA Linux open GPU kernel module source

- Repository: https://github.com/NVIDIA/open-gpu-kernel-modules
- Stars: 17,429 · Forks: 1,883
- Language: C
- License: NOASSERTION
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/nvidia-open-gpu-kernel-modules

## The problem: the Linux kernel side of the NVIDIA driver was closed

A GPU driver on Linux is split across a boundary the kernel enforces. Part of the driver runs in user space, part runs inside the kernel, and the kernel part has to be compiled against the exact kernel headers and configuration of the machine it will load on. For years the entire kernel side of NVIDIA's driver shipped as a binary blob, which meant that when a new kernel changed an internal API, users waited for NVIDIA to rebuild rather than rebuilding themselves.

This repository is the source release of that kernel side. It targets people who need to build the driver against a kernel NVIDIA has not shipped a binary for, and people who want to read or modify the code that runs in kernel space. It is version 615.71.09, and the README states the modules can be used on any Turing or later GPU. Pre-Turing cards are outside the scope, and the README points at the proprietary modules for that range.

## OS-agnostic code versus the kernel interface layer

The architecture is a two-part split, and the split is not symmetric. Each module is divided into an OS-agnostic component and a kernel interface layer. The OS-agnostic part is the bulk of the driver logic and does not depend on the operating system. The kernel interface layer is the thin part that talks to Linux, and it has to be built for the target kernel version and configuration.

The asymmetry shows up in what ships as source. In the .run installer, the OS-agnostic component is a prebuilt binary because it is large and slow to compile: for nvidia.ko that file is nv-kernel.o_binary, and for nvidia-modeset.ko it is nv-modeset-kernel.o_binary. The top-level Makefile encodes this directly. It builds src/nvidia/nv-kernel.o, then symlinks it into kernel-open/nvidia/nv-kernel.o_binary, and does the same for the modeset object. nvidia-drm.ko and nvidia-uvm.ko have no OS-agnostic component at all.

The directory layout follows the same line. kernel-open/ holds the kernel interface layer, with subdirectories for nvidia, nvidia-drm, nvidia-modeset and nvidia-uvm. src/ holds the OS-agnostic code, with src/nvidia, src/nvidia-modeset and src/common for utility code shared by nvidia.ko and nvidia-modeset.ko. A separate nouveau/ directory holds tools for Nouveau integration: a Python script that extracts firmware binary images encoded in the source and writes them as distinct files for the Nouveau driver to load and talk to the GSP firmware. The layout of those files is described in nouveau_firmware_layout.ods.

## Building the modules from source

The README gives the build in two commands. Running make modules compiles the modules with all available cores, and the Makefile's top-level target is modules, with all as an alias for it. The build produces the OS-agnostic objects first, then relinks them into the kernel-open tree as the expected _binary files.

```bash
make modules -j$(nproc)
```

Two build variables change the output. NV_VERBOSE=1 prints each complete command instead of the succinct CC line, and DEBUG=1 builds the modules with debug information and enables debug log messages inside them. Both go on the make command line.

```bash
make modules -j$(nproc) NV_VERBOSE=1
```

Cross-compilation is supported for x86_64 and aarch64. The README's example compiles on x86_64 for aarch64 by setting TARGET_ARCH, ARCH and the toolchain variables CC, LD, AR, CXX and OBJCOPY.

```bash
make modules -j$(nproc)         \
    TARGET_ARCH=aarch64         \
    ARCH=arm64                  \
    CC=aarch64-linux-gnu-gcc    \
    LD=aarch64-linux-gnu-ld     \
    AR=aarch64-linux-gnu-ar     \
    CXX=aarch64-linux-gnu-g++   \
    OBJCOPY=aarch64-linux-gnu-objcopy
```

One constraint is easy to miss: the README states that the kernel interface layers must be built with the toolchain that built the kernel. Any reasonably modern GCC or Clang works for the rest, but a mismatch on the interface layer is not a supported configuration. The modules support Linux kernel 4.15 or newer, the same range as the proprietary modules.

## Installing and pairing with user space

The README says to uninstall any existing NVIDIA kernel modules first, then install as root with make modules_install. The -j$(nproc) flag is shown in the README's install line as well.

```bash
make modules_install -j$(nproc)
```

The part that trips people up is the version contract. The README states that the modules built here must be used with GSP firmware and user-space NVIDIA GPU driver components from a corresponding 615.71.09 driver release. The recommended route is to install the user-space driver from the .run file with the --no-kernel-modules option, so the installer skips its own kernel modules and leaves yours in place.

```bash
sh ./NVIDIA-Linux-[...].run --no-kernel-modules
```

Mixing a source-built module with user-space components from a different driver version is not described as supported. If you build from this tree, treat the driver version as a matched pair.

## The contribution model limits what a fork can do

This is the section that decides whether the project fits you. The README is unusually direct about it: the code base is shared with NVIDIA's proprietary drivers, and various processing runs on the shared code to produce what is published here. The consequences are listed plainly. The repository functions mostly as a snapshot of each driver release. Revision history for individual changes is not expected to be available, and there will likely be only one git commit per driver release. Individual contributions may not be reflected as separate commits. Because contributions require manual merging into the shared code base, large refactoring changes may be difficult to accept, and the README asks that you contact NVIDIA in advance to coordinate them.

So the practical shape of the project is a per-release source drop, not a development branch you can track commit by commit. If your workflow assumes reviewing upstream history to find when a regression landed, this repository will not give you that. Pull requests are accepted through GitHub and require accepting a Contributor License Agreement. Issues specific to the open modules go in the repository's Issues section, and the README also lists the developer forum and linux-bugs@nvidia.com as reporting venues. Security reports have a separate SECURITY.md.

## Nouveau as the alternative path

The alternative is Nouveau, the in-tree Linux driver, and the relationship is closer than a typical competitor comparison. This repository ships a nouveau/ directory with a Python script that extracts firmware binary images and related data encoded in the source and stores them as separate files, which the Nouveau driver then uses to load and communicate with the GSP firmware. The binary file layout is documented in nouveau_firmware_layout.ods.

The difference in approach is where the driver lives and who maintains it against kernel changes. Nouveau is part of the kernel tree, so it moves with kernel releases. The NVIDIA open modules are built out of tree against a specific driver version and must match that version's user-space components and GSP firmware. If you want a driver that follows the kernel rather than the driver release, Nouveau is the one that does. If you need the feature set and firmware pairing described for Turing and later cards, the open modules are the path the README describes.

## Licence and what the repository metadata does not state

The repository carries a COPYING file at the top level, and the metadata shown for the repository does not resolve to a standard SPDX identifier. That matters if you plan to redistribute a rebuilt module or ship it inside a product image: the terms are in COPYING, and the metadata alone will not tell you what they permit. Read the file itself rather than relying on a package manager's licence tag.

The upgrade cost follows from the version contract rather than the licence. Because the modules must match the user-space driver and GSP firmware of the same release, upgrading is a paired operation: build the new modules, install the matching user-space components, and keep the versions aligned. The README does not document a rollback procedure, so plan how you will return to a working pair before you replace one.

## Conclusion

Adopt this if you run Turing or newer hardware on Linux 4.15 or later and you want to read the kernel interface layer, patch it, or build it against your own kernel. Do not adopt it if you are on pre-Turing hardware, or if you expected an upstreamable driver: the README states the repository is mostly a snapshot per driver release, with one commit per release and no per-change history, and large refactors require coordinating with NVIDIA in advance. Before building, verify that your GPU appears in the compatible GPU table and that you have a matching 615.71.09 user-space driver, because the README ties the modules to that exact release. Check the COPYING file too, since the licence is not stated as a standard SPDX identifier in the repository metadata.

## FAQ

### What is a GPU kernel?

The README does not define the term. What it does describe is the kernel interface layer of each NVIDIA module, which is the part built for the target Linux kernel version and configuration.

### What does a kernel module do in the NVIDIA open GPU kernel modules?

Each module is split into an OS-agnostic component and a kernel interface layer. The interface layer is built for the target Linux kernel, while the OS-agnostic part is the driver logic that does not depend on the operating system.

### What are NVIDIA kernel modules?

They are the parts of the NVIDIA GPU driver that run inside the Linux kernel, such as nvidia.ko, nvidia-modeset.ko, nvidia-drm.ko and nvidia-uvm.ko. This repository publishes the source for those modules.

## Sources

- [Issues](https://github.com/NVIDIA/open-gpu-kernel-modules/issues)
- [NVIDIA/open-gpu-kernel-modules on GitHub](https://github.com/NVIDIA/open-gpu-kernel-modules)
- [README](https://github.com/NVIDIA/open-gpu-kernel-modules/blob/main/README.md)
- [Releases](https://github.com/NVIDIA/open-gpu-kernel-modules/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/nvidia-open-gpu-kernel-modules