People say “install Mesa” as though it were one driver. It is a collection of drivers sharing infrastructure, and knowing which piece does what turns most graphics debugging from guesswork into a sequence of checks.

What Mesa provides

Mesa implements the graphics APIs applications call: OpenGL, OpenGL ES, Vulkan, and the video acceleration interfaces VA-API and VDPAU.

It sits above the kernel driver, which our GPU drivers guide covers. The kernel manages the hardware; Mesa turns glDrawArrays or a Vulkan command buffer into something the kernel can submit.

One Mesa installation contains drivers for AMD, Intel, NVIDIA via nouveau, several Arm GPUs, and software renderers. Which one loads is decided at runtime by what hardware is present.

Gallium3D, and what it is for

Gallium3D is a framework that splits an OpenGL driver into two parts:

• A state tracker implementing OpenGL semantics, shared by every driver
• A hardware backend that knows how to talk to one GPU family

The point is that OpenGL is enormous and mostly identical regardless of hardware. Implementing it once, correctly, and writing only the hardware-specific part per GPU saves an extraordinary amount of duplicated effort and duplicated bugs.

The Gallium drivers you will encounter:

Driver	Hardware
RadeonSI	AMD GCN and newer
Iris	Intel Gen8 and newer
Nouveau / NVC0	NVIDIA, open driver
Freedreno	Qualcomm Adreno
Panfrost	Arm Mali
llvmpipe	CPU software rendering
Zink	OpenGL implemented on Vulkan

Vulkan drivers sit outside Gallium

Vulkan drivers are written directly against Vulkan rather than through Gallium.

The reason is that Vulkan is explicit. The application manages memory, synchronisation and command buffers itself, so there is far less shared state for a framework to track. Most of what Gallium exists to do has nothing to do in a Vulkan driver.

Driver	Hardware
RADV	AMD
ANV	Intel
NVK	NVIDIA, open
Turnip	Qualcomm Adreno
lavapipe	CPU software Vulkan

RADV is the interesting political case. AMD ships its own Vulkan driver, AMDVLK, and RADV is the community one in Mesa. RADV is what nearly everyone actually uses, including Valve on the Steam Deck, because it has been better for years. A community driver outcompeting the vendor’s own is not the usual outcome.

Zink inverts the stack

Zink implements OpenGL on top of Vulkan.

That sounds redundant. You already have a Vulkan driver for your hardware, so why add a translation layer to reach an API the hardware supports natively?

Because maintaining two full drivers per GPU family is expensive. An OpenGL driver and a Vulkan driver are each large, and they duplicate a great deal of hardware knowledge. Zink means you write the Vulkan driver well and OpenGL arrives on top of it, so improvements land once and benefit both.

It was a curiosity for years and is not any more. Valve now ships the Steam Frame using Turnip for Vulkan and Zink for OpenGL, choosing the translation layer over the native Freedreno driver that already existed for that hardware. Shipping it in a consumer product is a stronger statement than any benchmark.

# try it yourself
MESA_LOADER_DRIVER_OVERRIDE=zink glxinfo -B
MESA_LOADER_DRIVER_OVERRIDE=zink glxgears

On current Mesa, the gap against a native driver is frequently a few percent, and occasionally reversed.

llvmpipe and lavapipe

Software renderers, running entirely on the CPU. They are complete and correct implementations and they are slow.

Seeing llvmpipe in glxinfo is almost always a symptom, not a choice. It means the hardware driver failed to load and Mesa fell back.

glxinfo -B | grep 'OpenGL renderer'
# llvmpipe means something is broken

sudo dmesg | grep -iE 'drm|firmware' | tail -20

They are genuinely useful in CI, in virtual machines with no GPU passthrough, and for reproducing rendering bugs without hardware variables.

Environment variables worth knowing

# select a Gallium driver
MESA_LOADER_DRIVER_OVERRIDE=zink app

# select a Vulkan ICD
VK_DRIVER_FILES=/usr/share/vulkan/icd.d/radeon_icd.x86_64.json app

# claim a newer OpenGL version than Mesa advertises
MESA_GL_VERSION_OVERRIDE=4.6 app

# see what is loading and why
MESA_DEBUG=1 app
LIBGL_DEBUG=verbose glxinfo -B 2>&1 | head -20

MESA_GL_VERSION_OVERRIDE deserves a warning. It makes Mesa claim a version, which gets stubborn applications past a version check. It does not implement anything, so if the application genuinely uses the features it will fail in a less obvious way.

Checking what you have

# Mesa version and active driver
glxinfo -B

# Vulkan drivers available
vulkaninfo --summary
ls /usr/share/vulkan/icd.d/

# video acceleration
vainfo

Mesa version matters more than most people expect. New GPUs frequently need a Mesa newer than an LTS distribution ships, and the symptom is poor performance or missing features rather than an outright failure. If you buy a current GPU and put it on a two-year-old distribution, check Mesa’s version before concluding the hardware is at fault.

Why this is one of the better parts of Linux

The graphics stack gets criticised, and the structural position is genuinely strong. AMD, Intel and Valve all pay people to work on Mesa, the drivers are in the same tree so improvements to shared infrastructure help everyone, and there is no per-vendor userspace blob to install for two of the three major vendors.

That is why an AMD or Intel system renders correctly with nothing installed, and it is the direct result of the shared-infrastructure decisions Gallium and Mesa made a long time ago.

Frequently Asked Questions

What exactly is Mesa?

Mesa is the open source implementation of graphics APIs on Linux, primarily OpenGL and Vulkan. It is not a single driver but a collection of them sharing common infrastructure, so one Mesa install provides drivers for AMD, Intel, NVIDIA via nouveau, Arm GPUs and several software renderers.

What is Gallium3D and why do Vulkan drivers not use it?

Gallium3D is a framework that splits a driver into a hardware-specific backend and shared state-tracking code, so OpenGL features are implemented once rather than per driver. Vulkan is explicit enough that most of that shared abstraction has nothing to do, so Vulkan drivers are written directly against the Vulkan API instead.

Is Zink slower than a native OpenGL driver?

Not necessarily any more. On modern Mesa, Zink is frequently within a few percent of native and occasionally ahead, because the Vulkan driver underneath receives more development attention than the older OpenGL one. Valve shipping the Steam Frame with Zink for OpenGL is a strong signal about its readiness.

What does llvmpipe mean when glxinfo reports it?

It means you are rendering on the CPU rather than the GPU. It is a correct and complete OpenGL implementation and it is very slow for anything interactive. Seeing it usually indicates a missing or failed GPU driver rather than a deliberate choice.

How do I force a specific Mesa driver for testing?

MESA_LOADER_DRIVER_OVERRIDE selects the Gallium driver, so setting it to zink runs OpenGL through Vulkan. For Vulkan itself, VK_ICD_FILENAMES or VK_DRIVER_FILES points at a specific installable client driver manifest. Both are for testing and comparison rather than permanent configuration.

Do I need to install Mesa separately?

No. Every mainstream distribution ships Mesa as part of the base graphics stack, because the desktop cannot render without it. You only interact with it directly when you want a newer version than your distribution provides, or when debugging which driver is in use.