Jump to content

Mesa (computer graphics): Difference between revisions

From Wikipedia, the free encyclopedia
Browse history interactively
← Previous editNext edit →
Content deleted Content added
VisualWikitext
m Fix typo
Line 18: Line 18:
| website = {{URL|mesa3d.org}}
| website = {{URL|mesa3d.org}}
}}
}}
'''Mesa''' is an [[open-source]] implementation of the [[OpenGL]], [[Vulkan (API)|Vulkan]] and other specifications<!-- verbatim from the mesa3d website-->. Its most important user surfacing parts are the two graphics drivers mostly developed and funded by Intel and AMD, which are using those implentations. The smaller GeForce graphics driver [[Nouveau (software)|Nouveau]] in contrast is mostly a community effort. Mesa implements a cross-language, cross-platform (mostly on [[Berkeley Software Distribution|BSD]] and [[Linux]] distributions), vendor-neutral standard [[Application programming interface|API]] for interfacing with diverse vendor-specific graphics hardware drivers.
'''Mesa''' is an [[open-source]] implementation of the [[OpenGL]], [[Vulkan (API)|Vulkan]] and other specifications<!-- verbatim from the mesa3d website-->. Its most important user surfacing parts are the two graphics drivers mostly developed and funded by Intel and AMD, which are using those implementations. The smaller GeForce graphics driver [[Nouveau (software)|Nouveau]] in contrast is mostly a community effort. Mesa implements a cross-language, cross-platform (mostly on [[Berkeley Software Distribution|BSD]] and [[Linux]] distributions), vendor-neutral standard [[Application programming interface|API]] for interfacing with diverse vendor-specific graphics hardware drivers.


Besides 3D applications such as games, modern [[display server]]s ([[Glamor (software)|X.org's Glamor]] or Wayland's Weston) use OpenGL/EGL, therefore all graphics typically go through Mesa. Proprietary graphics drivers (e.g. [[Nvidia GeForce driver]] and [[AMD Catalyst]] for [[Radeon]]) replace all of Mesa, providing their own implementation of a graphics API, rather than providing a driver that Mesa talks to. While Nvidia today promotes its proprietary driver for gaming, AMD promotes their Mesa drivers (radeon and radeonSI) over the deprecated [[AMD Catalyst]] (formerly fglrx).
Besides 3D applications such as games, modern [[display server]]s ([[Glamor (software)|X.org's Glamor]] or Wayland's Weston) use OpenGL/EGL, therefore all graphics typically go through Mesa. Proprietary graphics drivers (e.g. [[Nvidia GeForce driver]] and [[AMD Catalyst]] for [[Radeon]]) replace all of Mesa, providing their own implementation of a graphics API, rather than providing a driver that Mesa talks to. While Nvidia today promotes its proprietary driver for gaming, AMD promotes their Mesa drivers (radeon and radeonSI) over the deprecated [[AMD Catalyst]] (formerly fglrx).

Revision as of 09:04, 20 March 2017

Mesa
Original author(s)Brian Paul
Developer(s)Currently: Intel, AMD, VMware
Formerly: Tungsten Graphics[1]
Initial releaseAugust 1993; 31 years ago (1993-08)[2]
Stable release
17.0.1 / March 4, 2017; 7 years ago (2017-03-04),[3]
Preview release
17.0.0 RC3 / February 6, 2017; 7 years ago (2017-02-06)
Repository
Written inC, C++, Assembly[4]
Operating systemCross-platform (BSDs, Haiku, Linux, et al.)
TypeGraphics library
LicenseMIT License[5]
Websitemesa3d.org

Mesa is an open-source implementation of the OpenGL, Vulkan and other specifications. Its most important user surfacing parts are the two graphics drivers mostly developed and funded by Intel and AMD, which are using those implementations. The smaller GeForce graphics driver Nouveau in contrast is mostly a community effort. Mesa implements a cross-language, cross-platform (mostly on BSD and Linux distributions), vendor-neutral standard API for interfacing with diverse vendor-specific graphics hardware drivers.

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. Proprietary graphics drivers (e.g. Nvidia GeForce driver and AMD Catalyst for Radeon) replace all of Mesa, providing their own implementation of a graphics API, rather than providing a driver that Mesa talks to. While Nvidia today promotes its proprietary driver for gaming, AMD promotes their Mesa drivers (radeon and radeonSI) over the deprecated AMD Catalyst (formerly fglrx).

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 the graphics hardware manufacturers of the Khronos Group that administer the OpenGL specification. For Linux, development has also been partially driven by crowdfunding.[6]

Overview

Video games 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.
Illustration of the Linux 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

The free implementations of Wayland 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.[7]

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 (deprecated) and Direct3D 9 (since July 2013.[8]). 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 specially 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[9][10] visualized at mesamatrix.net. 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.[11]

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).[12]

Actual Version is 17.0 (new year Counting).[13][14][15] Ready features are certified OpenGL 4.5, OpenGL 4.5 for Intel Haswell,[16] OpenGL 4.3 for NVidia Maxwell and Pascal (GM107+).[17] 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.[18]

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.[19]

Note that due to the modularized nature of OpenGL, Mesa can actually support extensions from newer versions of OpenGL without claiming full support for them. 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.[20]

API Vulkan OpenCL OpenGL OpenGL ES OpenVG EGL GLX Direct3D
Version Date Last update 1.0
2016-02-16		 2.1
2015-11-11		 4.5
2014-08-11		 3.2
2015-08-10		 1.1
2008-12-03		 1.5
2014-03-19		 1.4
2005-12-16		 12.0
2015-07-29
Current stable version: 17.0 2017-02-13[21][13] 17.0.1 [22][23][24] 1.0 in dev. by Gallium
Compute:
work in progress
(WIP)
1.0, 1.1, 1.2[25][26] 		4.5 (+ extra ARBs) 3.2 —[27] 1.5 1.4 9.0c[28][29]
Old version, yet still maintained: 13.0 2016-11-01[30] 13.0.5 [31][32][33][34][35] 4.4
(4.5 No Test Label)
Old version, no longer maintained: 12.0 2016-07-08[36] 12.0.6 [37][38][39][40][41][42] 4.3[36] 3.1
Old version, no longer maintained: 11.2 2016-04-04[43] 11.2.2 — 4.1 (Intel 3.3+)[44]
Old version, no longer maintained: 11.1 2015-12-15[45] 11.1.4 3.0
Old version, no longer maintained: 11.0 2015-09-12[46] 11.0.9
Old version, no longer maintained: 10.6 2015-06-15[47] 10.6.9 3.3[48] 1.4
Old version, no longer maintained: 10.5 2015-03-06[49] 10.5.9 1.1
Old version, no longer maintained: 10.4 2014-12-14[50] 10.4.7
Old version, no longer maintained: 10.3 2014-09-19[51] 10.3.7 —
Old version, no longer maintained: 10.2 2014-06-06[52] 10.2.9
Old version, no longer maintained: 10.1 2014-03-04[53] 10.1.6
Old version, no longer maintained: 10.0 2013-11-30[54] 10.0.5
Old version, no longer maintained: 9.0 2012-10-08 9.0.3, 9.1.7, 9.2.5 — 3.1[55] 2.0
Old version, no longer maintained: 8.0 2012-02-08 8.0.5 3.0
Old version, no longer maintained: 7.0 2007-06-22 7.0.4, ..., 7.11.2 2.1 — — —
Old version, no longer maintained: 6.0 2004-01-06 6.0.1 1.5 1.3
Old version, no longer maintained: 5.0 2002-11-13 5.0.2 1.4
Old version, no longer maintained: 4.0 2001-10-22 4.0.4 1.3
Old version, no longer maintained: 3.0 1998-09-01 3.1, 3.2.1, 3.4.2.1 1.2
Old version, no longer maintained: 2.0 1996-10-01 2.6 1.1
Old version, no longer maintained: 1.0 1995-02-01 1.2.8 1.0
Legend:
Old version, not maintained
Old version, still maintained
Latest version
Latest preview version
Future release

Vulkan

The Khronos Group officially announced Vulkan API in March 2015, and officially released Vulkan 1.0 on February 16, 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.

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.[56]

RADV is a free Project in Beta Status for AMD and available in Version 13.[12]

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.

Explicit fencing

A kind of memory barrier which 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.[57]

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.[58]

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.[59]

Implementations of video acceleration APIs

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

  1. use a software implementation of a video compression or decompression algorithm (commonly called a CODEC) and execute this software on the CPU
  2. 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)
  3. 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/APU/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:

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.[60]

The free radeon driver supports Unified Video Decoder and Video Coding Engine through VDPAU and OpenMAX.[61]

Please note, that V4L2 is a kernel-to-user-space interface for video bit streams delivered by webcams or TV tuners.

Device drivers

Main article: Free and open-source graphics device driver
Graphics device drivers are implemented using two components: a UMD (user-mode driver) and a KMD (kernel-mode driver). Starting with Linux kernel 4.2 AMD Catalyst and Mesa will share the same Linux kernel driver: amdgpu. Amdgpu provides interfaces defined by DRM and KMS.

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.[62] An overview over some of the drivers available in Mesa is given at mesamatrix.net. The driver vc4 is missing from this site, while the driver freedreno is not part of Mesa.[citation needed]

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.[63]

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.[64][65][66][67] 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)

Main article: Direct Rendering Infrastructure

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.[68]

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.[68]

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.[69]

DRI3 is supported by the Intel driver since 2013[70][71] and is default in some Linux distributions since 2016[72] to enable Vulkan support and more. It is also default on AMD hardware since late 2016 (X.Org Server 1.18.3 and newer).[73]

Software renderer

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.[74][75]

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.[76] On the other hand, OpenGL 3.1+ is now supported.[77] Acceleration values from 29 to 51 related to LLVMPIPE were measured in some examples.[78] Only change to option "GALLIUM_DRIVER="swr" is necessary.

Mega drivers

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.[79] The state trackers for VDPAU and XvMC have become separate libraries.[80]

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. At least the Valve Corporation has granted all Mesa and all Debian developers free personal licenses for all the games distributed on Steam.

Software architecture

A graphics drivers consists of an implementation of the OpenGL state machine and a compilation stack to compile the shaders into the GPU's machine language. This compilation as well as pretty much anything else is executed on the CPU, then the compiled shaders are sent to the GPU and are executed by it. (SDL = Simple DirectMedia Layer).
The Intermediate Representations (IRs) in Mesa: GLSL IR, Mesa IR, TGSI, and LLVM IR. Missing are HIR, LIR and NIR.
Mesa IR is due to be removed completely.

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

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.

GLSL IR

Mesa IR

NIR

TGSI

Main article: Tungsten Graphics Shader Infrastructure

The Tungsten Graphics Shader Infrastructure (TGSI) was introduced in 2008 by Tungsten Graphics. All Gallium3D-style UMDs ingest TGSI.

LLVM IR

Main article: LLVM Intermediate Representation

The UMDs radeonsi and llvmpipe do not output 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).

Gallium3D

Main article: Gallium3D
Gallium3D introduced the intermediate language TGSI (Tungsten Graphics Shader Infrastructure). Any shaders written in GLSL (or other shading languages as well) are translated into TGSI, this translation is supported by the hardware driver. The driver translates these TGSI shaders into the instruction set of the GPU it is written for.

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 2 November 2024, 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.[citation needed]

Performance

History

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).[2] 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.[68] 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.[81]

See also

References

  1. ^ Marshall, David (16 December 2008). "VMware's year end acquisition of Tungsten Graphics". InfoWorld. Retrieved 6 August 2011.
  2. ^ a b "Mesa Introduction". Mesa Team. Retrieved 8 June 2015.
  3. ^ "Mesa 17.0.1 release announcement". Retrieved 4 March 2017.
  4. ^ "Mesa Languages Page". Open Hub. Retrieved 2 March 2015.
  5. ^ "Mesa 3D license". Retrieved 3 June 2015.
  6. ^ "Improve OpenGL support for the Linux Graphics Drivers - Mesa". Indiegogo. 11 December 2013. Retrieved 21 January 2015.
  7. ^ "AMD exploring new Linux driver Strategy". 22 March 2014. Retrieved 23 March 2014.
  8. ^ https://www.phoronix.com/scan.php?page=news_item&px=MTQxMjk
  9. ^ "mesa/mesa - The Mesa 3D Graphics Library". Retrieved 2 November 2016.
  10. ^ "The OpenGL vs Mesa matrix". 25 March 2015. Retrieved 29 March 2015.
  11. ^ "Mesa 11.0 Has Been Branched, The Release March Begins". 22 August 2015. Retrieved 22 August 2015.
  12. ^ a b https://phoronix-media.com/scan.php?page=news_item&px=RADV-Mesa-Submission-ML
  13. ^ a b "Mesa 17.0.0 Officially Released". Phoronix. 13 February 2017. Retrieved 13 February 2017.
  14. ^ https://cgit.freedesktop.org/mesa/mesa/commit/?id=5b4aeb331a41f1a224f26adc4834bf1a2c9b5ac6
  15. ^ http://www.phoronix.com/scan.php?page=article&item=mesa-17-features&num=1
  16. ^ https://cgit.freedesktop.org/mesa/mesa/commit/?id=d2590eb65ff28a9cbd592353d15d7e6cbd2c6fc6
  17. ^ https://cgit.freedesktop.org/mesa/mesa/commit/?id=f0997e2aa8b5628a8cccbd5adf9b22a053c6be54
  18. ^ http://www.phoronix.com/scan.php?page=article&item=nouveau-maxwell-pipeline&num=1
  19. ^ http://www.phoronix.com/scan.php?page=news_item&px=OpenGL-CTS-Open-Source
  20. ^ "The OpenGL vs Mesa matrix". mesamatrix.net. Retrieved 31 July 2016.
  21. ^ "[Mesa-announce] mesa 17.0.0". Retrieved 13 February 2017.
  22. ^ https://mesa.freedesktop.org/archive/
  23. ^ https://www.mesa3d.org/relnotes/17.0.0.html
  24. ^ https://www.mesa3d.org/relnotes/17.0.1.html
  25. ^ https://dri.freedesktop.org/wiki/GalliumCompute/
  26. ^ https://www.x.org/wiki/Events/XDC2013/XDC2013TomStellardCloverStatus/XDC2013TomStellardCloverStatus.pdf
  27. ^ Larabel, Michael (4 March 2015). "OpenVG Support Stripped From Gallium3D". Phoronix. Retrieved 11 July 2015.
  28. ^ "latest patches to "nine" state tracker". 4 February 2016.
  29. ^ Larabel, Michael (14 December 2014). "Mesa 10.4 Officially Released With Direct3D 9 State Tracker". Phoronix. Retrieved 11 July 2015.
  30. ^ "[Mesa-announce] mesa 13.0.0". Retrieved 2 November 2016.
  31. ^ http://mesa3d.org/relnotes/13.0.1.html
  32. ^ http://mesa3d.org/relnotes/13.0.2html
  33. ^ http://mesa3d.org/relnotes/13.0.3.html
  34. ^ https://www.mesa3d.org/relnotes/13.0.4.html
  35. ^ https://www.mesa3d.org/relnotes/13.0.5.html
  36. ^ a b "Mesa 12.0 Released With OpenGL 4.3 Support, Intel Vulkan & Many Other Features". 8 July 2016. Retrieved 8 July 2016.
  37. ^ http://mesa3d.org/relnotes/12.0.1.html
  38. ^ http://mesa3d.org/relnotes/12.0.2.html
  39. ^ http://mesa3d.org/relnotes/12.0.3.html
  40. ^ http://mesa3d.org/relnotes/12.0.4.html
  41. ^ http://mesa3d.org/relnotes/12.0.5.html
  42. ^ http://mesa3d.org/relnotes/12.0.6.html
  43. ^ "[Mesa-announce] Mesa 11.2.0". Retrieved 4 April 2016.
  44. ^ http://mesa3d.org/relnotes/11.0.0.html
  45. ^ "[Mesa-announce] Mesa 11.1.0". Retrieved 15 December 2015.
  46. ^ "[Mesa-announce] Mesa 11.0.0". Retrieved 26 September 2015.
  47. ^ "[Mesa-announce] Mesa 10.6.0". Retrieved 15 June 2015.
  48. ^ Larabel, Michael (26 October 2013). "Features To Be Found In Mesa 10.0". Phoronix.
  49. ^ "[Mesa-announce] Mesa 10.5.0". Retrieved 7 March 2015.
  50. ^ "[Mesa-announce] Mesa 10.4.0 released". Retrieved 7 March 2015.
  51. ^ "[Mesa-announce] Mesa 10.3 released". Retrieved 7 March 2015.
  52. ^ "[Mesa-announce] Mesa 10.2 released". Retrieved 7 March 2015.
  53. ^ "[Mesa-announce] Mesa 10.1 released". Retrieved 7 March 2015.
  54. ^ "[Mesa-announce] Mesa 10.0 released". Retrieved 7 March 2015.
  55. ^ "Mesa 9.0 Release Notes". Mesa. 8 October 2012. Retrieved 11 July 2015.
  56. ^ http://www.phoronix.com/scan.php?page=article&item=radv-hits-mesa&num=1
  57. ^ "Bringing Android explicit fencing to the mainline". LWN.net. 5 October 2016.
  58. ^ "libgbm in the Debian repositories".
  59. ^ "Enabling Alternative Window Systems with a non-Mesa Graphics Driver Implementation".
  60. ^ "Nouveau Video Acceleration". freedesktop.org.
  61. ^ "Radeon Feature Matrix". freedesktop.org.
  62. ^ Toral, Iago (8 August 2014). "Diving into Mesa". Retrieved 19 May 2016.
  63. ^ "Direct Rendering Infrastructure Status Page". freedesktop.org.
  64. ^ http://apcmag.com/how-to-improve-gaming-performance-on-your-linux-machine.htm
  65. ^ http://www.geeks3d.com/20120110/linux-mesa-gallium3d-nouveau-and-nvidia-drivers-opengl-test-gtx-280-gtx-480-gtx-580/
  66. ^ https://www.phoronix.com/vr.php?view=18344
  67. ^ https://www.phoronix.com/scan.php?page=article&item=july_2013_gpus&num=8
  68. ^ a b c Paul, Brian (10 August 2000). "Introduction to the Direct Rendering Infrastructure". dri.sourceforge.net. Retrieved 25 January 2012.
  69. ^ "DRI2". X.org. Retrieved 25 January 2012.
  70. ^ https://lwn.net/Articles/570082/
  71. ^ https://lists.freedesktop.org/archives/dri-devel/2013-November/048258.html
  72. ^ "xorg-x11-drv-intel-2.99.917-19.20151206.fc23 (re)enabled dri3 by default - kde - Fedora Mailing-Lists". lists.fedoraproject.org. Retrieved 3 December 2016.
  73. ^ "Radeon-AMDGPU-1.19-Updates". www.google.de. Retrieved 3 December 2016.
  74. ^ "LLVMpipe: OpenGL With Gallium3D on Your CPU". Phoronix.com. 30 April 2010. Retrieved 4 November 2014.
  75. ^ "llvmpipe". mesa3d.org. Retrieved 8 June 2015.
  76. ^ http://openswr.org
  77. ^ https://mesamatrix.net
  78. ^ http://openswr.org/perf.html
  79. ^ "DRI megadrivers". 25 September 2013.
  80. ^ "VDPAU & XvMC state trackers are now separate libraries". 23 June 2014.
  81. ^ "What's the relationship between Glide and DRI?". dri.freedesktop.org. Retrieved 25 January 2012.
Various layers within Linux, also showing separation between the userland and kernel space
User mode User applications bash, LibreOffice, GIMP, Blender, 0 A.D., Mozilla Firefox, ...
System components init daemon:
OpenRC, runit, systemd... 		System daemons:
polkitd, smbd, sshd, udevd... 		Window manager:
X11, Wayland, SurfaceFlinger (Android) 		Graphics:
Mesa, AMD Catalyst, ... 		Other libraries:
GTK, Qt, EFL, SDL, SFML, FLTK, GNUstep, ...
C standard library fopen, execv, malloc, memcpy, localtime, pthread_create... (up to 2000 subroutines)
glibc aims to be fast, musl aims to be lightweight, uClibc targets embedded systems, bionic was written for Android, etc. All aim to be POSIX/SUS-compatible.
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[1]
Process scheduling subsystem IPC subsystem Memory management subsystem Virtual files subsystem Networking subsystem
Other components: ALSA, DRI, evdev, klibc, LVM, device mapper, Linux Network Scheduler, Netfilter
Linux Security Modules: SELinux, TOMOYO, AppArmor, Smack
Hardware (CPU, main memory, data storage devices, etc.)

  1. ^ "Admin Guide README". Kernel.org git repositories.
Retrieved from "https://en.wikipedia.org/w/index.php?title=Mesa_(computer_graphics)&oldid=771224979"