After explaining how graphics drivers work in general, I want to talk specifically about the Linux graphics stack. What are the important projects, how do they fit together, and what you actually need to make your GPU work properly.
To get your GPU working on Linux with open source drivers, you need these pieces:
All of these need to support your specific GPU. More importantly, they need to be recent versions. Using old packages means missing out on new features, bug fixes, and performance improvements.
You'll see people on Reddit saying "the drivers are in the kernel" on Linux. This is only partially true. The kernel driver is in the kernel, but that's just one piece. The userspace drivers (Mesa), shader compilers, and firmware are all separate packages.
Your distro manages how these are packaged and which versions you get. This is why graphics experience can vary so much between different distributions.
Mesa is the cornerstone of the open source graphics stack on Linux. It's a collection of userspace drivers implementing various graphics and compute APIs for different GPUs.
Gallium drivers implement OpenGL, OpenGL ES, OpenCL, and video APIs (VAAPI). Gallium is a common infrastructure that lets drivers share code for these APIs.
Vulkan drivers are separate from Gallium because Vulkan is lower-level than the abstraction Gallium provides. But Vulkan drivers still share significant code with their Gallium counterparts where it makes sense.
NIR (the "common compiler infrastructure") is at the heart of modern Mesa drivers. It's an intermediate representation (IR) that lets different drivers share optimization passes and compiler infrastructure. Instead of every driver implementing the same optimizations for their specific GPU, they can use shared NIR passes and only write the backend code generation.
For AMD GPUs specifically, the stack looks like this:
ACO is interesting because it was developed specifically for RADV to address performance issues with LLVM shader compilation. It's a from-scratch compiler backend that generates better code faster than LLVM for graphics workloads.
Some distros (Debian, Ubuntu LTS, etc.) ship old kernel and Mesa versions claiming they're more "stable." This is backwards. Driver developers actively work on fixing bugs and adding features. New games rely on new driver features. Old drivers mean worse performance and more bugs, not fewer.
Mesa development moves fast. Every release has performance improvements, bug fixes, and new features. If you're running Mesa from 6 months ago, you're missing hundreds of commits worth of improvements.
The kernel DRM subsystem is the same—active development means fixes and new features land constantly. Regressions happen, but they get fixed quickly because of extensive automated testing (the Vulkan conformance test suite runs on every commit to Mesa, for example).
If you want to run Windows games on Linux, use Proton (built into Steam) or Wine with DXVK/VKD3D-Proton. These translate DirectX to Vulkan and offer the best performance and compatibility.
Avoid Wine's default WineD3D (which translates DirectX to OpenGL)—it's slower and less compatible than the Vulkan-based translation layers.
I'm currently studying ACO, RADV, and NIR. The code is surprisingly readable once you understand the basic architecture. NIR especially is well-designed—having a common IR means you can implement an optimization once and every driver benefits.
What's interesting is seeing how much work goes into generating efficient GPU code. Register allocation alone is a complex problem because GPUs have specific constraints—you want high register usage for hiding latency, but too much causes spilling which kills performance.
Instruction scheduling matters more on GPUs than CPUs because latencies are longer and there's less out-of-order execution to hide stalls. ACO does a lot of work to schedule instructions properly and keep the GPU busy.