NVIDIA Linux Drivers: Open Modules, GSP Firmware, and the Road to Blackwell

For a long time, running NVIDIA hardware on Linux meant accepting a binary blob -- a closed-source kernel module you could not inspect, patch, or fully trust. Distribution maintainers had to ship it under special licenses, users had to manually accept EULAs, and every kernel update risked breaking the driver entirely until NVIDIA published a compatible build. The Linux community grumbled. Linus Torvalds famously made his views on binary-only kernel modules clear. And nothing changed for years.

It helps to understand what was actually at stake. A kernel module runs in ring 0 -- the highest privilege level on the processor. A bug in a closed-source kernel module cannot be patched by the distribution, cannot be audited by the security community, and cannot be fixed by anyone except the vendor. When that module is a GPU driver used by tens of millions of machines, the exposure surface is enormous. The friction was not just philosophical; it was architectural.

Then in May 2022, NVIDIA flipped the switch. The company published its Linux GPU kernel modules as open source under a dual GPL/MIT license, starting with the R515 driver release. That decision set off a chain of architectural changes that is still playing out today, culminating in the R590 series dropping support for Pascal and older hardware entirely and making the open kernel module the default across Arch Linux, Ubuntu, and every major distribution that has followed suit.

This article traces the full arc of that story -- the technical reasons behind it, what the GPU System Processor (GSP) firmware architecture means for your system, what changed in the latest 590 driver series, how Wayland support finally stabilized, and what the Nova driver project in the upstream Linux kernel signals about where this is all heading.

The R515 Open-Source Release: What Actually Happened

NVIDIA's May 2022 announcement was more surgical than a full open-sourcing. The company published the kernel modules -- the code that runs inside the Linux kernel space -- under a dual GPL/MIT license. The user-space components of the driver, including the OpenGL and Vulkan libraries, remained closed-source binaries. This distinction matters and has since drawn criticism from parts of the community.

The open kernel modules shipped in two "flavors," a term NVIDIA uses in its documentation. The proprietary flavor is the historical default -- the one NVIDIA has shipped since its earliest Linux drivers. The open flavor is the newly published source, dual-licensed, and built on a fundamentally different internal architecture. Both flavors use the same user-space components; only the kernel-side code differs.

In the NVIDIA Technical Blog post announcing the release, the company framed the decision as a step toward tighter kernel integration and a platform for developer contribution -- describing it as "a significant step toward improving the experience." (NVIDIA Technical Blog, May 2022)

The initial release supported Turing and Ampere GPUs at production quality for datacenter compute workloads. Support for GeForce and Workstation GPUs was described as alpha-quality, with missing features including G-SYNC, Quadro Sync, SLI, and certain Wayland configurations. NVIDIA was direct about this: the open modules needed to mature before they could fully supplant the closed-source driver on consumer hardware.

The reaction from the Linux ecosystem was broadly positive but qualified. Canonical's VP of Silicon Alliances, Cindy Goldberg, called it a simplification for Ubuntu users "whether they're AI/ML developers, gamers, or cloud users." Julia Computing's CTO Keno Fischer called it "long time coming, but absolutely the right move." Some community members were more skeptical, noting that the open-source kernel code still relies on closed-source functions in the GPU firmware, making the gesture less complete than it might appear on the surface.

The GSP Architecture: Why Turing is the Hard Floor

Understanding why the open kernel modules only support Turing and newer GPUs requires understanding what the GPU System Processor (GSP) is and what it does.

The GSP is a dedicated processor embedded in NVIDIA GPUs starting with the Turing architecture (released in September 2018). According to NVIDIA's official driver documentation, the GSP "can be used to offload GPU initialization and management tasks" that were previously handled by the CPU through the kernel driver. The GSP is driven by firmware files distributed with the driver, stored at paths like /lib/firmware/nvidia/ and loaded at driver initialization.

The open kernel modules are architecturally dependent on the GSP. The operations that the closed-source kernel module performs in CPU-side code are, in the open module, delegated to GSP firmware instead. This means the open driver cannot function at all on hardware that lacks a GSP -- which is everything older than Turing. Maxwell, Pascal, and Volta GPUs simply do not have the hardware, so there is no path to open-module support for them regardless of driver version.

This architecture has a meaningful security implication. When the GSP handles GPU initialization, the CPU-side kernel code becomes significantly simpler and more auditable. The complex, proprietary initialization logic that used to live in the closed-source kernel module is now in the GSP firmware -- still not open source, but moved off the critical path of Linux kernel security review. It is a tradeoff, not a solution, but it is a meaningful architectural shift.

The tradeoff deserves closer inspection than it usually receives. Moving opaque initialization logic from the kernel module into GSP firmware does reduce the kernel attack surface -- there is less privileged CPU-side code that can be exploited through a malformed GPU response. But it does not eliminate the trust boundary; it relocates it. The GSP firmware blob running on a dedicated RISC-V processor inside the GPU operates with hardware-level access to GPU memory, PCIe bus transactions, and potentially system memory through DMA. If that firmware contains a vulnerability -- or deliberately malicious behavior -- it runs below the visibility of any kernel introspection tool, any hypervisor, any security audit. From a threat modeling perspective, moving attack surface from kernel space into firmware is an improvement for casual adversaries and a lateral shift for sophisticated ones. Users in high-assurance environments should be clear-eyed about what the open module transition does and does not change.

The practical corollary is that the open kernel modules are a meaningful improvement for the common case -- development workstations, gaming systems, ML clusters -- while the deeper trust question around GSP firmware remains unresolved and is not addressable within the current NVIDIA driver architecture. Nova, discussed later, represents one long-term path toward that resolution by building a driver whose full call graph can eventually be audited in mainline Linux.

In May 2025, NVIDIA supplied updated GSP firmware derived from its R570 driver series to the upstream linux-firmware.git repository for use by the Nouveau driver. According to Phoronix, this updated firmware was specifically intended to support on-going Hopper and Blackwell GPU upstreaming in the open-source Nouveau driver stack, enabling those architectures in community-maintained code for the first time.

The R560 Transition Announcement and the Path to Default

Two years after the initial open-source release, NVIDIA published a second landmark post on its Technical Blog in July 2024 announcing it was transitioning fully toward the open-source GPU kernel modules. The announcement named the upcoming R560 driver release as the point at which NVIDIA would make the open modules the recommended default for Turing, Ampere, Ada Lovelace, and Hopper architecture GPUs.

The company cited equivalent or better application performance as the key milestone that made the transition appropriate. According to the NVIDIA Technical Blog post by Rob Armstrong, Kevin Mittman, and Fred Oh, the open-source GPU kernel modules had also added substantial new capabilities during those two years, including heterogeneous memory management (HMM) support, confidential computing, and coherent memory architectures -- features that depend on the tighter kernel integration that the open-source approach enables.

The performance parity claim warrants unpacking. The operations that moved from CPU-side kernel code to GSP firmware include GPU initialization, power management state transitions, and certain memory management tasks. Early versions of the open module introduced latency in some of those transitions because the GSP firmware had to handle requests that the proprietary kernel code had previously managed inline with full CPU cache coherency. By R560, that latency overhead was sufficiently reduced across the Turing-through-Hopper generation that NVIDIA felt confident calling it equivalent. On Blackwell, the GSP firmware and kernel interface were co-designed from the start, which is part of why Blackwell can be open-module-only without a performance asterisk.

For Blackwell GPUs -- the RTX 50 series -- the announcement was unambiguous: the open kernel modules are the only supported option. The closed-source kernel module is not being extended to Blackwell. If you have an RTX 5080, RTX 5090, or any other Blackwell card, you are running the open module whether you configured it explicitly or not.

What Changed in the R590 Series

The R590 driver series entered public beta on December 2, 2025 as 590.44.01 and shipped its stable release on December 18, 2025 as 590.48.01. This is where several threads converged. Pascal, Maxwell, and Volta support were formally dropped from the main branch. The open kernel module became the default on distributions that had not already made the switch. And Wayland support received meaningful improvements that addressed long-standing complaints.

According to the beta changelog on the NVIDIA developer forums and 9to5Linux's coverage of the 590.44.01 beta release, the driver raises the minimum supported Wayland version to 1.20. It also raises the minimum supported glibc version to 2.27. It fixes a bug that prevented the PowerMizer preferred mode dropdown in nvidia-settings from functioning correctly on Wayland. It improves Vulkan swapchain recreation performance, which translates directly to reduced stuttering when resizing Vulkan application windows. It also resolves several issues that had prevented Vulkan applications from running on the Venus VirtIO virtual GPU stack.

On the system stability side, the R590 series fixed a bug that could cause system freezes on PREEMPT_RT kernels -- a significant issue for users running real-time Linux configurations for audio production, robotics, or low-latency workloads. It also corrected incorrect DPI reporting for certain monitors including the Samsung Odyssey Neo G9.

Arch Linux announced on December 20, 2025 that it was transitioning its main NVIDIA driver packages to use the open kernel modules as the default, coinciding with the R590 series. The official announcement confirmed that users with Turing (RTX 20xx and GTX 1650 series) and newer GPUs would move to the open kernel modules automatically on upgrade, with no manual steps required. The package rename from nvidia to nvidia-open, nvidia-dkms to nvidia-open-dkms, and nvidia-lts to nvidia-open-lts formalized what had been an optional configuration into the distribution default. Users on Pascal, Maxwell, or Volta hardware who updated without reading the announcement found their graphical environment broken -- the announcement included explicit intervention steps to switch to the AUR legacy packages.

What Is Coming in R595

The R590 series is not the final word. On March 5, 2026 -- two and a half months after R590 shipped stable -- NVIDIA released the 595.45.04 beta driver for Linux, marking the first public release in the R595 series. It is in beta as of this writing, but the changes it introduces are worth knowing about, both because several of them close longstanding Linux-specific gaps and because the pace of releases signals NVIDIA's current investment level in the platform.

The headline additions in R595 are two new Vulkan extensions. VK_EXT_descriptor_heap allows applications to store buffer and image descriptors directly into GPU-accessible memory, reducing CPU overhead on descriptor management -- a common bottleneck in high-draw-call workloads. VK_EXT_present_timing allows applications to query detailed timing information about past frames and specify a target presentation time for future ones, which benefits both gaming (smoother frame pacing) and video playback applications on Wayland.

R595 also adds support for DRI3 version 1.2. DRI3 is the kernel-to-userspace interface for Direct Rendering Infrastructure, and the 1.2 revision introduces DMA Fence support -- a Linux kernel synchronization mechanism that improves buffer hand-off coordination between the driver and compositors. In practical terms, this is another layer of the explicit synchronization story that Explicit Sync started: more of the frame pipeline is now synchronized through kernel-verifiable fences rather than driver-internal mechanisms.

Two other changes in R595 are worth noting for specific use cases. A new application profile called CudaNoStablePerfLimit allows CUDA applications to reach the P0 power state -- the highest performance and power level -- which was previously unavailable to CUDA workloads on Linux without manual intervention. And the handling of video memory preservation during system suspend and resume was updated: when using the open kernel modules with NVreg_UseKernelSuspendNotifiers=1 enabled, the driver now handles VRAM preservation automatically during suspend cycles, which matters for laptop users and systems with power management requirements.

R595 remains in beta as of late March 2026. The stable release timeline has not been announced, but based on the R590 beta-to-stable cycle (approximately 16 days), stable availability is plausible by mid-April 2026. Until then, R590.48.01 remains the recommended stable driver for production systems.

Wayland Support: A Long Road to Stability

The history of NVIDIA and Wayland on Linux is a story of slow, incremental progress against a backdrop of community frustration. For years, NVIDIA's proprietary driver stack lagged behind the open-source AMD and Intel drivers in Wayland compatibility because of NVIDIA's historically proprietary approach to kernel mode setting and buffer sharing.

The critical architectural fix arrived with the R555 series, which added support for the linux-drm-syncobj-v1 protocol for explicit synchronization in EGL. According to the Arch Linux wiki, prior to driver version 555.xx (or when using a Wayland compositor that does not support Explicit Sync via that protocol), the NVIDIA driver was prone to serious rendering problems in both native Wayland and Xwayland sessions, including flickering and frames appearing out of order. Explicit Sync was the technical root cause of years of Wayland complaints.

DRM kernel mode setting, required for all Wayland configurations to function properly, is now enabled by default as of nvidia-utils 560.35.03-5. Before version 560, users had to manually set the modeset=1 kernel module parameter for the nvidia_drm module, either in /etc/modprobe.d/ or as a kernel command-line parameter.

The R590 series continued this trajectory by raising the minimum Wayland version to 1.20, which was released in 2022. Any system running a modern compositor -- GNOME Shell, KDE Plasma, Sway, Hyprland -- will comfortably meet this requirement. The bump in minimum version allows the driver to rely on protocol features that were previously treated as optional, resulting in a cleaner and more consistent implementation. If you are setting up a desktop environment on Arch Linux with an NVIDIA card, the Arch desktop environment guide covers the full configuration process including the Wayland-specific steps.

What Happens to X11 and Xorg

The article to this point has focused on Wayland, which is where active development is happening. But a meaningful number of NVIDIA Linux users are still on X11 -- because of specific applications that do not support Wayland, because of multi-monitor setups with mixed refresh rates that Wayland compositors handle inconsistently, or simply because X11 has worked reliably for years and there has been no compelling reason to change. The question of what happens to X11 support under the open kernel module transition deserves a direct answer.

X11 and Xorg remain fully supported as of R590 and R595. Nothing in the open module transition changes X11 support for currently supported hardware. The Xorg DDX driver (xorg-x11-drv-nvidia on Fedora, xserver-xorg-video-nvidia on Ubuntu) is a user-space component and is independent of whether the kernel module is the open or proprietary flavor. You can run the open kernel module with an X11 session without any special configuration.

The longer-term picture is less settled. NVIDIA has been progressively investing in Wayland at the protocol level, and the explicit synchronization work in R555 and R560 was explicitly motivated by Wayland rather than X11. NVIDIA has not announced a deprecation timeline for Xorg support, and X11 continues to be tested and supported in every release. However, the weight of development effort has clearly shifted. New features -- VK_EXT_present_timing, the DRI3 1.2 additions in R595, improvements to Wayland compositor interaction -- are Wayland-first or Wayland-only.

For users whose workflows depend on X11-specific features -- NVIDIA G-SYNC with certain monitor configurations, specific GLX extensions, or applications that explicitly require Xorg -- the current picture is stable. There is no imminent disruption. But the direction of investment is worth tracking, particularly if you are planning hardware or distribution choices that will persist for several years.

Checking What You Are Running

One practical consequence of the open/proprietary split is that it is now worth knowing which driver flavor is actually loaded on your system. NVIDIA provides two straightforward ways to check.

# Method 1: modinfo shows the license field
$ modinfo nvidia | grep license
# Proprietary output:
license:  NVIDIA
# Open module output:
license:  GPL and additional rights

# Method 2: Read the driver version file directly
$ cat /proc/driver/nvidia/version
NVRM version: NVIDIA UNIX x86_64 Kernel Module  590.48.01  ...

# Check GSP firmware status for a specific GPU
$ nvidia-smi -q | grep "GSP Firmware"
GSP Firmware Version              : 590.48.01
# N/A here means GSP is not active (proprietary driver, older GPU, or disabled)

The GSP firmware version matching the driver version confirms that firmware-based GPU management is active. On systems where GSP is not being used -- older GPUs, or the proprietary driver with NVreg_EnableGpuFirmware=0 -- the GSP firmware field will show N/A.

For installations on systems running AI workloads, verifying the driver version and CUDA compatibility is equally important. NVIDIA's datacenter driver documentation for the 590.48.01 release confirms CUDA 13.x support for Maxwell through Blackwell architectures. The guide to running AI workloads on Linux covers the full environment setup including driver verification and container runtime configuration.

Installing the Right Driver by Distribution

The installation path varies meaningfully across distributions. Here is the current recommended approach for the three most common scenarios as of early 2026.

Arch Linux

As of the R590 transition, Arch Linux users with Turing or newer GPUs should install nvidia-open for the running kernel, nvidia-open-dkms for DKMS-managed builds across multiple kernels, or nvidia-open-lts for the LTS kernel. Pascal and older users must install nvidia-580xx-dkms from the AUR. The Arch Linux wiki's NVIDIA article is the authoritative reference for edge cases including Intel 11th Gen IBT incompatibility (ibt=off) and Nova driver conflicts.

# For standard kernel
$ sudo pacman -S nvidia-open nvidia-utils

# For DKMS (multiple kernels)
$ sudo pacman -S nvidia-open-dkms nvidia-utils

# Rebuild initramfs after install
$ sudo mkinitcpio -P

Ubuntu / Debian

Ubuntu includes NVIDIA drivers in the ubuntu-drivers tool. The ubuntu-drivers autoinstall command will select the recommended driver for your hardware. For manual control, the graphics-drivers PPA provides current release branches. Note that Debian does not support PPAs -- Debian 13 "Trixie," based on Linux 6.12 LTS, includes updated NVIDIA packages in the non-free-firmware repository.

# Automatic recommended driver selection
$ sudo ubuntu-drivers autoinstall

# Or install a specific open-module version explicitly
$ sudo apt install nvidia-open-590

# Verify after reboot
$ nvidia-smi

Fedora

Fedora users access NVIDIA drivers through RPM Fusion. The akmod-nvidia-open package provides the open kernel module with automatic kernel module rebuilding via akmods. For a full GPU driver and gaming setup, the Fedora gaming optimization guide covers the complete process including Steam, Lutris, and GPU driver configuration end to end.

# Enable RPM Fusion if not already done
$ sudo dnf install \
  https://mirrors.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm \
  https://mirrors.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-$(rpm -E %fedora).noarch.rpm

# Install open kernel module
$ sudo dnf install akmod-nvidia-open xorg-x11-drv-nvidia-cuda

# Wait for kmod build to complete, then reboot
$ sudo akmods --force && sudo dracut --force && sudo reboot

What to Do When a Driver Update Breaks Something

The R590 series introduced a hard upgrade hazard for Pascal and older users on Arch Linux who were not watching release announcements. But driver regressions are not unique to major generational cuts -- any driver update can introduce issues specific to your GPU model, compositor, or application stack. The article has covered installation, but it has not covered the equally practical question of what to do when an update causes problems.

Pinning the Driver on Arch Linux

Arch Linux does not provide a formal package pinning mechanism, but you can prevent a specific package from being upgraded by adding it to the IgnorePkg list in /etc/pacman.conf. To hold the current NVIDIA driver version:

# Hold nvidia-open and nvidia-utils at their current versions
IgnorePkg = nvidia-open nvidia-utils

pacman will warn you that the packages are being skipped during system upgrades. Remove the line when you are ready to update again. Note that holding the driver too long relative to kernel updates can cause incompatibilities if the driver cannot compile against a significantly newer kernel; DKMS will report the failure clearly when this happens.

Downgrading on Ubuntu and Debian

On Ubuntu, you can pin a specific driver version using apt-mark hold:

# Hold the current installed version
$ sudo apt-mark hold nvidia-open-590 nvidia-utils-590

# To revert to a previous version if already upgraded
$ sudo apt install nvidia-open-590=590.48.01-0ubuntu1

# Verify what is held
$ apt-mark showhold

Diagnosing Driver Issues

When a driver update causes instability, the fastest diagnostic path is to check the kernel ring buffer for NVIDIA-related messages immediately after the issue occurs. dmesg | grep -i nvidia will surface module load errors, GSP firmware failures, and DRM initialization problems. If GSP firmware fails to load, the output will show an explicit error from nvidia-drm or the nvidia module. A GSP firmware version mismatch between the kernel module and the firmware files in /lib/firmware/nvidia/ is a common cause of breakage after partial upgrades where the kernel module updated but the firmware package did not.

The deeper diagnostic pattern is to think in terms of the four layers that must be mutually consistent after any NVIDIA driver update: the kernel module version, the GSP firmware files in /lib/firmware/nvidia/, the user-space libraries in nvidia-utils, and the DKMS-built module version recorded in /var/lib/dkms/. A mismatch at any of these four layers produces symptoms that look similar -- a black screen, a compositor crash, a CUDA initialization failure -- but have different root causes and different fixes. Checking version alignment across all four before assuming a "bad driver" is the correct diagnostic sequence. A version mismatch between the kernel module and nvidia-utils, for instance, resolves with a reboot after ensuring all packages updated together. A DKMS build failure requires rebuilding with dkms autoinstall and checking compiler output for the specific kernel ABI incompatibility. A GSP firmware mismatch requires verifying that the linux-firmware package version matches what the driver expects, which occasionally lags behind on rolling distributions if the firmware repository is not synchronized with the driver repository.

The Nouveau / NVK Alternative

Parallel to NVIDIA's official driver story is the continued development of the open-source Nouveau driver and its Mesa-based Vulkan implementation, NVK. For users who want a fully upstream, fully open stack with no proprietary components whatsoever, this is the relevant track to watch.

Nouveau has historically suffered from poor performance on modern hardware because NVIDIA did not publish the clock frequency management tables needed for the driver to run GPUs at full speed. That barrier partially shifted with Turing and the GSP firmware: Nouveau gained access to NVIDIA-supplied GSP firmware blobs that enable automatic GPU reclocking on Turing and newer hardware. According to the Nouveau project's official documentation, automatic reclocking is available for Turing and newer GPUs through GSP firmware as of the current upstream kernel.

NVK, the Mesa Vulkan driver for NVIDIA hardware, advanced significantly through 2025. In April 2025, Mesa 25.1 extended NVK support to Maxwell, Pascal, and Volta GPUs, and made Zink+NVK the default OpenGL path for Turing and newer, replacing the old Nouveau GL driver. Then in August 2025, Mesa 25.2 extended NVK further to Blackwell and Kepler GPUs. According to the official Nouveau project page at nouveau.freedesktop.org, these milestones represent NVK now supporting the same range of desktop GPU generations that NVIDIA's proprietary driver has covered. On Blackwell, NVK delivers Vulkan 1.4 conformance; Kepler is limited to Vulkan 1.2 due to hardware constraints. The practical implication is that the RTX 50 series can be driven entirely by open-source code within the Mesa stack -- no proprietary components required. For context on how Arch Linux's rolling release model handles driver stack updates like these, the Arch Linux overview covers the distribution's update philosophy end to end.

Understanding where the remaining performance gap comes from requires looking at what the proprietary driver does that NVK currently cannot. The largest category is shader compilation. NVIDIA's proprietary driver compiles GLSL and SPIR-V shaders with a backend that has been tuned over years to exploit undocumented microarchitectural features of each GPU generation -- register bank conflict avoidance, specific warp scheduling heuristics, instruction pairing rules that the public ISA documentation does not fully describe. NVK compiles to a publicly documented target and cannot exploit those microarchitectural details without either reverse engineering or additional firmware cooperation. This is not a temporary gap that additional engineering effort alone can close; it is a structural consequence of compiling against a documented target versus an intimately known proprietary one. The gap narrows as NVIDIA provides more documentation -- which the Nova co-maintainership arrangement may gradually enable -- but it will not disappear entirely on the current architecture.

For workloads where NVK has achieved or nearly achieved parity -- general Vulkan applications, compute shaders that map cleanly to the documented ISA, compositing and desktop rendering -- the fully open stack is a legitimate choice. For workloads that depend on maximum shader throughput, ray tracing performance, or CUDA (which has no open-source equivalent), the proprietary driver remains the only option.

Performance and compatibility on NVK varies relative to the official NVIDIA driver stack. For gaming and general consumer use, the official driver remains the performance-optimal choice on modern hardware. NVK is the correct path when proprietary components are unacceptable on principle, or for workloads where it has achieved parity -- and that class of workloads is expanding with each Mesa release.

The Nova Driver: Rust, Upstream, and the Future

The most technically forward-looking development in the NVIDIA Linux driver space is the Nova driver project, which represents an entirely different approach from anything discussed so far.

Nova is a new GPU driver written in Rust, developed for inclusion in the upstream Linux kernel. It is not a fork or replacement of the official NVIDIA driver stack. It is intended to eventually supersede the reverse-engineered Nouveau driver for GSP-capable hardware -- which means Turing and newer. The project consists of two components: nova-core, which handles GPU initialization and management via GSP firmware, and nova-drm, which handles the DRM (Direct Rendering Manager) interface.

According to the Rust for Linux project documentation, Nova is intended to "supersede the nouveau driver for NVIDIA GPUs based on the GPU System Processor." Danilo Krummrich of Red Hat submitted the initial pull request in March 2025, and the nova-core component was officially merged into Linux kernel 6.15 on May 25, 2025 -- making it the first Rust-written Direct Rendering Manager driver accepted into the kernel mainline. The initial submission consisted of approximately 1,207 lines of code, of which around 700 were Rust and the remainder early project documentation including an extensive TODO list. The code now lives in drivers/gpu/nova-core/ and drivers/gpu/drm/nova/ in the upstream kernel tree.

An NVIDIA engineer became co-maintainer of Nova during 2025, as documented by Phoronix as one of the year's defining NVIDIA Linux developments. This level of direct involvement signals NVIDIA's endorsement of the Rust-based upstream approach as a long-term path -- a company that a decade ago resisted open kernel modules is now co-maintaining the upstream Rust driver intended to replace its own reverse-engineered predecessor.

The choice of Rust as Nova's implementation language aligns with the broader trend of Rust adoption in the Linux kernel. Rust's memory safety guarantees are particularly valuable in kernel driver code, where buffer overflows and null pointer dereferences have historically been sources of privilege escalation vulnerabilities. For a system that needs to interact with GPU hardware at the lowest level, those guarantees are not theoretical -- they are practically significant for anyone running NVIDIA hardware in security-sensitive environments.

To understand why this matters specifically for a GPU driver, consider what a GPU driver does at the kernel level: it manages DMA mappings between system RAM and GPU VRAM, it handles GPU command buffer submission from unprivileged userspace applications, and it arbitrates access to shared GPU resources across multiple processes. Each of those operations involves memory that is simultaneously visible to the CPU, the GPU, and potentially other PCIe devices. A use-after-free or double-free in that code can expose arbitrary kernel memory to a userspace process, or allow a malicious application to craft GPU commands that corrupt memory belonging to another process. These vulnerabilities have appeared in GPU drivers across vendors -- including NVIDIA's proprietary driver -- precisely because the combination of shared memory, asynchronous hardware, and complex state machines is among the hardest patterns to implement safely in C. Rust's ownership model eliminates the class of errors that makes that combination dangerous, at compile time, without runtime overhead. For Nova, this means that a conformance test suite can eventually verify not just that the driver produces correct output, but that it cannot produce the class of memory safety violations that the Linux security community has historically needed to patch out-of-band.

The connection between driver-level security and the broader Linux security posture is worth understanding, and the Linux kernel tuning guide provides relevant context on kernel parameter management that applies to driver configuration as well.

How to Verify Your NVIDIA Driver Setup on Linux

Step 1: Identify Your GPU Generation

Run nvidia-smi or lspci | grep -i nvidia to confirm your GPU model. Turing covers RTX 20xx and GTX 1650/1660 series. Ampere covers RTX 30xx. Ada Lovelace covers RTX 40xx. Blackwell covers RTX 50xx. Pascal (GTX 10xx), Maxwell (GTX 900 series), Volta (Titan V), and older require the legacy proprietary branch and will not work with the R590 main driver. If you are unsure of your GPU's architecture, cross-reference the model number against Nouveau's GPU code name table or NVIDIA's own product pages.

Step 2: Install the Correct Driver Package

On Arch Linux with a Turing or newer GPU, install nvidia-open or nvidia-open-dkms. On Ubuntu, use ubuntu-drivers autoinstall or install a specific nvidia-open-XXX package. On Fedora, use akmod-nvidia-open from RPM Fusion. After installation, rebuild your initramfs (Arch: mkinitcpio -P; Ubuntu/Debian: update-initramfs -u; Fedora: dracut --force) and reboot.

Step 3: Verify GSP Firmware and DRM Mode Setting

After rebooting, confirm GSP firmware is active with nvidia-smi -q | grep "GSP Firmware" -- the output should show the driver version number, not N/A. Verify DRM kernel mode setting with cat /sys/module/nvidia_drm/parameters/modeset -- it should return Y. If you are using Wayland, confirm your compositor version meets the R590 minimum of Wayland 1.20 with wayland-info --version or by checking your compositor's release notes.

Frequently Asked Questions

Do I need nvidia-open or the proprietary driver on a Turing or newer GPU?

As of the R590 driver series, NVIDIA recommends the open kernel modules for all Turing (RTX 20xx, GTX 1650, GTX 1660) and newer GPUs. For Blackwell (RTX 50xx), the open module is the only supported option -- the closed-source kernel module is no longer extended to that architecture. If you are on Pascal (GTX 10xx), Maxwell (GTX 900 series), or Volta (Titan V), you must use the legacy proprietary branch such as nvidia-580xx-dkms on Arch Linux. NVIDIA has committed to quarterly security updates for those architectures through October 2028.

What is GSP firmware and why does NVIDIA's open driver require it?

The GPU System Processor (GSP) is a dedicated processor embedded in Turing and newer NVIDIA GPUs. It offloads GPU initialization and management tasks from the CPU to firmware running directly on the GPU. The open kernel modules depend entirely on GSP to perform operations that were previously handled by closed-source kernel-space code, which is why the open modules only support Turing and newer hardware -- older GPUs simply do not have the GSP hardware.

What is the Nova driver and should I use it now?

Nova is a Rust-written open-source NVIDIA GPU driver developed for the upstream Linux kernel. Its initial nova-core component was merged into Linux kernel 6.15 in May 2025, making it the first Rust-written DRM driver accepted into the kernel mainline. It is intended to eventually supersede the reverse-engineered Nouveau driver for GSP-capable hardware (Turing and newer). As of early 2026, Nova is not production-ready and is not a replacement for the packaged NVIDIA driver stack. If your kernel is compiled with CONFIG_NOVA_CORE enabled, nvidia-utils will blacklist nova_core and nova_drm automatically to prevent conflicts.

What is NVK and how does it differ from the NVIDIA proprietary driver?

NVK is the Mesa Vulkan driver for NVIDIA hardware, developed as part of the open-source Nouveau stack primarily by Collabora's Faith Ekstrand and others. As of Mesa 25.2 (August 2025), NVK supports Kepler through Blackwell GPUs and is a conformant Vulkan 1.4 implementation for the hardware it supports. Starting with Mesa 25.1, Zink+NVK replaced the old Nouveau OpenGL driver as the default for Turing and newer GPUs. NVK is the correct choice for users who need a fully open-source, no-proprietary-component driver stack. For gaming and general consumer workloads on modern hardware, the official NVIDIA driver remains the performance-optimal choice -- but the gap has narrowed considerably over the past two years.

Is X11 still supported with the open kernel modules?

Yes. The open kernel module transition does not affect X11 compatibility. The Xorg DDX driver is a user-space component that operates independently of whether the kernel module is the open or proprietary flavor. X11 sessions work with the open kernel module without any special configuration. However, the R595 series raises the minimum supported Xorg version to 1.17; any distribution shipping Xorg 1.16 or older will need to update before upgrading to R595. NVIDIA has not announced a deprecation timeline for X11 support, but active development investment is concentrated on Wayland.

What should I do if a driver update breaks my system?

On Arch Linux, add the relevant nvidia packages to IgnorePkg in /etc/pacman.conf to prevent them from upgrading until the regression is fixed. On Ubuntu and Debian, use apt-mark hold on the driver packages. The first diagnostic step is always dmesg | grep -i nvidia immediately after the failure -- GSP firmware load errors, DRM initialization failures, and module version mismatches will surface there. A version mismatch between modinfo nvidia | grep version and the installed nvidia-utils package is the most common root cause of breakage after partial upgrades. Rebuilding the initramfs and rebooting resolves a large proportion of post-upgrade issues on all three major distributions.

The State of NVIDIA on Linux in 2026

The NVIDIA Linux driver story in 2026 is one of genuine, structurally significant change -- not marketing language. The open kernel modules have moved from alpha-quality curiosities to distribution defaults. Blackwell GPUs ship without any proprietary kernel-mode option. Wayland flickering, the most persistent practical complaint from desktop Linux users with NVIDIA hardware, was addressed at the protocol level with Explicit Sync and at the driver level with the R555 and R590 series improvements. The R590 series completed the generational cut: Pascal, Maxwell, and Volta users are now on the legacy branch, while everything from Turing forward runs the open module by default.

The R595 beta -- already public as of early March 2026 -- extends that work further with DRI3 1.2 support, two new Vulkan extensions that improve gaming and compute performance, and GPU reset capability while the DRM module is loaded. The pace of releases makes clear that the R590 transition was not a stopping point but a platform consolidation that made faster iteration possible. X11 remains fully supported but the development weight has shifted decisively toward Wayland; users building for the long term should plan accordingly.

The parallel open-source story is equally significant. Mesa NVK achieved Vulkan 1.4 conformance across all supported hardware, expanded to cover Kepler through Blackwell in a single release cycle, and became the default OpenGL path for Turing and newer via Zink. Nova entered the upstream Linux kernel as the first Rust-written DRM driver, with an NVIDIA engineer co-maintaining it. These are not experimental side projects -- they are the infrastructure that will define NVIDIA Linux support for the next decade.

The path ahead runs toward two convergent goals. On the official driver side, the open modules will continue to expand capabilities and close the gap between proprietary and open on older Turing-generation hardware where some features still lag. On the upstream kernel side, Nova represents a long-term bet on a Rust-written driver that can eventually be merged into mainline Linux without the out-of-tree friction that has defined the NVIDIA driver experience for decades.

Neither path is complete. The user-space components of the NVIDIA stack remain closed source. Nova is years from production readiness. GSP firmware itself is not open. But the trajectory is clear, and for a company that spent years as the canonical example of everything wrong with Linux driver support, the change in direction is worth acknowledging for what it is.

For the practical administrator or desktop user right now: if you have a Turing or newer GPU and are running a current distribution, you are likely already on the open kernel module whether you configured it or not. Verify it, confirm GSP firmware is active, confirm DRM modeset is enabled if you use Wayland, and know how to pin or downgrade if a future update causes a regression. The days of wrestling with NVIDIA drivers on Linux are not entirely over -- but they are measurably better than they were.

For deeper context on how kernel modules work in general and how the Linux kernel manages drivers and firmware at a lower level, the Linux firmware blobs guide covers what firmware blobs are, why they exist, and how the kernel loads them -- directly relevant to understanding the GSP firmware architecture described in this article. And if you are tuning a system that runs NVIDIA GPUs alongside demanding Linux kernel workloads, understanding the Linux kernel memory model provides the foundational context for how kernel-space driver code interacts with system memory.