outsource rendering calculations to the
GPU over
OpenGL in real-time. Shaders are written in
OpenGL Shading Language or
SPIR-V and compiled on the CPU. The compiled programs are executed on the GPU. graphics stack:
DRM & libDRM,
Mesa 3D.
Display server belongs to the
windowing system and is not necessary e.g. for gaming.
Implementations of rendering APIs rely upon the Mesa implementation of
EGL. The special library called
libwayland-EGL, written to accommodate access to the
framebuffer, should have been made obsolete by the EGL 1.5 release. On the
GDC 2014, AMD was exploring a strategy change towards using DRM instead of their in-kernel blob. 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 . Mesa 10 complies with OpenGL 3.3 for Intel, AMD/ATI, and Nvidia GPU hardware. Mesa 11 was announced with some drivers being OpenGL 4.1 compliant. Mesa 12 contains OpenGL 4.2 and 4.3 and Intel Vulkan 1.0 support. Mesa 13 brought Intel support for OpenGL 4.4 and 4.5 (all Features supported for Intel Gen 8+, Radeon GCN, Nvidia (Fermi, Kepler), but no Khronos-Test for 4.5-Label) and experimental AMD Vulkan 1.0 support through the community driver RADV. OpenGL ES 3.2 is possible with Intel Skylake (Gen9). Ready features are certified OpenGL 4.5, OpenGL 4.5 for Intel Haswell, OpenGL 4.3 for Nvidia Maxwell and Pascal (GM107+). Huge performance gain was measured with Maxwell 1 (GeForce GTX 750 Ti and more with GM1xx). Maxwell-2-Cards (GeForce GTX 980 and more with GM2xx) are underclocked without Nvidia information. The Khronos CTS test suite for OpenGL 4.4, 4.5 and OpenGL ES 3.0+ is in now (2017-01-24) Open Source and all tests for Mesa 13 and 17 are now possible without costs. 2nd stable version of 2017, 17.1.0, came out on 10 May 2017 with some interesting improvements. OpenGL 4.2+ for Intel Ivy Bridge and OpenGL 3.3+ for Intel Open SWR Rasterizer are 2 of the highlights. Due to the modularized nature of OpenGL, Mesa can support extensions from newer versions of OpenGL without claiming full support for such versions. For example, in July 2016, Mesa supported OpenGL ES 3.1 but also all OpenGL ES 3.2 extensions except for five, as well as a number of extensions not part of any OpenGL or OpenGL ES version. 3rd Version 17.2 is available since September 2017 with some new OpenGL 4.6 features and velocity improvements in 3D for Intel and AMD. Only 1.4% of Tests fail for OpenGL 4.5 in Nouveau for Kepler. 4th Version 17.3 is ready since December 2017. Many improvements in many drivers are available. OpenGL 4.6 is nearly fully available (Spir-V is not ready). AMD Vulkan Driver RADV is now fully conformant in Khronos-Test. 1st version of 2018 is 18.0 and available since March 2018 by same scheme in 2017. Full OpenGL 4.6 support is not ready, but many features and improvements were successfully tested in RC3. 10-bit support for Intel i965 in Colors is also a Highlight. New is support for
Intel Cannon Lake and
AMD Vega with actual Linux Version. AMD Evergreen Chips (RV800 or R900) are near OpenGL 4.5 support. Old AMD R600 or RV700 Chips can only support OpenGL 3.3 with some features of OpenGL 4.x. Freedreno is the Driver for Adreno Hardware and near OpenGL 3.3 support. 2nd version of 2018 is 18.1 and available since May. Target is Vulkan 1.1.72 in Intel ANV and AMD RADV driver. OpenGL 4.6 with spir-V is also main target. Permanent work is possible completion of Features and Optimization of drivers for older hardware like AMD R600/Evergreen, Nvidia Tesla and before, Fermi, Kepler or Intel Sandybridge, Ivybridge, Haswell or Broadwell. ARM Architecture made also great improvements in Adreno 3xx/4xx/5xx and Broadwell VC4/VC5 for Raspi with main target OpenGL ES. 3rd version of 2018 is 18.2 and available in calendar stable in September. OpenGL 4.6 with spir-V and Vulkan 1.1.80 are in WIP. The soft Driver for virtual machines VIRGL is ready for OpenGL 4.3 and OpenGL ES 3.2. RadeonSI is also ready for OpenGL ES 3.2. ASTC Texture Compression Support and Compatibility Modus Support for OpenGL 4.4 (3.1 in 18.1) are other highlights in RadeonSI for AMD GCN Cards. New Vulkan 1.1 and more features for Intel and AMD are available. See more Details for Vulkan in Mesamatrix. 4th version of 2018 is 18.3 and released as stable Version 18.3.1 in December 2018. Many features in Detail and support of newer hardware are main parts. Full support of OpenGL 4.6 is not ready. 1st Version of 2019 is 19.0 and was now released at March. Full support of OpenGL 4.6 is not ready, but many improvements on this way are in all drivers. The second 2019 version is 19.1. A key feature is the transition of TGSI to NIR, marking a step toward OpenGL 4.6 with SPIR-V support and broader OpenCL compatibility. RadeonSI performs well with NIR in the development version. 3rd Version of 2019 is 19.2. OpenGL 4.6 is Beta ready for new Intel Iris Driver. 4th Version of 2019 is 19.3. OpenGL 4.6 is ready for Intel i965 and optional for new Iris Driver. First Version of 2020 is 20.0. Vulkan 1.2 is ready for AMD RADV and Intel ANV. Intel Iris is default for Intel Broadwell Gen 8+. RadeonSI driver switched to using NIR by default, instead of TGSI. 2nd Version of 2020 is 20.1. Many improvements are ready in many drivers. Zink is a new virtual driver for OpenGL over Vulkan. 3rd Version of 2020 is 20.2. OpenGL 3.0 for Zink is one new feature. LLVMpipe will support OpenGL 4.3+ (4.5+ in 20.3). ARM Panfrost is mostly improved with many modules. Shared virtual memory is possible for OpenCL in Nouveau with Pascal and higher. 4th Version of 2020 is 20.3. v3d and v3dv are new drivers for OpenGL and Vulkan 1.0 with Broadcom hardware like Raspberry Pi 4. OpenCL 1.2 is full supported in clover module. Zink support OpenGL 3.3+. LLVMpipe virtual driver support now OpenGL 4.5+ with 4.6 in view. Lavapipe (originally called Vallium) as Vulkan Tree of LLVMpipe is merged. In Mesa 21.0 d3d12 will be merged with OpenGL 3.0 to 3.3. Microsoft and Collabora develops new emulation d3d12 in WSL2 to Windows 10 with Direct 3D 12. OpenCL 1.2 is also target in d3d12. An acceleration of factor 2 to 5 is done in Benchmark SPECviewperf with improved OpenGL Code. Many Mesa 21.0 features improves performance. New Release 21.0.0 is public since 11 March 2021. Mesa 21.1 is second release of year 2021. OpenGL 4.6+ and OpenGL ES 3.1+ is available for Zink. AMD Driver 600g can change to NIR with more possibilities for old Radeon HD 5000 and 6000 cards. Qualcomm Turnip reaches Vulkan 1.1+ and software emulation Lavapipe Vulkan 1.1+. Google VirtIO GPU Driver Venus with Vulkan 1.2+ is merged in experimental state with low performance in mesa main tree. Mesa 21.2 is third release of year 2021. Google Virtual Vulkan IO Driver Venus will be official introduced with full Vulkan 1.2+ support (more mesamatrix). ARM Panfrost: OpenGL ES 3.1+ Support is available and panVK is the new Vulkan Driver. Initial support started for ARM Apple M1 with new driver Asahi. 21.2 is available since 4 August 2021. An old plan is to split old drivers in a classic tree with many advantages in programming, support, bug fixing for the modern gallium 3D part. One problem here is Intel i965 with support of Popular old hardware to Intel Haswell and before also with Windows 10 support. A new Gallium3D driver Crocus for Intel Gen 4 Graphics to Haswell is here in development to complete here the gallium3D area with possible split in the next time of year 2021. Crocus is optional available in 21.2. Amber branch is for old drivers without Gallium 3D Functions like Radeon R200, intel i915 and 965 with actual version 21.3.9. In Version 22.0 Classic drivers are retired. Vulkan 1.3 is available for Intel Anvil and AMD RADV. Microsoft introduces new driver „Dozen“ for WSL 2 in early development stage as Vulkan over d3d12 in Mesa 22.1. RustiCL is available at 22.3 with official OpenCL 3.0 Conformance for Intel XE Graphics. Performance is equal and better to AMD ROCm with AMD 6700 XT Card. A main development target of Mesa 23.0 was ray tracing for Vulkan. Microsoft develops the Dozen driver for Vulkan in WSL. Vulkan 1.0+ with 80% 1.1 and 1.2 will be available in Mesa 23.2 after delay to 23.1 (See mesamatrix). RustiCL for AMD hardware is available in 23.1. VirGL for virtual machines jumps in Mesa 23.2 to OpenGL 4.6. Apple Asahi for Apple Arm Machines jumps from OpenGL 2.1 to 3.1 with 90% features of OpenGL 3.2 and 3.3 and OpenGL ES 2.0 to 3.0. Microsoft Supports in WSL OpenGL 4.6+ in Mesa 24.0 (in Mesa 23.3: 4.3+) with
DirectX 12 translation driver dozen.
Table of Rendering APIs 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+. 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 •
X-Video Bitstream Acceleration (XvBA) – extension to
Xv - succeeded by VAAPI •
X-Video Motion Compensation (XvMC) – extension to
Xv - succeeded by VAAPI For example,
Nouveau, which has been developed as part of Mesa, but also includes a Linux kernel component, which is being developed as part of the Linux kernel, supports the
PureVideo-branded ASICs and provides access to them through
VDPAU and partly through
XvMC. The free radeon driver supports
Unified Video Decoder and
Video Coding Engine through VDPAU and OpenMAX.
V4L2 is a
kernel-to-user-space interface for video bit streams delivered by webcams or TV tuners. Due to
patent concerns regarding the
H.264,
H.265 and
VC-1 video codecs,
Fedora Linux disabled support for VAAPI acceleration for those in its build of Mesa in September 2022.
Device drivers The available free and open-source device drivers for graphic chipsets are "stewarded" by Mesa (because the existing free and open-source implementation of APIs are developed inside of Mesa). Currently there are two frameworks to write graphics drivers: "classic" and Gallium3D. An overview over some (but not all) of the drivers available in Mesa is given at . There are device drivers for AMD/ATI R100 to R800, Intel, and
Nvidia cards with 3D acceleration. Previously drivers existed for the IBM/Toshiba/Sony
Cell processor of the
PlayStation 3, S3 Virge &
Savage chipsets, VIA chipsets, Matrox G200 & G400, and more. The free and open-source drivers compete with proprietary closed-source drivers. Depending on the availability of hardware documentation and man-power, the free and open-source driver lag behind more or less in supporting 3D acceleration of new hardware. Also, 3D rendering performance was usually significantly slower with some notable exceptions. Today this is still true for Nouveau for most NVIDIA GPUs while on AMDs Radeon GPUs the open driver now mostly matches or exceeds the proprietary driver's performance.
Direct Rendering Infrastructure (DRI) At the time 3D
graphics cards became more mainstream for PCs, individuals partly supported by some companies began working on adding more support for hardware-accelerated 3D rendering to Mesa. The
Direct Rendering Infrastructure (DRI) was one of these approaches to interface Mesa, OpenGL and other 3D rendering API libraries with the device drivers and hardware. After reaching a basic level of usability, DRI support was officially added to Mesa. This significantly broadened the available range of hardware support achievable when using the Mesa library.
DRI3 is supported by the Intel driver since 2013 and is default in some Linux distributions since 2016 to enable Vulkan support and more. It is also default on AMD hardware since late 2016 (X.Org Server 1.18.3 and newer).
Software renderer Mesa also contains an implementation of
software rendering called that allows shaders to run on the CPU as a fallback when no graphics hardware accelerators are present. The Gallium software rasterizer is known as
softpipe or when built with support for
LLVM llvmpipe, which generates CPU code at runtime. Since Mesa 10.x OpenGL 3.3+ is supported for Softpipe (10.3) and LLVMpipe (10.2). Actually about 80% of Features from OpenGL 4.x are implemented in Mesa 17.3 (See Mesamatrix). In Mesa 12.0 a new Intel Rasterizer OpenSWR is available with high advantages in clusters for large data sets. It's more focused on engineering visualisation than in game or art imagery and can only work on x86 processors. On the other hand, OpenGL 3.1+ is now supported. Acceleration values from 29 to 51 related to LLVMPIPE were measured in some examples. OpenGL 3.3+ is supported for OpenSWR since Mesa 17.1. VirGL is a Rasterizer for Virtual machines implemented in Mesa 11.1 since 2015 with OpenGL 3.3 support and showed in Mesamatrix since Mesa 18. In actual new Mesa 18.2 it supports more than the others with OpenGL 4.3 and OpenGL ES 3.2. About 80% of OpenGL 4.4 and 4.5 features are also now ready. Vulkan Development starts with GSOC 2018 projects. Actual virGL state in Mesamatrix is full support of OpenGL 4.6+ and OpenGL ES 3.2+ with some necessary Linux software. D3d12 is a project of Microsoft for WSL2 emulation of OpenGL 3.3+ and OpenCL 1.2+ with Direct3D 12. D3D12 is merged in 21.0.
Mega drivers The idea of bundling multiple drivers into a single "mega" driver was proposed by Emma Anholt. It allows for a single copy of the shared Mesa code to be used among multiple drivers (instead of it existing in each driver separately) and offering better performance than a separate shared library due to the removal of the internal library interface. The state trackers for
VDPAU and XvMC have become separate libraries.
shader-db shader-db is a collection of about 20,000
shaders gathered from various computer games and benchmarks as well as some scripts to compile these and collect some statistics. Shader-db is intended to help validate an optimization. It was noticed that an unexpected number of shaders are not hand-written but generated. This means these shaders were originally written in
HLSL and then translated into GLSL by some translator program, such as e.g.
HLSL2GLSL. The problem is, that the generated code is often far from being optimal. Matt Turner said it was much easier to fix this in the translator program than having to make Mesa's compiler carry the burden of dealing with such bloated shaders. shader-db cannot be considered free and open-source software. To use it legally, one must have a license for all the computer games that the shaders are part of. == Software architecture ==