After introducing how graphics drivers work in general, I’d like to give a brief overview about what is what in the Linux graphics stack, what are the important parts and what the key projects are where the development happens, as well as what you need to do to get the best user experience out of it.

The open source Linux graphics driver stack

Please refer to my previous post for a more detailed general explanation on graphics drivers in general. This post focuses on how things work in the open source graphics stack on Linux.

Which GPUs are supported?

We have open source drivers for the GPUs from all major manufacturers with varying degrees of success.

  • Some companies (eg. AMD, Intel and others) choose to participate in the open source community and develop open source drivers themselves, with contributions also coming from other parties (eg. Valve, Red Hat, Google, etc). If you have an AMD or Intel GPU, their open source drivers typically work better than their alternatives (if any), and have been for a long time.
  • Others (eg. NVidia and Apple) don’t recognize the benefits of this style of development and leave it to the community to create drivers based on reverse-engineering or sometimes minimal help from the manufacturer. If you have an NVidia GPU, as of late 2025 the open source drivers may not be quite ready just yet. In this post I am not going to discuss the proprietary drivers.

What parts do you need?

The components you need in order to get your GPU working on open source drivers on a Linux distro are the following:

  • Linux kernel (obviously) ― contains the open source kernel drivers (KMD).
  • linux-firmware ― contains the necessary firmware. Note that even when the actual drivers are open source, most (all?) GPUs require closed source firmware to function.
  • Mesa ― contains the most userspace drivers (relevant to gaming) as well as a shader compiler stack.
  • LLVM ― needed by some Mesa drivers for shader compilation.
  • Some vendors have other projects (eg. AMD ROCm) for supporting other features that aren’t part of Mesa. These parts are out of scope for this blog post.

To make your GPU work, you need new enough versions of the Linux kernel, linux-firmware and Mesa (and LLVM) that include support for your GPU.

To make your GPU work well, I highly recommend to use the latest stable versions of all of the above. If you use old versions, you are missing out. By using old versions you are choosing not to benefit from the latest developments (features and bug fixes) that open source developers have worked on, and you will have a sub-par experience (especially on relatively new hardware).

Wait, aren’t the drivers in the kernel?

If you read Reddit posts, you will stumble upon some people who believe that “the drivers are in the kernel” on Linux. This is a half-truth. Only the KMDs are part of the kernel, everything else (linux-firmware, Mesa, LLVM) is distributed in separate packges. How exactly those packages are organized, depends on your distribution.

What is the Mesa project?

Mesa is a collection of userspace drivers which implement various different APIs. It is the cornerstone of the open source graphics stack. I’m going to attempt to give a brief overview of what are the most relevant parts of Mesa.

Gallium

An important part of Mesa is the Gallium driver infrastructure, which contains a lot of common code for implementing different APIs, such as:

  • Graphics: OpenGL, OpenGL ES, EGL
  • Compute: OpenCL
  • Video decoding and encoding: VAAPI (previously also VDPAU)

Vulkan

Mesa also contains a collection of Vulkan drivers. Originally, Vulkan was deemed “lower level than Gallium”, so Vulkan drivers are not part of the Gallium driver infrastructure. However, Vulkan has a lot of overlapping functionality with the aforementioned APIs, so Vulkan drivers still share a lot of code with their Gallium counterparts when appropriate.

NIR

Another important part of Mesa is the NIR shader compiler stack, which is at the heart of every Mesa driver that is still being maintained. This enables sharing a lot of compiler code across different drivers. I highly recommend Faith Ekstrand’s post In defense of NIR to learn more about it.

Compatibility layers and API translation

Technically they are not drivers, but in practice, if you want to run Windows games, you will need a compatibility layer like Wine or Proton, including graphics translation layers. The recommended ones are:

  • DXVK: translates DirectX 8-11 to Vulkan.
  • VKD3D-Proton: translates DirectX 12 to Vulkan.

Those are default in Proton and offer the best performance. However, for “political” reasons, these are sadly not the defaults in Wine, so either you’ll have to use Proton or make sure to install the above in Wine manually.

Just for the sake of completeness, I’ll also mention the Wine defaults:

  • WineD3D: translates DirectX 1-11 to OpenGL. It is what we all used before Vulkan and DXVK existed, sadly its performance and compatibility has always been lacking.
  • VKD3D: translates DirectX 12 to Vulkan. Not practically usable. Can only actually run a select few games, and those with lackluster performance. (Not to be confused with VKD3D-Proton, which is actually fully-featured.)

Side note about window systems

Despite the X server being abandoned for a long time, there is still a debate between Linux users whether to use a Wayland compositor or the X server. I’m not going to discuss the advantages and disadvantages of these, because I don’t participate in their development and I feel it has already been well-explained by the community.

I’m just going to say that it helps to choose a competent compositor that implements direct scanout. This means that the frames as rendered by your game can be sent directly to the display without the need for the compositor to do any additional processing on it.

In this blog post I focus on just the driver stack, because that is largely shared between both solutions.

Making your games run (well)

Sadly, many Linux distributions choose to ship old versions of the kernel and/or other parts of the driver stack, giving their users a sub-par experience. Debian, Ubuntu LTS and their derivatives like Mint, Pop OS, etc. are all guilty of this. They justify this by claiming that older versions are more reliable, but this is actually not true.

In reality, us driver developers as well as the developers of the API translation layers work hard to implement new features that are needed to get new games working, as well as fixing bugs that are exposed by new games (or updates of old games).

Regressions are real, but they are usually quickly fixed thanks to the extensive testing that we do: every time we merge new code, our automated testing system runs the full Vulkan conformance test suite to make sure that all functionality is still intact, thanks to Martin’s genious.