Linux GPU drivers explained: Mesa, proprietary, and DKMS

level:Beginner verified:Jun 2026

Of all the decisions in an Arch install, the GPU driver is the one with the most folklore attached to it, and most of that folklore is out of date. The reputation that NVIDIA is a nightmare and that "open source means slow" comes from a different era. Today the right driver is almost entirely decided by which graphics vendor you have, and for two of the three vendors there is genuinely nothing to think about: you install one package and you are done. The only vendor that still asks you a real question is NVIDIA, and even that question now has a clear default. If you have Intel or AMD graphics, you can take the default below without reading further. If you have NVIDIA, the one thing worth getting right is which package matches your card's age.

What a driver and a kernel module actually are

A GPU driver on Linux is not one thing; it is a stack split across two places.

Part of it lives in the kernel as a kernel module — a chunk of code, loaded at boot, that talks directly to the hardware: setting modes, managing GPU memory, scheduling work on the chip. Modules can be compiled into the kernel or loaded on demand, and you can usually see them with lsmod. This is the layer that makes the card exist to the system.

The other part lives in userspace as libraries that translate the graphics APIs your applications speak — OpenGL and Vulkan — into commands the kernel module sends to the GPU. When a game or your desktop draws something, it calls these libraries.

For Intel and AMD, that userspace half is Mesa: the open-source implementation of OpenGL and Vulkan that the whole Linux graphics ecosystem is built on. Mesa is not a single driver but a collection of them, and it is mature, fast, and maintained in the open. Understanding that "Mesa" is the userspace graphics stack — not a brand or a single chip's driver — clears up most of the confusion in driver guides.

The stack below shows the two halves and which packages fill each layer. What it draws is the path from the chip up to your apps; why it splits into kernel and userspace is that the module talks to hardware while the libraries translate APIs; how you read it is bottom to top.

flowchart TD
    A["GPU hardware"] --> B["Kernel module<br/><i>amdgpu, i915, nvidia</i>"]
    B --> C["Userspace libraries<br/><i>Mesa or NVIDIA libs, Vulkan</i>"]
    C --> D["Desktop + apps<br/><i>games, compositor</i>"]

One module talks to the chip; the userspace layer above it speaks OpenGL and Vulkan to your programs.

Before you can match a package to your card you need to know which card you have, and that is a host-OS question — the same lookup whatever you eventually install.

os:windows Open Device Manager and expand Display adapters.

os:macos Open the Apple menu, About This Mac, and read the Graphics line.

os:linux Run lspci | grep -i vga (or the broader lspci -k) to see the chip and the driver bound to it.

What you are after is the vendor and model; why it matters is that the entire decision below hinges on it; how you confirm it is one of those three commands.

The vendor split

Intel: nothing to do

Intel integrated graphics are the easiest case on Linux. The kernel module is built in and maintained upstream, and the userspace side is Mesa, with vulkan-intel providing Vulkan. On a standard Arch install you typically need only the Mesa package and the Intel Vulkan driver; there is no proprietary blob, no separate download, no signing. It works out of the box and keeps working across kernel updates.

AMD: open is the default, even for gaming

AMD made a decision years ago that paid off enormously for Linux users: its modern driver is open source and lives in the kernel as the amdgpu module, with the userspace half handled by Mesa — OpenGL through Mesa's drivers and Vulkan through RADV, Mesa's AMD Vulkan driver. There is a separate proprietary stack (AMDVLK / the professional drivers) aimed at specific workstation workloads, but for desktops and gaming you do not want it. The open AMD stack is the recommended default and is what most gamers on Linux actually run. You install Mesa plus the AMD Vulkan package and that is the entire decision.

NVIDIA: the one real choice

NVIDIA is the vendor with history, and the situation changed significantly in late 2025, so ignore any guide older than that. There are two families of driver.

Nouveau is the fully open-source, community-built NVIDIA driver included in Mesa and the kernel. It needs no proprietary code and is fine for a basic desktop, but it has historically lagged on performance and on the newest hardware, so most people running NVIDIA for gaming or compute use the official driver instead.

The official NVIDIA driver is the one to install for performance. The important modern change is that the kernel module half of it now comes in two flavours: the older closed-source module, and open kernel modules (the nvidia-open packages) that NVIDIA open-sourced and now treats as the path forward. These open kernel modules require a GPU System Processor (GSP) on the card, which means they need Turing or newer — the GTX 16-series, RTX 20-series, and everything after.

As of the NVIDIA 590 driver release, Arch Linux switched its main NVIDIA packages to the open kernel modules (Phoronix, Arch news). Concretely, the package nvidia now provides the open modules, nvidia-dkms became nvidia-open-dkms, and nvidia-lts became nvidia-lts-open. The same release dropped support for Pascal (GTX 10-series) and older in the main driver. If you have a Pascal or Maxwell card, the main packages will not work; the supported path is the legacy nvidia-580xx-dkms package from the AUR. Turing-and-newer cards transition to the open modules automatically. Because the exact cut-offs move with each driver bump, check the support table on the NVIDIA page of the Arch Wiki for your specific card before installing — that table is the authoritative, current source.

⚠️ Warning Pre-Turing NVIDIA cards (Pascal / GTX 10-series and older) were dropped from the main packages in the 590 release. Installing the stock nvidia package on one of those will not work — you need the legacy nvidia-580xx-dkms path instead. Confirm your exact card against the wiki support table before you install, since the cut-off moves with each driver bump.

What DKMS is

You will keep seeing -dkms in those package names, and it is worth knowing what it does. DKMS — Dynamic Kernel Module Support — is a framework that automatically rebuilds out-of-tree kernel modules whenever your kernel updates. NVIDIA's driver is not part of the mainline kernel, so its module is tied to the exact kernel version it was built against. Update your kernel without rebuilding, and the module fails to load — you boot to a black screen or a low-resolution fallback.

The plain nvidia-open package ships a module prebuilt for the standard linux kernel, which is fine if that is the only kernel you run. The DKMS variant (nvidia-open-dkms) instead rebuilds the module on every kernel update, which is what you want if you run the linux-lts kernel, a custom kernel, or simply want the module to never fall out of sync. In short: what DKMS does is recompile the module; why you need it is that an out-of-tree module is pinned to one kernel version; how it helps is by triggering that rebuild automatically the moment the kernel changes. Rolling distributions like Arch update kernels often, so for an NVIDIA machine the DKMS package is frequently the safer choice. This concern does not arise for Intel or in-kernel AMD, because their modules ship inside the kernel and are updated with it.

A note on Wayland versus X11

You will also have to pick a display protocol, and it touches the driver story. Wayland is the modern display server protocol and the default on GNOME and KDE Plasma; X11 is the older one. Intel and AMD have run cleanly on Wayland for years. NVIDIA's Wayland support lagged historically but has caught up substantially with recent drivers, and the open kernel modules are part of why. This choice belongs to the layer above the driver — the display server and desktop environment — which is covered in what a desktop environment is. For most people on current hardware and drivers, Wayland is the right default now.

Which should I pick?

Intel or AMD: install Mesa and the matching Vulkan package, and stop thinking about it. For Intel that is Mesa plus vulkan-intel; for AMD, Mesa plus vulkan-radeon (RADV). The open stack is the default and the best choice, gaming included. There is no decision to agonise over.

NVIDIA Turing or newer (GTX 16-series / RTX 20-series and up): install the open driver — nvidia-open, or nvidia-open-dkms if you run a non-standard or LTS kernel. This is now the Arch default and matches NVIDIA's own direction.

NVIDIA Pascal or older (GTX 10-series and earlier): the main packages no longer support you. Use the legacy nvidia-580xx-dkms from the AUR, or run nouveau if you only need a desktop. Always confirm your card against the Arch Wiki support table first, since the boundaries shift with each release.

💡 Tip The fast path for most people: if you have Intel or AMD, just install Mesa and the matching Vulkan package. If you have NVIDIA Turing or newer (GTX 16-series / RTX 20-series and up), reach for nvidia-open. Two of the three vendors have no real decision to make.

What the chart routes on is your vendor first and, for NVIDIA, your card's age; why it forks that way is that only NVIDIA still has a real package choice; how you use it is start at your vendor and follow one branch.

flowchart TD
    A["Which vendor?"] -->|"Intel"| B["mesa + vulkan-intel"]
    A -->|"AMD"| C["mesa + vulkan-radeon"]
    A -->|"NVIDIA"| D["How old is the card?"]
    D -->|"Turing or newer"| E["nvidia-open<br/><i>open-dkms on LTS/custom</i>"]
    D -->|"Pascal or older"| F["legacy nvidia-580xx-dkms<br/><i>or nouveau</i>"]

Intel and AMD terminate immediately; only the NVIDIA branch asks the second question. Check the wiki table for your exact card before installing.

How this fits the Arch install

This decision lands in one step of part 3, where you install the desktop and drivers. After the base system boots you identify your GPU, install Mesa for everyone, and add the NVIDIA package only if you have an NVIDIA card. Getting the package right there is what separates a clean first boot into your desktop from a session that drops to software rendering. The full path from blank disk to working system is in the install hub.

A short close

The GPU driver looks like the scary part of an install and is mostly not. Intel and AMD are solved problems: Mesa, one Vulkan package, done. NVIDIA is the only vendor that asks a question, and in 2025 the answer simplified — the open kernel modules became the default for Turing and newer, with a legacy path for the old cards. Check the wiki table for your exact GPU, install the matching package, and let DKMS keep it in step with your kernel.