Mesa (computer graphics) | Wikipedia audio article

Mesa, also called Mesa3D and The Mesa 3D Graphics
Library, is an open source software implementation of OpenGL, Vulkan, and other graphics API
specifications. Mesa translates these specifications to vendor-specific
graphics hardware drivers. Its most important users are two graphics
drivers mostly developed and funded by Intel and AMD for their respective hardware (AMD
promotes their Mesa drivers Radeon and RadeonSI over the deprecated AMD Catalyst, and Intel
has only supported the Mesa driver). Proprietary graphics drivers (e.g. Nvidia
GeForce driver and Catalyst) replace all of Mesa, providing their own implementation of
a graphics API. An open-source effort to write a Mesa Nvidia
driver called Nouveau is mostly developed by the community. Besides 3D applications such as games, modern
display servers (’s Glamor or Wayland’s Weston) use OpenGL/EGL; therefore all graphics
typically go through Mesa. Mesa is hosted by 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.==Overview=====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 (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 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 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).1st stable version of 2017 is 17.0 (new year Counting). 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.Note that due to the modularized
nature of OpenGL, Mesa can actually 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.An open question for Mesa and Linux is High Dynamic
Range (HDR). Many problems and open points are in pipe
for a clean and basic implementation.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 Cannonlake 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.====Table of Rendering APIs========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.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.====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.====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 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/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: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 VAAPIFor 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.Please note, that V4L2 is a kernel-to-user-space interface
for video bit streams delivered by webcams or TV tuners.===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 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 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.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.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 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. Since Mesa 10.x OpenGL 3.3+ is supported for
Softpipe (10.3) and LLVMpipe (10.2). Actual 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. Only change to option “GALLIUM_DRIVER=”swr”
is necessary. 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.===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. 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. 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==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 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 graphics applications output
SPIR-V instead of GLSL. In contrast to the latter, SPIR-V is binary
to avoid implementation differences between GLSL compiler frontends of different driver
implementations, as this has been a major source of application incompatiblities and
bugs. Also SPIR-V binary usually also passed through
some general optimizations. Also to some degree, SPIR-V’s binary representation
offers some degree of obfuscation, which might appeal to some software vendors as a form
of intellectual property protection; however it should be noted, that SPIR-V contains ample
information for reflection and tools exist that translate SPIR-V back into high quality,
human readable high level code. A UMD needs only apply optimizations, that
are specific to the supported hardware. SPIR-V Specification (Provisional)====GLSL IR==== 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, IR========NIR====
Connor Abbott – NIR, or moving beyond GLSL IR in Mesa XDC2014
(Mesa-dev) 2014-12-15 Reintroducing NIR, a new IR for mesa Tungsten Graphics Shader Infrastructure
(TGSI) was introduced in 2008 by Tungsten Graphics. All Gallium3D-style UMDs ingest TGSI.====LLVM IR====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==
Gallium3D is a set of interfaces and a collection of supporting libraries intended to ease the
programming of device drivers for 3D graphics chipsets for multiple operating systems, rendering
or video acceleration APIs. A feature matrix is being provided at GalliumStatus,
and the efforts of writing free and open-source device drivers for graphics chips is being
separately documented in the Wikipedia: Free and open-source graphics device driver. The development of Gallium3D started in 2008
at Tungsten Graphics, and the implementation is available as free and open-source software
as part of Mesa 3D hosted by The primary goal of making driver development
easier, bundling otherwise duplicated code of several different drivers at a single point,
and to support modern hardware architectures. This is done by providing a better division
of labor, for example, leaving memory management to the kernel DRI driver. Gallium3D has been a part of Mesa since 2009
and is currently used by the free and open-source graphics driver for Nvidia (nouveau project),
for R300–R900, and for other free and open-source GPU device drivers.===Software architecture===
Gallium3D eases programming of device drivers by splitting the graphics device driver into
three parts. This is accomplished by the introduction of
two interfaces: Gallium3D State Tracker Interface and the Gallium3D WinSys Interface. The three components are called: Gallium3D State Tracker
Each graphical API by which a device driver is being addressed has its own State Tracker,
e.g. there is a Gallium3D State Tracker for OpenGL and a different one for Direct3D or
GLX. Each State Tracker contains an implementation
of the Gallium3D State Tracker Interface, and is unique, this means is shared by all
existent Gallium3D device drivers. Gallium3D hardware device driver
This is the actual code, that is specific to the underlying 3D graphic accelerator,
but only as far as the Gallium3D WinSys Interface allows. There is a unique Gallium3D hardware device
driver for each available graphics chip and each implements the Gallium3D State Tracker
Interface as well as the Gallium3D WinSys Interface. The Gallium3D hardware device driver understands
only TGSI (Tungsten Graphics Shader Infrastructure), an intermediate language for describing shaders. This code translated shaders translated from
GLSL into TGSI further into instruction set implemented by the GPU. Gallium3D WinSys
This is specific to the underlying kernel of the operating system and each one implements
the Gallium3D WinSys Interface to interface with all available Gallium3D hardware device
drivers.====Differences from classic graphics drivers
====Gallium3D provides a unified API exposing
standard hardware functions, such as shader units found on modern hardware. Thus, 3D APIs such as OpenGL 1.x/2.x, OpenGL
3.x, OpenVG, GPGPU infrastructure or even Direct3D (as found in the Wine compatibility
layer) will need only a single back-end, called a state tracker, targeting the Gallium3D API. By contrast, classic-style DRI device drivers
require a different back-end for each hardware platform and several other APIs need translation
to OpenGL at the expense of code duplication. All vendor device drivers, due to their proprietary
and closed-source nature, are written that way meaning that, e.g. the AMD Catalyst implements
both OpenGL and Direct3D, and the vendor drivers for the GeForce have their implementations. Under Gallium3D, Direct Rendering Manager
(DRM) kernel drivers will manage the memory and Direct Rendering Interface (DRI2) drivers
will be more GPU processing oriented. During the transition period from userspace
modesetting to kernelspace modesetting some of the Mesa 3D drivers, such as the radeon
driver or Intel’s drivers, ended up supporting both DRI1 and DRI2 and used DRI2 if available
on the system. Gallium3D additionally requires a level of
shader support that is not available on older cards like e.g. ATi r100-r200 so users for
those cards need to keep using Mesa 3D with DRI2 for their 3D usage.====Tungsten Graphics Shader Infrastructure
====Tungsten Graphics Shader Infrastructure (TGSI)
is an Intermediate representation like LLVM Intermediate Representation or the new Standard
Portable Intermediate Representation (SPIR) to be used by the Vulkan API and OpenCL 2.1. Shaders written in OpenGL Shading Language
are to be translated/compiled into TGSI, then optimizations are made, and then the TGSI
shaders are being compiled into shaders for the instruction set of the used GPU.====LLVM usage====In addition, using the modular structure of
Gallium3D, there is an effort underway to use the LLVM compiler suite and create a module
to optimize shader code on the fly.The library represents each shader program using an extensible
binary intermediate representation called Tungsten Graphics Shader Infrastructure (TGSI)
which LLVM then translates into GLSL shaders optimized for target hardware.===Adoption===
Several free and open-source graphics device drivers, which have been, or are being written
based on information gained through clean-room reverse engineering, adopted the driver model
provided by Gallium3D, e.g. nouveau and others (see Free and open-source graphics device
driver for a complete list). The main reason may be that the Gallium3D
driver model lessens the amount of code required to be written. Of course, being licensed under a free software
license, this code can at any time by anybody be rewritten to implement the DRI-, or some
other, driver model.===History===
Original authors of Gallium3D were Keith Whitwell and Brian Paul at Tungsten Graphics (acquired
by VMware in 2008.====Milestones====
As of fall 2011, there were at least 10 known, mature and working Gallium3D drivers. Open-source drivers for Nvidia graphics cards
by the name of Nouveau team develops its drivers using the Gallium3D framework.2008-07-13:
Nouveau development is done exclusively for the Gallium framework. The old DRI driver was removed from the master
branch of the Mesa repository on The gallium-0.2 branch was merged into mainline
Master branch of Mesa. Development is done in Mesa mainline. 2009-02-25: Gallium3D can run on Linux as
well as FreeBSD kernels.2009-05-01: Zack Rusin from Tungsten Graphics added the OpenVG state
tracker to Mesa 3D, which enables Scalable Vector Graphics to be hardware-accelerated
by any Gallium3D-based driver. 2009-07-17: Mesa3D 7.5 is released, the first
version to include Gallium3D.2010-09-10: Initial support for the Evergreen GPUs was added to
the r600g driver.2010-09-21: There are two Gallium3D drivers for ATI hardware known as
r300g and r600g for R300-R500 and R600-Evergreen GPUs respectively. 2010-09-21: Major commits were made to the
code to support Direct3D 10 and 11. In time, this might offer the ability to use
recent Direct3D implementations on GNU/Linux systems. 2011-11-30: Intel 965g and Cell Gallium drivers
were removed from the master branch of Mesa as unmaintained and broken.2013-11-30: Mesa
10 with OpenGL 3.2, 3.3 and OpenCL 1.0+ 2014-11-18: Major commits were made to the
code to support Direct3D 9.2015-09-15: Mesa 11 with OpenGL 4.0, 4.1 and OpenCL 1.2 (incomplete)
2015-12-15: Mesa 11.1 Driver VIRGL for virtual machines with OpenGL 3.3
2016-07-08: Mesa 12 with OpenGL 4.2, 4.3 and Vulkan 1.0 (Intel ANV and AMD RADV)
2016-11-01: Mesa 13 with OpenGL 4.4 and OpenGL ES 3.2
2017-02-13: Mesa 17.0 with OpenGL 4.5 and freedreno driver with OpenGL 3.0 and 3.1
2017-05-10: Mesa 17.1 OpenGL 4.2+ for Intel Ivy Bridge (more than Intel driver for Windows,
OpenGL 3.3+ for Intel Open SWR Rasterizer (important for cluster Computer for huge simulations)
2017-12-08: Mesa 17.3 AMD Vulkan Driver RADV full compliant in Khronos Test of Vulkan 1.0
2018-05-18: Mesa 18.1 with Vulkan 1.1 (Intel ANV and AMD RADV)
2018-09-07: Mesa 18.2 with OpenGL 4.3 for Soft Driver VIRGL (important for virtual machines
in cloud Cluster Computer), OpenGL ES 3.1 for Freedreno with Adreno A5xx==Performance==
Performance comparison of free and open-source graphics device drivers==
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). 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.==See also==
Free and open-source graphics device driver

Posts Tagged with…

Write a Comment

Your email address will not be published. Required fields are marked *