Graphics on Linux has two halves that people constantly conflate, and knowing which half you are dealing with makes almost every driver problem tractable.

The two halves

The kernel driver manages the hardware. It allocates video memory, submits command buffers, drives display outputs through DRM/KMS, and handles power management. amdgpu, i915, xe, nouveau and nvidia are kernel drivers.

The userspace driver implements the APIs applications call: OpenGL, Vulkan, video decode. For AMD, Intel and nouveau this is Mesa. For proprietary NVIDIA it is NVIDIA’s own libraries.

You need both, and they fail differently. A missing kernel driver means no display or a fallback framebuffer. A missing or broken userspace driver means your desktop starts but rendering is slow, wrong, or falls back to software.

# the kernel half
lspci -k | grep -A3 -E 'VGA|3D'

# the userspace half
glxinfo -B | grep -E 'OpenGL renderer|OpenGL version'
vulkaninfo --summary 2>/dev/null | head -20

If glxinfo reports llvmpipe, you are rendering on the CPU. Something is wrong.

AMD

Kernel: amdgpu. Userspace: Mesa, with RADV for Vulkan and RadeonSI for OpenGL.

Everything is in the kernel and in Mesa, so a current distribution supports current AMD hardware with nothing installed. This is the smoothest experience available on Linux and the reason AMD is the default recommendation for a machine that has to work.

The AMDGPU PRO stack exists for specific professional applications wanting certified OpenGL. Almost nobody needs it, and installing it on a desktop usually makes things worse.

Support arrives roughly with the hardware, provided your kernel and Mesa are new enough. That is the caveat worth remembering: a new AMD card on an old LTS kernel can perform badly or not work at all, which is an argument for a rolling distribution or a newer kernel if you buy recent hardware.

Intel

Kernel: i915 for older hardware, xe for recent and future parts. Userspace: Mesa, with ANV for Vulkan and Iris for OpenGL.

Intel integrated graphics have been well supported for a long time and generally require nothing. The transition from i915 to xe is the thing to be aware of: Intel is moving to a new kernel driver with a cleaner architecture, and which one you get depends on your hardware and your distribution’s configuration.

You rarely need to pick. If you are testing, the kernel command line can force the choice, and our kernel parameters guide covers how to set that persistently.

Intel’s discrete Arc cards work, and benefit substantially from a recent kernel and Mesa, more so than integrated parts do.

NVIDIA

This is where it gets complicated, and the complication is historical rather than technical.

Option one: the proprietary driver. Best performance, full feature support, and the only realistic choice for CUDA, serious gaming or professional applications. It is out of tree, so it is rebuilt against each new kernel through DKMS, and a kernel update can leave you at a text console if that rebuild fails.

Option two: nouveau. The community reverse-engineered driver, in mainline, in Mesa, working out of the box. Its long-standing limitation is reclocking: on most cards it cannot raise clock speeds from the boot state, so the GPU runs at a fraction of its capability. Fine for displaying a desktop, not for anything demanding.

The picture is improving. GSP firmware support lets nouveau delegate much of the hardware management to a firmware processor NVIDIA ships, and NVK is a modern Vulkan driver in Mesa built on that. It is progressing quickly and is not yet a replacement for the proprietary driver on demanding workloads.

On NVIDIA’s open kernel modules, be precise about what changed: the kernel module is open, which genuinely helps distributions package and maintain it. The userspace driver remains proprietary, and that is where most of the driver actually lives. It is a real improvement for packaging and a partial one for anything else.

# proprietary driver status
nvidia-smi

# is the module loaded and which one
lsmod | grep -E 'nvidia|nouveau'

# did DKMS build against your running kernel
dkms status

Secure Boot makes NVIDIA harder

An out-of-tree module must be signed to load when Secure Boot is on. Distributions handle this with varying grace, and the failure mode is a driver that silently does not load after an update.

mokutil --sb-state
dmesg | grep -i 'module verification\|taint'

Our Secure Boot guide covers the mechanism, and enrolling your own keys covers doing it deliberately rather than fighting it.

Hybrid graphics on laptops

Many laptops have Intel or AMD integrated graphics plus a discrete NVIDIA GPU. The integrated one drives the display; the discrete one is used on request.

# run one application on the discrete GPU
DRI_PRIME=1 glxinfo -B | grep 'OpenGL renderer'

# NVIDIA equivalent
__NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia glxinfo -B

Battery life depends heavily on the discrete GPU being genuinely asleep when unused, which our power management guide covers.

Choosing hardware

	Works out of box	Wayland	Gaming	Compute
AMD	Yes	Excellent	Excellent	ROCm, improving
Intel	Yes	Excellent	Adequate to good	oneAPI
NVIDIA proprietary	No	Good, historically rough	Excellent	CUDA, dominant
nouveau	Yes	Fine	Poor	No

For a desktop that should simply work, AMD. For CUDA, NVIDIA, and you accept the driver maintenance. For a laptop, integrated AMD or Intel avoids an entire category of problem.

When something breaks

# what the kernel thinks happened
sudo dmesg | grep -iE 'drm|amdgpu|i915|xe |nvidia|nouveau' | tail -40

# is the firmware present
ls /lib/firmware/amdgpu/ | head
dmesg | grep -i 'firmware.*fail'

Missing firmware is a common and easily fixed cause. GPUs need firmware blobs the distribution packages separately, frequently in a linux-firmware package, and a minimal install may not have them.

After a kernel update with NVIDIA, check dkms status before assuming the driver is at fault.

If you land at a black screen, our chroot rescue guide covers getting back in, and adding nomodeset temporarily at the bootloader will usually get you a usable console.

Frequently Asked Questions

Why do AMD and Intel GPUs work on Linux without installing anything?

Because their kernel drivers are in mainline Linux and their userspace drivers are in Mesa, which distributions ship by default. Nothing needs installing because the support arrived with your kernel and your graphics stack. NVIDIA historically kept its driver out of tree, so it has to be added separately.

What is the difference between the kernel driver and the Mesa driver?

The kernel driver manages the hardware: memory, command submission, display outputs and power. Mesa implements the graphics APIs that applications call, such as OpenGL and Vulkan, and translates them into commands the kernel driver submits. You need both and they are separate pieces of software.

Should I use nouveau or the NVIDIA proprietary driver?

The proprietary driver for anything demanding, because nouveau has long been limited by an inability to reclock most cards, leaving them stuck at low clock speeds. Nouveau is fine for a desktop that just needs to display things, and the newer NVK Vulkan driver plus GSP firmware support is steadily improving the situation.

What did NVIDIA opening its kernel modules actually change?

The kernel module is now open source, which helps distributions package it and fixes some maintenance pain. The userspace driver, where most of the proprietary work lives, remains closed. It is a meaningful improvement for packaging and less of one for the freedom argument.

What is the Xe driver and do I need it?

Xe is Intel new kernel driver, intended to replace i915 for recent and future hardware. On older Intel graphics you stay on i915. On newer parts your distribution decides, and you generally do not need to choose manually unless you are testing.

How do I find out which GPU driver is actually in use?

Run lspci -k and look at the kernel driver in use line for your VGA device, which tells you the kernel side. Then run glxinfo -B to see what Mesa or the vendor driver reports for the OpenGL renderer. Those two answers together describe your full stack.