Linux GPU Drivers: NVIDIA, AMD, and Intel Explained

For a long time, GPU drivers on Linux were a reliable source of frustration. NVIDIA required a proprietary blob that fought the kernel at every update. AMD's story was fragmented between a proprietary stack and a half-finished open-source one. Intel barely registered as a discrete GPU vendor. In 2026, that picture looks genuinely different. This guide covers where each vendor's driver stack stands today, how to install and verify drivers correctly, and what to watch for when things go wrong.

How Linux GPU Drivers Work

Linux graphics involves two layers that are easy to confuse. The kernel driver handles the low-level communication between the operating system and the GPU hardware -- memory management, command submission, power states, and display output via the Direct Rendering Manager (DRM) subsystem. Above it sits the userspace driver, which translates OpenGL, Vulkan, or compute API calls into GPU instructions.

On AMD and Intel, both layers are open-source and ship together through Mesa. On NVIDIA, the kernel module is now available in both proprietary and open-source variants, but the userspace components remain closed. Understanding this split matters when you are debugging a driver failure -- a crash in the kernel module looks very different from a Vulkan driver bug in Mesa.

Before touching any driver, identify what hardware you have and what the kernel has already loaded:

# List GPU hardware and bound kernel module
$ lspci -k | grep -A 2 -i vga

# Check DRM devices recognized by the kernel
$ ls /dev/dri/

# Confirm which OpenGL driver is active
$ glxinfo | grep "OpenGL renderer"

NVIDIA: Proprietary vs Open Kernel Module NVIDIA

NVIDIA's Linux driver situation has improved substantially since the open kernel module (OKM) was released in 2022 and has been maturing ever since. As of March 2026, the current production branch is 580.x, with 590.x as the latest feature branch. Starting with the 560 driver series, the open kernel module became the default and recommended option — NVIDIA's own installation guide confirms that as of the 560 series, the open kernel module is the default and recommended option for Turing and newer hardware. Maxwell, Pascal, and Volta owners face a harder situation: the 590 branch dropped all three architectures from active support, meaning those cards now require legacy community-maintained packages (such as nvidia-580xx-dkms from the AUR on Arch-based systems) and will no longer receive game-ready optimizations.

What changed with the open kernel module

The closed NVIDIA kernel module was notorious for fighting Linux's standard kernel interfaces. It bypassed DRM APIs, which is why NVIDIA GPUs historically could not use fbdev, had KMS (Kernel Mode Setting) disabled by default, and caused chaos with suspend/resume. The open kernel module changes this by registering properly with the DRM subsystem. It still ships with the same proprietary userspace components -- libGL, libvulkan, CUDA runtime -- but the kernel-facing code is now auditable and better maintained alongside kernel updates.

The fully open-source path: NVK and Nouveau

If you want a fully open-source NVIDIA stack with no proprietary components, that path now exists and is production-ready. NVK is an open-source Vulkan 1.4 driver for NVIDIA hardware in Mesa, developed primarily by Faith Ekstrand at Collabora. It reached stable status with Mesa 24.1 and ships by default in distributions that include it in their Vulkan driver list. Starting with Mesa 25.1, NVK combined with the Zink OpenGL-on-Vulkan layer is the default OpenGL implementation for Turing and newer GPUs -- replacing the old Nouveau GL driver on those architectures. The kernel side of this stack uses the nouveau kernel module rather than NVIDIA's open kernel module.

The tradeoffs are real. NVK does not provide CUDA, DLSS, or hardware ray tracing -- those require the proprietary driver stack. Gaming performance through NVK and DXVK is workable but trails the proprietary driver on demanding titles, particularly those relying on shader pre-compilation. For a desktop workstation, media workloads, or any setup where avoiding the proprietary blob is the priority, NVK is now a legitimate option.

Secure Boot and NVIDIA: why your driver installs but does not load

This is the failure mode that causes more confusion than any other NVIDIA issue on Linux. You install the driver, everything appears to succeed, you reboot -- and the GPU is still running Nouveau or falling back to software rendering. The culprit is almost always Secure Boot.

When Secure Boot is active, the UEFI firmware only loads kernel modules that are cryptographically signed by a trusted key. NVIDIA's kernel module is a third-party module and is not pre-trusted. The install process generates a Machine Owner Key (MOK) and signs the module with it, but the key itself must be enrolled in firmware before it will be accepted. That enrollment happens at a one-time prompt on the next reboot. If you miss that prompt -- by pressing the wrong button on the blue MOK Manager screen, or if you did not notice the screen at all -- the module will be built but the firmware will refuse to load it.

If you missed the MOK enrollment prompt, you can re-trigger it without reinstalling:

# Check whether Secure Boot is active
$ mokutil --sb-state
SecureBoot enabled

# Re-trigger MOK enrollment for the existing key
$ sudo update-secureboot-policy --enroll-key

# Alternative: import the MOK key directly (Ubuntu/Debian path)
$ sudo mokutil --import /var/lib/shim-signed/mok/MOK.der

# Reboot -- at the blue MokManager screen, select:
# "Enroll MOK" -> "Continue" -> "Yes" -> enter the password you set
# Do NOT select "Continue Boot" -- that skips enrollment
$ sudo reboot

# After reboot, verify the module loaded
$ lsmod | grep nvidia
$ nvidia-smi

Installing the NVIDIA driver on Ubuntu

# Let ubuntu-drivers recommend the right version
$ sudo ubuntu-drivers list
nvidia-driver-580-open
nvidia-driver-580

# Install the recommended open module version (OKM is default since 560.x)
$ sudo ubuntu-drivers install

# Or install the open module build manually with apt
$ sudo apt install nvidia-open-kernel-dkms nvidia-driver

# Reboot, then verify
$ nvidia-smi

NVIDIA and Wayland

The flickering and tearing that plagued NVIDIA GPUs under Wayland was caused by a missing explicit synchronization protocol. NVIDIA adopted linux-drm-syncobj-v1 in the 555 driver series, and the 570 and 580 series have refined it further. On GNOME 46 and KDE Plasma 6.1 and later, the experience is now comparable to X11 for standard desktop use. Some compositors and XFCE-based setups have reported regression issues with the 580 and 590 series -- if you hit compositor breakage, check whether your compositor's vertical blank mode conflicts with NVIDIA's settings before rolling back.

AMD: The All-In Open-Source Stack AMD

AMD's driver story is the simplest in 2026: everything is open-source and everything lives in the upstream kernel and Mesa. In May 2025, AMD announced it would begin officially supporting Mesa RADV as part of its packaged Radeon Software for Linux while dropping its proprietary OpenGL and Vulkan drivers from that package. On September 15, 2025, AMD formally confirmed the discontinuation of AMDVLK on its GitHub page. AMD's JianRong JIN announced that the company was unifying its Linux Vulkan driver strategy by ending the AMDVLK project and moving all official support to the Mesa RADV driver as the sole supported open-source Vulkan driver for Radeon graphics. That leaves AMDGPU (kernel driver) and RADV (Mesa Vulkan driver) as the entire stack. For most users on GCN 5 (Vega) and newer hardware, there is nothing to install -- the drivers ship with the kernel and Mesa packages on every major distribution.

The AMDGPU and RADV stack

AMDGPU is the kernel driver that handles hardware initialization, command scheduling, memory management, and power management. RADV is the community-maintained Vulkan driver inside Mesa that uses the ACO shader compiler. ACO compiles shaders faster than AMD's earlier LLVM compiler backend and consistently performs better in gaming workloads -- benchmarks on recent Ryzen hardware show RADV outperforming the old proprietary driver by measurable margins. For compute workloads, AMD provides the ROCm stack as a separate install on top of AMDGPU.

# Mesa ships by default -- verify it is current
$ glxinfo | grep "OpenGL renderer"
OpenGL renderer string: AMD Radeon RX 7800 XT (radeonsi, navi32, LLVM 18.1.8, DRM 3.59)

# For Vulkan, confirm RADV is the active driver
$ vulkaninfo | grep "driverName"
driverName = radv

# GPU monitoring (install via package manager)
$ sudo apt install radeontop
$ radeontop

ROCm for compute workloads

If you are running AI workloads or machine learning inference on Linux, AMD's ROCm platform installs on top of AMDGPU and provides a CUDA-compatible compute layer. AMD publishes a package repository and the amdgpu-install script for supported distributions. ROCm 7.2.0, released January 21, 2026, is the current production build and is supported on Ubuntu 22.04.3, Ubuntu 24.04, and RHEL 10.0 (for Radeon products). It extends RDNA4 GPU support to the Radeon AI PRO R9600D and Radeon RX 9060 XT LP. The install path below uses Ubuntu, which has broader AMDGPU support than RHEL for desktop compute:

# Download and install the amdgpu-install script
$ sudo apt update && sudo apt install -y wget
$ wget https://repo.radeon.com/amdgpu-install/7.2/ubuntu/noble/amdgpu-install_7.2.70200-1_all.deb
$ sudo apt install ./amdgpu-install_7.2.70200-1_all.deb
$ sudo amdgpu-install -y --usecase=graphics,rocm
$ sudo usermod -a -G render,video $LOGNAME
# Reboot after install, then verify ROCm
$ rocminfo | grep "Agent Type"

Legacy AMD hardware

The older radeon kernel driver (used for pre-GCN Terascale hardware) is still present in the kernel for cards that AMDGPU does not support. Linux kernel 6.19, arriving in early 2026, delivers significant performance improvements for GCN 1.0 and GCN 1.1 cards by migrating them onto updated internal paths. If you are running an older Radeon card and see unexpectedly poor performance, check your kernel version first -- a simple upgrade may resolve it without any driver configuration changes.

Intel: The Xe Driver Transition Intel

Intel has been the overlooked third option for Linux GPU drivers, but that is changing with the Xe kernel driver. Intel is migrating from the aging i915 driver to xe, a ground-up rewrite built for modern Linux DRM interfaces. The Xe driver is the default for Lunar Lake integrated graphics and Battlemage (Arc B-series) discrete GPUs. On older Arc Alchemist (A-series) cards, you can force the switch, though some users have reported inconsistencies during the transition period.

# Check which driver is bound to the Intel GPU
$ lspci -k | grep -A 3 "VGA\|Display"
Kernel driver in use: xe

# GPU utilization monitoring
$ sudo apt install intel-gpu-tools
$ sudo intel_gpu_top

# Hardware video decode acceleration (install separately)
$ sudo apt install intel-media-va-driver-non-free

For SR-IOV virtualization on Intel Battlemage, Linux 6.17 adds support in the Xe driver -- but with an important caveat: SR-IOV is only enabled for Arc Pro products (such as the Arc Pro B50), not the consumer B-series cards like the B580 or B570. Phoronix confirmed this limitation explicitly, reporting that SR-IOV virtualization support in the Intel Xe kernel driver is restricted to Arc Pro products only. If you run GPU-passthrough or shared GPU environments, the Arc Pro line is the hardware to target. The i915 driver remains in the kernel for older Intel graphics and is not going anywhere soon, but new development is concentrated on Xe.

Wayland Compatibility in 2026

Wayland is no longer optional on major distributions. Fedora and Ubuntu use it by default, and KDE announced in November 2025 that the upcoming Plasma 6.8 release -- expected around October 2026 -- will drop the X11 session entirely, making Wayland-exclusive the future default. The KDE team stated that "the vast majority of our users are already using the Wayland session." Until then, X11 session support continues through the Plasma 6.7 series, which will receive extra bug-fix releases into early 2027 for users who need the transition time. Whether your GPU driver works cleanly under Wayland is now a primary evaluation criterion, not an afterthought.

The key protocol for GPU Wayland compatibility is explicit synchronization via linux-drm-syncobj-v1. Without it, compositors have to fall back to implicit synchronization, which is what caused the widespread flickering on NVIDIA hardware for years. All three major GPU stacks now support this protocol -- AMD and Intel through Mesa, NVIDIA through the 555+ driver series. If you are experiencing rendering artifacts or screen tearing under Wayland, verifying explicit sync support is the first diagnostic step:

# Check available Wayland protocols (requires wayland-utils)
$ wayland-info | grep syncobj

# Check Vulkan extensions for present timing
$ vulkaninfo 2>/dev/null | grep -i "present\|sync"

# NVIDIA specific: confirm explicit sync is active
$ nvidia-settings -q CurrentMetaMode | grep sync

If you are building or choosing a desktop environment on Linux and GPU driver stability under Wayland is a priority, AMD remains the lowest-friction choice. The driver is in the kernel, Mesa ships with every distribution, and no additional configuration is needed for Wayland support.

Forcing an X11 session when Wayland does not work

Despite the direction of travel, there are still hardware and driver combinations where Wayland is not reliable -- particularly older NVIDIA cards on the legacy driver stack, certain PRIME configurations, and some virtual machine setups. Knowing how to fall back to X11 is useful while you troubleshoot.

On GNOME, the X11 session option appears on the login screen when you click the gear icon next to the sign-in button. Select GNOME on Xorg to start an X11 session. On KDE Plasma 6.7 and earlier, the session selector at the bottom left of the login screen offers both Wayland and X11 options. Note that KDE Plasma 6.8 (expected October 2026) will remove the X11 session option -- if you are dependent on X11 for hardware or workflow reasons, plan your upgrade timeline accordingly. On other display managers, look for a session type selector on the login screen or set the default session in /etc/sddm.conf or /etc/gdm3/daemon.conf.

# GDM (GNOME): force X11 globally by uncommenting WaylandEnable=false
$ sudo nano /etc/gdm3/daemon.conf
# Under [daemon], set:
WaylandEnable=false

# SDDM (KDE): set default session to x11
$ sudo nano /etc/sddm.conf
# Under [Autologin] or create [General], set:
DisplayServer=x11

# Confirm which display server is active after login
$ echo $XDG_SESSION_TYPE
x11

Hybrid Graphics and Laptops

Laptops with both an integrated GPU (iGPU) and a discrete GPU (dGPU) add another layer of complexity. Linux handles this through PRIME, which allows applications to select which GPU renders a frame while the display output goes through a different device.

AMD iGPU plus AMD dGPU configurations work cleanly on Linux. Power management, switching, and PRIME offloading all function without manual configuration on modern kernels. Intel plus NVIDIA (Optimus) setups work but require more hands-on setup -- PRIME switching functions, but battery life can suffer if the discrete NVIDIA GPU does not power down properly when idle. The 570 and 580 NVIDIA driver series improved PRIME power management, but it still requires validation on each laptop model. AMD iGPU plus NVIDIA dGPU combinations fall in a similar category.

# Run an application on the NVIDIA discrete GPU (PRIME offload)
$ __NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia glxgears

# AMD PRIME offload -- target the discrete GPU by PCI slot
$ DRI_PRIME=1 glxinfo | grep "OpenGL renderer"

# Check power state of NVIDIA dGPU (should be D3cold when idle)
$ cat /sys/bus/pci/devices/0000:01:00.0/power_state

Diagnosing Driver Problems

GPU driver failures on Linux tend to fall into a few categories: the module not loading, the module loading but the userspace driver not finding it, or the driver loading correctly but producing rendering errors. The diagnostic path is the same regardless of vendor -- start at the kernel and work upward.

# Check kernel messages for GPU driver errors at boot
$ dmesg | grep -i "drm\|nvidia\|amdgpu\|xe\|error"

# Check if the kernel module loaded
$ lsmod | grep -E "nvidia|amdgpu|xe"

# For NVIDIA -- full driver and hardware status
$ nvidia-smi -q

# Check DKMS build status (NVIDIA, out-of-tree modules)
$ dkms status

# Confirm Mesa version (AMD / Intel userspace)
$ glxinfo | grep "Mesa"

# Watch GPU utilization in real time
$ watch -n 1 cat /sys/class/drm/card0/device/gpu_busy_percent

DKMS build failures on NVIDIA are a common source of pain after kernel updates. If dkms status shows an error for the nvidia module, run sudo dkms autoinstall to attempt a rebuild. If the build fails, you likely need a newer driver that supports the updated kernel. Check NVIDIA's Unix Drivers page for the current recommended version and whether a patch release is available for your kernel version. Kernel version mismatches between the running kernel and the installed headers are the most common cause of DKMS failures that are not actual driver bugs.

GPU Drivers and Linux Gaming

Linux gaming has moved well beyond novelty territory, and GPU driver quality is central to the experience. If you are optimizing Linux for gaming with Steam and Lutris, the GPU driver stack you choose shapes which Proton features work, how well shader compilation performs, and whether you hit per-game workarounds.

AMD with RADV gives you the ACO shader compiler, which compiles shaders on demand faster than any other stack on Linux. NVIDIA with the 580.x driver series gives you DLSS, RTX ray tracing, and the best performance ceiling on supported titles. The tradeoff is setup complexity -- AMD installs and works, while NVIDIA requires more attention to driver version, Wayland configuration, and PRIME setup on laptops. For users running a SteamOS or HoloISO gaming environment, AMD is the native hardware target and the path of least resistance.

Choosing a GPU vendor for Linux in 2026 is less about raw performance than it used to be. Both AMD and NVIDIA are competitive. The real question is how much configuration you want to manage.

Step 1: Identify your GPU and choose the right driver

Run lspci -k | grep -A 2 -i vga to identify your GPU and confirm which kernel module, if any, is already bound to it. For NVIDIA hardware, note the GPU generation -- Turing (RTX 20-series) and newer support the open kernel module; Maxwell, Pascal, and Volta are now in legacy territory and require community packages on the 590.x branch. For AMD, verify whether your card is GCN 5 (Vega) or newer, which gets full AMDGPU support. Intel Battlemage (Arc B-series) and Lunar Lake use the Xe driver automatically on kernel 6.11 and later.

Step 2: Install the correct driver package for your distribution

For NVIDIA on Ubuntu, run sudo ubuntu-drivers install to let the system choose the recommended driver, or install nvidia-open-kernel-dkms and nvidia-driver directly with apt for Turing and newer cards. The open kernel module has been the default since the 560 driver series. Maxwell, Pascal, and Volta cards require legacy community packages and are no longer actively maintained by NVIDIA. For AMD, install the mesa package (typically already present on all major distros) and optionally the amdgpu-install script from AMD's repository if you need ROCm 7.2.0 for compute. For Intel Battlemage (Arc B580, B570) or Lunar Lake, the Xe kernel driver loads automatically on kernel 6.11 and later; install intel-media-va-driver-non-free separately for hardware video decode.

Step 2b: Enroll the MOK key on reboot if Secure Boot is active (NVIDIA only)

After the NVIDIA driver installs, DKMS builds and signs the kernel module against a generated Machine Owner Key. Before that key takes effect, it must be enrolled in firmware. On the next reboot, a blue MokManager screen appears. Select Enroll MOK then follow the prompts and enter the password you set during install. If you do not see this screen, or if you accidentally selected Continue Boot, see the Secure Boot section above for how to re-trigger enrollment. AMD and Intel users on Secure Boot systems need no extra steps -- their drivers are in-kernel and pre-trusted.

Step 3: Verify the driver loaded and check Wayland compatibility

After rebooting, run glxinfo | grep "OpenGL renderer" to confirm the active driver. For NVIDIA, run nvidia-smi to check driver version and hardware status. For Wayland, install wayland-utils (sudo apt install wayland-utils) and run wayland-info | grep syncobj to confirm explicit sync is available. If you see rendering artifacts, check dmesg | grep -i drm for kernel-level errors before assuming the issue is in userspace.

Frequently Asked Questions

Sources and Verification

The claims in this article are drawn from primary sources. Key references used and recommended for further reading:

• NVIDIA open kernel module default (560+): NVIDIA Driver Installation Guide r595 — confirms the open kernel module is the default and recommended option starting with the 560 series for Turing and newer hardware.
• NVIDIA 590 drops Maxwell, Pascal, Volta: Arch Linux announcement, December 2025 and Phoronix coverage
• AMDVLK discontinuation (September 15, 2025): AMD's official GitHub announcement
• ROCm 7.2.0 (released January 21, 2026): AMD ROCm release notes
• KDE Plasma 6.8 Wayland-only announcement (November 26, 2025): KDE official blog
• Intel SR-IOV restricted to Arc Pro only: Phoronix, 2026
• Intel Battlemage minimum kernel (6.11): Documented in Linux Mint community guides and Ubuntu discourse threads for Arc B580/B570 users
• NVK Vulkan 1.4 conformance and Mesa 25.1 default: Mesa NVK documentation — confirms that Mesa 25.1 makes NVK+Zink the default OpenGL implementation for Turing and later NVIDIA hardware.