Mesa (computer graphics)
|Original author(s)||Brian Paul|
|Developer(s)||Currently: Intel, AMD, VMware
Formerly: Tungsten Graphics
|Initial release||August 1993|
|Stable release||11.1.1 / January 13, 2016|
|Written in||C, C++, Assembly|
|Operating system||Cross-platform (BSDs, Haiku, Linux, et al.)|
Mesa is a collection of free and open-source libraries that implement several rendering as well as video acceleration APIs related to hardware-accelerated 3D rendering, 3D computer graphics and GPGPU, the most prominent being OpenGL. Mesa is hosted at freedesktop.org and used on Linux, BSD and other operating systems. Additionally to the APIs, Mesa also harbors most of the available free and open-source graphics device drivers, which is a bit misleading, since the actual device drivers are located in the kernel, and the user-space part consists of some compiler software. The development of Mesa started in August 1993 by Brian Paul, who is still active in the project today, by now containing numerous contributions from various other people and companies worldwide, due to its broad adoption. Crowdfunding has been successfully used to partially drive development of Mesa.
- 1 Overview
- 2 Software architecture
- 3 Performance
- 4 Criticism
- 5 History
- 6 See also
- 7 References
- 8 External links
Implementations of rendering APIs
Mesa is known as housing implementation 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.
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 specially true for DRI drivers, while the Gallium3D drivers share common code that tend to homogenize the supported extensions and versions.
Mesa 10.x complies with OpenGL 3.3, for Intel, AMD/ATI and Nvidia GPU hardware. Mesa 11.0 was announced with some drivers being OpenGL 4.1 compliant. Mesa maintains a support matrix with the status of the current OpenGL 3 and 4 conformance.
|Future release: 11.2||2016-03-11||???||?||?||N/A||1.5||1.4||9.0c|
|Current stable version: 11.1||2015-12-15||N/A||4.2 (Intel 3.3)||3.0||N/A||1.5||1.4||9.0c|
|Old version, no longer supported: 11.0||2015-09-12||4.2 (Intel 3.3)||3.0||N/A||1.5||1.4||9.0c|
|Old version, no longer supported: 10.6||2015-06-15||3.3||3.0||N/A||1.4||1.4||9.0c|
|Old version, no longer supported: 10.5||2015-03-06||3.3||3.0||1.1||1.4||1.4||9.0c|
|Old version, no longer supported: 10.4||2014-12-14||3.3||3.0||1.1||1.4||1.4||9.0c|
|Old version, no longer supported: 10.3||2014-09-19||3.3||3.0||1.1||1.4||1.4||N/A|
|Old version, no longer supported: 10.2||2014-06-06||3.3||3.0||1.1||1.4||1.4||N/A|
|Old version, no longer supported: 10.1||2014-03-04||3.3||3.0||1.1||1.4||1.4||N/A|
|Old version, no longer supported: 10.0||2013-11-30||3.3||3.0||1.1||1.4||1.4||N/A|
|Old version, no longer supported: 9.0||2012-10-08||3.1||2.0||1.1||1.4||1.4||N/A|
|Old version, no longer supported: 8.0||2012-02-08||3.0||2.0||1.1||1.4||1.4||N/A|
|Old version, no longer supported: 7.0||2007-06-22||2.1||N/A||N/A||N/A||1.4||N/A|
|Old version, no longer supported: 6.0||2004-01-06||1.5||N/A||N/A||N/A||1.3||N/A|
|Old version, no longer supported: 5.0||2002-11-13||1.4||N/A||N/A||N/A||1.3||N/A|
|Old version, no longer supported: 4.0||2001-10-22||1.3||N/A||N/A||N/A||1.3||N/A|
There has also been a Direct3D 9 state tracker since July 2013. Note that due to the modularized nature of OpenGL, Mesa actually supports extensions from newer versions of OpenGL without claiming full support for them. For example, as of September 2015, Mesa supports OpenGL 4.2 Core Profile but also 9 out of 12 extensions that form OpenGL 4.5, with two more extensions under development.
In March 2015, the Vulkan API was officially announced by Khronos. SPIR-V, a newer version of Standard Portable Intermediate Representation (SPIR), will be part of the core specification. It remains to be seen how Mesa's current LIR, HIR and TGSI will interoperate with SPIR-V.
Generic Buffer Management
Generic Buffer Management (GBM) is an API which 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 as 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.
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 codec and do calculations on the CPU
- use a codec and do calculations on the 3D rendering engine of the GPU
- use a SIP block designed specifically for this task, e.g. PureVideo, Unified Video Decoder, Video Coding Engine, Quick Sync Video, DaVinci, CedarX, Crystal HD, etc.
Utilizing the CPU doesn't require any special support to be present in Mesa, but methods two and three do require explicit support by the graphics device driver and additional special interfaces (APIs) to be used by end-user software to access this hardware, which are shared in Mesa 3D. Several APIs for the access of video decoding hardware have been designed, including:
- Video Decode and Presentation API for Unix (VDPAU) – by Nvidia
- Video Acceleration API (VAAPI) – by Intel
- Distributed Codec Engine (DCE) – by Texas Instruments
- DirectX Video Acceleration (DXVA) – Microsoft Windows-only
- OpenMAX IL – video encoding by Khronos Group
- OpenVideo Decode (OVD) – AMD vaporware
- X-Video Bitstream Acceleration (XvBA) – extension to Xv
- X-Video Motion Compensation (XvMC) – extension to Xv
||It has been suggested that Free and open-source graphics device driver be merged into this article. (Discuss) Proposed since September 2015.|
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: DRI and Gallium3D. An overview over some of the drivers available in Mesa is given at http://mesamatrix.net/ The driver vc4 is missing from this site, while the driver freedreno is not part of mesa.
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 APU 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 is usually significantly slower with some notable exceptions, where the free and open-source driver performs better than proprietary drivers.
Direct Rendering Infrastructure (DRI)
|This section is outdated. (March 2015)|
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.[when?] 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.
With adapting to DRI, the Mesa library finally took over the role of the front end component of a full scale OpenGL framework with varying backend components that could offer different degrees of 3D hardware support while not dropping the full software rendering capability. The total system used many different software components.
While the design requires all these components to interact carefully, the interfaces between them are relatively fixed. Nonetheless, as most components interacting with the Mesa stack are open source, experimental work is often done through altering several components at once as well as the interfaces between them. If such experiments prove successful, they can be incorporated into the next major or minor release. That applies e.g. to the update of the DRI specification developed in the 2007-2008 timeframe. The result of this experimentation, DRI2, operates without locks and with improved back buffer support. For this, a special git branch of Mesa was created.
Software rendering is the misleading term, when shaders are executed on the CPU instead of the GPU. Mesa also contains an implementation of software rendering that allows shaders to run on the CPU as a fallback when no graphics hardware accelerators are present called swrast. The Gallium software rasterizer is known as softpipe or when built with support for LLVM llvmpipe which generates CPU code at runtime.
The idea of bundling multiple drivers into a single "mega" driver was proposed by Eric 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 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 shall 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, then 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. At least the Valve Corporation has granted all Mesa and all Debian developers free personal licenses for all the games distributed on Steam.
The so called "user-mode graphics device drivers" (UMD) in Mesa have very few commonalities with what is generally called a device driver. There are a couple of differences:
- they are meant to work on top of additionally existent kernel mode graphics device drivers, that are e.g. available as part of the Linux kernel found in the source code under
/drivers/gpu/drm/Each UMD communicates with its kernel mode counterpart with the help of a specific library, name libdrm_specific and a generic one, named libdrm. This section shall look solely on the user-mode part above libdrm
- there is some implementation of the finite-state machine as specified by e.g. OpenGL; this implementation of the OpenGL state machine may be shared among multiple UMDs or not
- they consist to a great part of some sort of compiler, that ingests e.g. GLSL and eventually outputs machine code. Parsers and may be shared among multiple UMD or be specific
Mesa's Intermediate Representations
One goal of Mesa is the optimization of code that is to be executed by the respective GPU. Another is the sharing of code. Instead of documenting the pieces of software, that do this or that, this Wikipedia article shall instead look at the Intermediate Representations used in the process of compiling and optimizing. See Abstract syntax tree (AST) and Static single assignment form (SSA form).
SPIR-V is a certain version of the Standard Portable Intermediate Representation. The idea is, that game engines output SPIR-V instead of GLSL. In contrast to the latter, SPIR-V is binary to protect intellectual property and is already the result of general optimizations. A UMD needs only apply optimizations, that are specific to the supported hardware.
- XDC2014, Matt Turner: Video on YouTube, Matt Turner - GLSL compiler: Where we've been and where we're going
- XDC2015, Matt Turner: Video on YouTube, http://www.x.org/wiki/Events/XDC2015/Program/turner_glsl_compiler.pdf
- Connor Abbott - NIR, or moving beyond GLSL IR in Mesa XDC2014
The Tungsten Graphics Shader Infrastructure (TGSI) was introduced in 2008 by Tungsten Graphics. All Gallium3D-style UMDs ingest TGSI.
llvmpipe do not ouput machine code, but instead LLVM IR. From here on, LLVM does optimizations and the compilation to machine code. This does mean, that a certain minimum version of LLVM has to be installed as well!
Mesa's GLSL compiler
Mesa's GLSL compiler generates its own IR. Because each driver has very different requirements from a LIR, it differentiates between HIR (high-level IR) and LIR (low-level IR).
||It has been suggested that Gallium3D be merged into this article. (Discuss) Proposed since March 2015.|
Gallium3D was developed by Tungsten Graphics as a means to simplify the writing of device drivers and also to achieve maximum portability of them, without having to rewrite the source code. Gallium3D specification were released in 2008 and as of 9 February 2016, the current version is still 0.4.
Most device drivers inside of Mesa have been rewritten conforming to the new internal APIs defined by Gallium3D, and new drivers written since the introduction of Gallium3D have been written as Gallium3D drivers from the beginning on. A notable exception is the Mesa driver for the Intel 965-family of GPUs.
The main disadvantage is, that by introducing additional interfaces, namely the Gallium3D WinSys Interface, the full capabilities of the underlying hardware can not be accessed by the device drivers.
|This section requires expansion. (September 2014)|
Project initiator Brian Paul was a graphics hobbyist. He thought it would be fun to implement a simple 3D graphics library using the OpenGL API, which he might then use instead of VOGL (very ordinary GL Like Library). Beginning in 1993, he spent eighteen months of part-time development before he released the software on the Internet. The software was well received, and people began contributing to its development. Mesa started off by rendering all 3D computer graphics on the CPU. Despite this, the internal architecture of Mesa was designed to be open for attaching to graphics processor-accelerated 3D rendering. In this first phase, rendering was done indirectly in the display server, leaving some overhead and noticeable speed lagging behind the theoretical maximum. The Diamond Monster 3D, using the Voodoo Graphics chipset, was one of the first 3D hardware devices supported by Mesa.
The first true graphics hardware support was added to Mesa in 1997, based upon the Glide API for the then new 3dfx Voodoo I/II graphics cards and their successors. A major problem of using Glide as the acceleration layer was the habit of Glide to run full screen, which was only suitable for computer games. Further, Glide took the lock of the screen memory, and thus the display server was blocked from doing any other GUI tasks.
In 2014, LunarG, a United States based private computer software company founded in 2009 that specializes in 3D driver development, enhancements and tuning, received funding from Valve to explore the possibility of game performance improvements using LunarGLASS technology in the Mesa driver.
- David Marshall (2008-12-16). "VMware's year end acquisition of Tungsten Graphics". InfoWorld. Retrieved 2011-08-06.
- "Mesa Introduction". Mesa Team. Retrieved 2015-06-08.
- "Mesa 11.1.1 release announcement". Retrieved 2016-01-13.
- "Mesa Languages Page". Open Hub. Retrieved 2015-03-02.
- "Mesa 3D license". Retrieved 2015-06-03.
- "Improve OpenGL support for the Linux Graphics Drivers - Mesa". Indiegogo. 2013-12-11. Retrieved 2015-01-21.
- "AMD exploring new Linux driver Strategy". 2014-03-22. Retrieved 2014-03-23.
- "Mesa 11.0 Has Been Branched, The Release March Begins". 2015-08-22. Retrieved 2015-08-22.
- "mesa/mesa - The Mesa 3D Graphics Library". Retrieved 2015-01-22.
- "The OpenGL vs Mesa matrix". 2015-03-25. Retrieved 2015-03-29.
- "[Mesa-dev] Mesa 11.2.0 release plan". Retrieved 2016-01-26.
- "latest patches to "nine" state tracker". 2016-02-04.
- "[Mesa-announce] Mesa 11.1.0". Retrieved 2015-12-15.
- "[Mesa-announce] Mesa 11.0.0". Retrieved 2015-09-26.
- "[Mesa] Intel releases OpenGL 4.4 for Windows". Retrieved 2015-09-10.
- "[Mesa-announce] Mesa 10.6.0". Retrieved 2015-06-15.
- Larabel, Michael (4 March 2015). "OpenVG Support Stripped From Gallium3D". Phoronix. Retrieved 11 July 2015.
- "[Mesa-announce] Mesa 10.5.0". Retrieved 2015-03-07.
- "[Mesa-announce] Mesa 10.4.0 released". Retrieved 2015-03-07.
- Larabel, Michael (14 December 2014). "Mesa 10.4 Officially Released With Direct3D 9 State Tracker". Phoronix. Retrieved 11 July 2015.
- "[Mesa-announce] Mesa 10.3 released". Retrieved 2015-03-07.
- "[Mesa-announce] Mesa 10.2 released". Retrieved 2015-03-07.
- "[Mesa-announce] Mesa 10.1 released". Retrieved 2015-03-07.
- Larabel, Michael (2014-03-05). "Mesa 10.1 Released With Many Open-Source Driver Improvements". Phoronix.
- "[Mesa-announce] Mesa 10.0 released". Retrieved 2015-03-07.
- Larabel, Michael (2013-10-26). "Features To Be Found In Mesa 10.0". Phoronix.
- "Mesa 9.0 Release Notes". Mesa. 8 October 2012. Retrieved 11 July 2015.
- "libgbm in the Debian repositories".
- "Enabling Alternative Window Systems with a non-Mesa Graphics Driver Implementation".
- "Nouveau Video Acceleration". freedesktop.org.
- "Radeon Feature Matrix". freedesktop.org.
- Direct Rendering Infrastructure Status Page on freedesktop.org
- Brian Paul (2000-08-10). "Introduction to the Direct Rendering Infrastructure". dri.sourceforge.net. Retrieved 2012-01-25.
- "DRI2". X.org. Retrieved 2012-01-25.
- "LLVMpipe: OpenGL With Gallium3D on Your CPU". Phoronix.com. 2010-04-30. Retrieved 2014-11-04.
- "llvmpipe". mesa3d.org. Retrieved 2015-06-08.
- "DRI megadrivers". 2013-09-25.
- "VDPAU & XvMC state trackers are now separate libraries". 2014-06-23.
- "What's the relationship between Glide and DRI?". dri.freedesktop.org. Retrieved 2012-01-25.
- "Services - LunarG". LunarG. Retrieved 2014-09-17.
- Dawe, Liam (2014-06-08). "Valve Are Funding A Big Change To Mesa, Should Improve Linux Graphical Performance". GamingOnLinux. Retrieved 2014-09-17.
|User mode||User applications||For example, bash, LibreOffice, Apache OpenOffice, Blender, 0 A.D., Mozilla Firefox, etc.|
|Low-level system components:||System daemons:
systemd, runit, logind, networkd, soundd, ...
X11, Wayland, Mir, SurfaceFlinger (Android)
GTK+, Qt, EFL, SDL, SFML, FLTK, GNUstep, etc.
Mesa, AMD Catalyst, ...
|C standard library||open(), exec(), sbrk(), socket(), fopen(), calloc(), ... (up to 2000 subroutines)
glibc aims to be POSIX/SUS-compatible, uClibc targets embedded systems, bionic written for Android, etc.
|Kernel mode||Linux kernel||stat, splice, dup, read, open, ioctl, write, mmap, close, exit, etc. (about 380 system calls)
The Linux kernel System Call Interface (SCI, aims to be POSIX/SUS-compatible)
|Other components: ALSA, DRI, evdev, LVM, device mapper, Linux Network Scheduler, Netfilter
Linux Security Modules: SELinux, TOMOYO, AppArmor, Smack
|Hardware (CPU, main memory, data storage devices, etc.)|