Mesa, also called Mesa3D and The Mesa 3D Graphics Library, is an open source implementation of OpenGL, OpenGL ES, Vulkan, and other graphics API specifications, as well as OpenCL for GPU compute. Mesa implements these specifications with vendor-specific graphics hardware drivers, software rendering drivers, layered (translation) drivers, and more.

On Linux systems, GPU acceleration is provided primarily through Mesa. AMD supports the RadeonSI and RADV drivers in Mesa as their official GPU drivers on Linux. Intel has only ever supported the Mesa drivers on Linux systems. Google uses the Freedreno driver in Mesa in some Chromebooks with Qualcomm processors. Systems with Nvidia cards usually use the proprietary Nvidia GeForce driver, but there are ongoing efforts to write Mesa Nvidia drivers called Nouveau and NVK. As of 2026, NVK is still usually slower than the proprietary driver, but the performance gap is continually decreasing as it is developed further.

Besides 3D applications such as games, modern display servers (X.org's Glamor or Wayland's Weston) use OpenGL/EGL; therefore all graphics typically go through Mesa.

Mesa is hosted by freedesktop.org and was initiated in August 1993 by Brian Paul, who is still active in the project. Mesa was subsequently widely adopted and now contains numerous contributions from various individuals and corporations worldwide, including from most graphics hardware manufacturers, and other interested parties, such as Valve Corporation.

Overview

Implementations of rendering APIs

Mesa is known as housing implementations of graphic APIs. Historically the main API that Mesa has implemented is OpenGL, along with other Khronos Group related specifications (like OpenVG, OpenGL ES or recently EGL). But Mesa can implement other APIs and indeed it did with Glide (deprecated) and Direct3D 9 since July 2013. Mesa is also not specific to Unix-like operating systems: on Windows for example, Mesa provides an OpenGL API over DirectX.

Mesa implements a translation layer between a graphics API such as OpenGL and the graphics hardware drivers in the operating system kernel. The supported version of the different graphic APIs depends on the driver, because each hardware driver has its own implementation (and therefore status). This is especially true for the "classic" drivers, while the Gallium3D drivers share common code that tend to homogenize the supported extensions and versions.

Mesa maintains a support matrix with the status of the current OpenGL conformance visualized at .

Table of Rendering APIs

Mesa Version First Release Date Last update Vulkan OpenCL OpenGL OpenGL ES OpenVG EGL GLX Direct3D 1.42024-12-03 3.02020-11-30 4.62017-07-31 3.2.62019-07-10 1.12008-12-03 1.52014-03-19 1.42005-12-16 122015-07-29 2023-05-10 23.1.81.3.244: 1.3+ (Intel Gen8+ to XE, AMD GCN Gen2+ to RDNA3, Lavapipe, Google Venus), 1.1+ (Qualcomm Turnip), 1.0+ (AMD GCN1, Broadcom v3dv, ARM Mali PanVK)1.0, 1.1, 1.2 (full support), 3.0 (wip, some functions in 21.1), OpenCL 1.2+ and 3.0 with new RustiCL for AMD GCN and Intel Xe (Mesa 22.3+), AMD R600, Nvidia Fermi+ (Mesa 23.1+)4.6 (19.3: Intel Gen 8+, 20.0: AMD GCN, 21.1: Zink, llvmpipe, 21.2: Intel Gen 7.5) 3.2 (20.3: Intel i965, AMD radeonsi, llvmpipe, VirGL, freedreno, Zink (21.3); 3.1: AMD r600, Nvidia nvC0, softpipe, Broadcom v3d, ARM Panfrost (21.3), d3d12 (22.0) rowspan="31" 1.5 1.4 9.0c 2023-02-23 23.0.41.3.232: mostly equal to 23.1 2022-11-30 22.3.722.3: 1.3.225: 1.3+ (Intel Gen8+, AMD GCN Gen2+, Lavapipe), 1.2+ (Google Venus), 1.1+ (Qualcomm Turnip, Lavapipe (22.2)), 1.0+ (AMD GCN1, Broadcom v3dv, ARM Mali PanVK) 2022-09-21 22.2.5 2022-05-20 22.1.7 2022-03-09 22.0.5 2021-11-17 21.3.921.3: 1.2.190 (Intel Gen8+, AMD GCN Gen2+, Google Venus (21.3), Lavapipe), 1.0+ (AMD GCN1, Broadcom v3dv), 1.1+ (Qualcomm Turnip, Lavapipe (21.1)) 2021-08-04 21.2.6 2021-05-05 21.1.8 2021-03-11 21.0.3 2020-12-03 20.3.520.3: 1.2.158 (Intel Gen8+, AMD GCN Gen2+), 1.0+ (AMD GCN1, Broadcom v3dv (20.3)) 2020-09-28 20.2.61.0, 1.1, 1.2 (WIP) some failed conformance tests 2020-05-27 20.1.10 2020-02-19 20.0.81.2+ (Intel Gen8+, AMD GCN Gen2+) 2019-12-11 19.3.51.1+ (Intel Gen8+, AMD GCN Gen2+) (19.1: 1.1.104 19.0: 1.1.102, 18.3: 1.1.90, 18.2: 1.1.84) 2019-09-25 19.2.8 4.5 2019-06-11 19.1.8 2019-03-13 19.0.8 2018-12-07 18.3.6 2018-09-07 18.2.8 2018-05-18 18.1.9 1.1 (Intel Gen8+, AMD GCN Gen2+)(1.1.73) 2018-03-27 18.0.5 1.0+ (1.0.66) 2017-12-08 17.3.9 1.0 (PC: ANV Intel Gen7+ Ivy Bridge, RADV AMD GCN only) (header: 17.3: 1.0.63, 17.2: 1.0.54, 17.1: 1.0.42, 17.0: 1.0.38, 13.0: 1.0.6, 12.0: 1.0.3) in dev. by Gallium Compute (Clover): some CTS-Tests fail in 1.0 and 1.1, 1.2 (WIP), so 1.0, 1.1, 1.2 incomplete 2017-09-04 17.2.8 2017-05-10 17.1.10 17.0.7 2016-11-01 13.0.6 4.4 (4.5 No Test Label) 2016-07-08 12.0.6 4.3 3.1 2016-04-04 11.2.2 rowspan="19" 4.1 (Intel 3.3+) 2015-12-15 11.1.4 3.0 2015-09-12 11.0.9 2015-06-15 10.6.9 3.3 1.4 2015-03-06 10.5.9 1.1 2014-12-14 10.4.7 2014-09-19 10.3.7 rowspan="13" 2014-06-06 10.2.9 2014-03-04 10.1.6 2013-11-30 10.0.5 2012-10-08 9.0.3, 9.1.7, 9.2.5 rowspan="9" 3.1 2.0 2012-02-08 8.0.5 3.0 2007-06-22 7.0.4, ..., 7.11.2 2.1 rowspan="7" rowspan="7" rowspan="7" 2004-01-06 6.0.1 1.5 1.3 2002-11-13 5.0.2 1.4 2001-10-22 4.0.4 1.3 1998-09 3.1, 3.2.1, 3.4.2.1 1.2 1996-10 2.6 1.1 1995-02 1.2.8 1.0

Vulkan

The Khronos Group officially announced Vulkan API in March 2015, and officially released Vulkan 1.0 on 16 February 2016. Vulkan breaks compatibility with OpenGL and completely abandons its monolithic state machine concept. The developers of Gallium3D called Vulkan to be something along the lines of Gallium3D 2.0 – Gallium3D separates the code that implements the OpenGL state machine from the code that is specific to the hardware.

Version 1.3 is immediately available with Mesa 22.0. Hardware with support of OpenGL ES 3.1 should run at Vulkan Level 1.3 and before.

As Gallium3D ingests TGSI, Vulkan ingests SPIR-V (Standard Portable Intermediate Representation version "V" as in "Vulkan").

Intel released their implementation of a Vulkan driver for their hardware the day the specification was officially released, but it was only mainlined in April and so became part of Mesa 12.0, released in July 2016. While already the i965 driver wasn't written according to the Gallium3D specifications, for the Vulkan driver it makes even less sense to flange it on top of Gallium3D. Similarly there is no technical reason to flange it with NIR, but yet Intel's employees implemented their Vulkan driver that way.

It is to be expected that AMD's own proprietary Vulkan driver, which was released in March, and was announced to be released as free and open-source software in the future and be mainlined into Mesa, also abandons Gallium3D.

RADV is a free project for AMD and is available since version 13. Conformance with Khronos-Test came in version 17.3. Actual is Full support of Vulkan 1.0 and 1.1 since Mesa 18.1.

Nvidia released their proprietary GeForce driver with Vulkan support at launch day and Imagination Technologies (PowerVR), Qualcomm (Adreno) and ARM (Mali) have done the same or at least announced proprietary Vulkan drivers for Android and other operating systems. But when and whether additional free and open-source Vulkan implementations for these GPUs will show up, remains to be seen.

Mesa Software Driver VIRGL starts Vulkan Development in 2018 with GSOC projects for support of Virtual machines.

Lavapipe is a CPU-based Software Vulkan driver and the brother of LLVMpipe. Mesa Version 21.1 supports Vulkan 1.1+.

Google introduces Venus Vulkan Driver for virtual machines in Mesa 21.1 with full support for Vulkan 1.2+.

Qualcomm Turnip and Broadcom v3dv are new drivers for Qualcomm Adreno and Broadcom Raspberry 4 Hardware. Turnip is the Vulkan brother of freedreno for OpenGL. V3dv supports Vulkan 1.0+ since Mesa 20.3. In Version 21.1 Turnip supports Vulkan 1.1+.

Panfrost PanVK for ARM Mali is at way to Vulkan 1.1, but only 1.0 is stable available with Mesa 22.0.

Project Dozen is connecting direct 3D 12 (d3d12) with Vulkan for Linux Emulation WSL2 in Windows 10 and 11. In Mesa 23.2 Vulkan 1.0 is full conformant supported and 80% of 1.1 and 1.2 (mesamatrix).

Explicit fencing A kind of memory barrier that separates one buffer from the rest of the memory is called a fence. Fences are there to ensure that a buffer is not being overwritten before rendering and display operations have completed on it. Implicit fencing is used for synchronization between graphics drivers and the GPU hardware. The fence signals when a buffer is no longer being used by one component so it can be operated on or reused by another. In the past the Linux kernel had an implicit fencing mechanism, where a fence is directly attached to a buffer (cf. GEM handles and FDs), but userspace is unaware of this. Explicit fencing exposes fences to userspace, where userspace gets fences from both the Direct Rendering Manager (DRM) subsystem and from the GPU. Explicit fencing is required by Vulkan and offers advantages for tracing and debugging.

Linux kernel 4.9 added Android's synchronization framework to mainline.

Generic Buffer Management Generic Buffer Management (GBM) is an API that provides a mechanism for allocating buffers for graphics rendering tied to Mesa. GBM is intended to be used as a native platform for EGL on DRM or openwfd. The handle it creates can be used to initialize EGL and to create render target buffers.

Mesa GBM is an abstraction of the graphics driver specific buffer management APIs (for instance the various libdrm_* libraries), implemented internally by calling into the Mesa GPU drivers.

For example, the Wayland compositor Weston does its rendering using OpenGL ES 2, which it initializes by calling EGL. Since the server runs on the "bare KMS driver", it uses the EGL DRM platform, which could really be called the GBM platform, since it relies on the Mesa GBM interface.

At XDC2014, Nvidia employee Andy Ritger proposed to enhance EGL in order to replace GBM. This was not taken positively by the community, and Nvidia eventually changed their mind, and took another approach.

Implementations of video acceleration APIs There are three possible ways to do the calculations necessary for the encoding and decoding of video streams:

use a software implementation of a video compression or decompression algorithm (commonly called a CODEC) and execute this software on the CPU use a software implementation of a video compression or decompression algorithm (commonly called a CODEC) and execute this software on the GPU (the 3D rendering engine) use a complete (or partial) hardware implementation of a video compression or decompression algorithm; it has become very common to integrate such ASICs into the chip of the GPU/CPU/SoC and therefore abundantly available; for marketing reasons companies have established brands for their ASICs, such as PureVideo (Nvidia), Unified Video Decoder (AMD), Video Coding Engine (AMD), Quick Sync Video (Intel), DaVinci (Texas Instruments), CedarX (Allwinner), Crystal HD (Broadcom); some ASICs are available for licensing as semiconductor intellectual property core; usually different versions implement different video compression and/or video decompression algorithms; support for such ASICs usually belong into the kernel driver, to initialize the hardware and do low-level stuff. Mesa, which runs in user-space, houses the implementations of several APIs for software, e.g. VLC media player, GStreamer, HandBrake, etc., to conveniently access such ASICs:

Video Acceleration API (VAAPI) – the most common API for Linux, used by AMD and Intel Video Decode and Presentation API for Unix (VDPAU) – used by Nvidia DirectX Video Acceleration (DXVA) – Microsoft Windows-only OpenMAX IL – designed by Khronos Group for video compression Distributed Codec Engine (DCE) – designed by Texas Instruments