Editing Direct Rendering Infrastructure

{{short description|Framework}}
{{Infobox Software
| name                   = DRI
| title                  = DRI-1.0
| logo                   = 
| screenshot             = 
| caption                = 
| author                 = Precision Insight, Tungsten Graphics
| developer              = [[freedesktop.org]]
| released               = {{start date and age|1998|08}}<ref name="DRI history">{{cite web|last1=Owen|first1=Jens|title=The DRI project history|url=https://dri.freedesktop.org/wiki/DriHistory/|website=DRI project wiki|access-date=16 April 2016}}</ref>
| latest release version = 2.4.x
| latest release date    = February 2009
| programming language   = [[C (programming language)|C]]
| operating system       =
| platform               = [[POSIX]]
| size                   =
| genre                  = [[Software framework|Framework]] / [[Application programming interface|API]]
| license                = [[MIT license|MIT]] and other licenses<ref name="Mesa DRI License">[http://www.mesa3d.org/license.html Mesa DRI License] / Copyright Information - The Mesa 3D Graphics Library</ref>
| website                = {{URL|https://dri.freedesktop.org}}
}}
{{Infobox Software
| name                   = DRI
| title                  = DRI-2.0
| logo                   =
| screenshot             =
| caption                =
| author                 = [[Kristian Høgsberg]] et al.
| developer              = [[freedesktop.org]]
| released               = {{start date and age|2008|09|04}}<ref name="dri2proto spec 2.0" />
| latest release version = 2.8
| latest release date    = {{start date and age|2012|07|11}}<ref name="dri2proto 2.8" />
| latest preview version =
| latest preview date    =
| programming language   = [[C (programming language)|C]]
| operating system       = 
| platform               = [[POSIX]]
| size                   = 
| genre                  = [[Software framework|Framework]] / [[Application programming interface|API]]
| license                = [[MIT license|MIT]] and other licenses<ref name="Mesa DRI License"/>
| website                = {{URL|https://dri.freedesktop.org}}
}}
{{Infobox Software
| name                   = DRI
| title                  = DRI-3.0
| logo                   =
| screenshot             =
| caption                = 
| author                 = [[Keith Packard]] et al.
| developer              = [[freedesktop.org]]
| released               = {{start date and age|2013|11|01}}<ref name="dri3proto 1.0" />
| latest release version = 1.0
| latest release date    = {{start date and age|2013|11|01}}<ref name="dri3proto 1.0" />
| latest preview version =
| latest preview date    =
| programming language   = [[C (programming language)|C]]
| operating system       = 
| platform               = [[POSIX]]
| size                   = 
| genre                  = [[Software framework|Framework]] / [[Application programming interface|API]]
| license                = [[MIT license|MIT]] and other licenses<ref name="Mesa DRI License"/>
| website                = {{URL|https://dri.freedesktop.org}}
}}
[[File:Linux Graphics Stack 2013.svg|thumb|300px|There are two graphics hardware drivers: one resides inside of the X [[display server]]. There have been several designs of this driver. The current one splits it in two portions: DIX (Device-Independent X) and DDX (Device-Dependent X)]]
[[File:The Linux Graphics Stack and glamor.svg|thumb|300px|[[Glamor (software)|Glamor]] will simplify the [[X.Org Server|X server]], and {{mono|[[AMD Catalyst|libGL-fglrx-glx]]}} {{Update inline|date=May 2024|reason=libGL-fglrx-glx is no longer part of the current revision of this diagram, and the diagram has changed: previously there was no relationship between "Proprietary user mode graphics drivers" and "Mesa 3D", therefore facts seem to have changed}} could use the libDRM of the radeon open-source driver instead of the proprietary [[binary blob]].]]
[[File:Linux kernel and OpenGL video games.svg|thumb|300px|[[Rendering (computer graphics)|Rendering]] calculations are outsourced over [[OpenGL]] to the [[Graphics processing unit|GPU]] to be done in real-time. The '''DRI''' regulates access and book-keeping.]]

The '''Direct Rendering Infrastructure''' ('''DRI''') is the framework comprising the modern [[Linux]] graphics stack which allows unprivileged user-space programs to issue commands to [[graphics hardware]] without conflicting with other programs.<ref name="DRI wiki">{{cite web|title=Mesa 3D and Direct Rendering Infrastructure wiki|url=http://dri.freedesktop.org/wiki/|access-date=15 July 2014}}</ref> The main use of DRI is to provide hardware acceleration for the [[Mesa (computer graphics)|Mesa]] implementation of [[OpenGL]]. DRI has also been adapted to provide OpenGL acceleration on a [[Linux framebuffer|framebuffer console]] without a [[display server]] running.<ref>{{cite web|url=http://fbdri.sourceforge.net/|title=DRI for Framebuffer Consoles|access-date=January 4, 2019}}</ref>

DRI implementation is scattered through the [[X.Org Server|X Server]] and its associated client libraries, [[Mesa 3D]] and the [[Direct Rendering Manager]] kernel subsystem.<ref name="DRI wiki" /> All of its [[source code]] is [[open-source software]].

== Overview ==
In the classic [[X Window System]] architecture the X Server is the only process with exclusive access to the [[video card|graphics hardware]], and therefore the one which does the actual [[Rendering (computer graphics)|rendering]] on the [[framebuffer]]. All that X clients do is communicate with the X Server to dispatch rendering commands. Those commands are hardware independent, meaning that the [[X Window System core protocol|X11 protocol]] provides an [[Application programming interface|API]] that abstracts the graphics device so the X clients don't need to know or worry about the specifics of the underlying hardware. Any hardware-specific code lives inside the [[Device Dependent X]], the part of the X Server that manages each type of video card or graphics adapter and which is also often called the ''video'' or ''graphics driver''.

The rise of [[3D rendering]] has shown the limits of this architecture. [[3D computer graphics software|3D graphics applications]] tend to produce large amounts of commands and data, all of which must be dispatched to the X Server for rendering. As the amount of [[inter-process communication]] (IPC) between the X client and X Server increased, the 3D rendering performance suffered to the point that X driver developers concluded that in order to take advantage of 3D hardware capabilities of the latest graphics cards a new IPC-less architecture was required. X clients should have direct access to graphics hardware rather than relying on another process to do so, saving all the IPC overhead. This approach is called "direct rendering" as opposed to the "indirect rendering" provided by the classical X architecture. The ''Direct Rendering Infrastructure'' was initially developed to allow any X client to perform 3D rendering using this "direct rendering" approach.

Nothing prevents DRI from being used to implement accelerated 2D direct rendering within an X client.<ref name="dri2proto spec 2.0" /> Simply no one has had the need to do so because the 2D indirect rendering performance was good enough.

== Software architecture ==
The basic architecture of the Direct Rendering Infrastructure involves three main components:<ref name="Martin et all 1999 DRI low level">{{cite web|last1=Martin|first1=Kevin E.|last2=Faith|first2=Rickard E.|last3=Owen|first3=Jens|last4=Akin|first4=Allen|title=Direct Rendering Infrastructure, Low-Level Design Document|url=http://dri.sourceforge.net/doc/design_low_level.html|access-date=18 May 2016|date=11 May 1999|archive-date=23 July 2016|archive-url=https://web.archive.org/web/20160723091323/http://dri.sourceforge.net/doc/design_low_level.html|url-status=dead}}</ref>
* the DRI client &mdash;for example, an X client performing "direct rendering"&mdash; needs a hardware-specific "driver" able to manage the current video card or graphics adapter in order to render on it. These ''DRI drivers'' are typically provided as [[shared libraries]] to which the client is [[Dynamic linker|dynamically linked]]. Since DRI was conceived to take advantage of 3D graphics hardware, the libraries are normally presented to clients as hardware-accelerated implementations of a 3D API such as [[OpenGL]], provided by either the 3D-hardware vendor itself or a third party such as the [[Mesa 3D]] [[free software]] project.
* the X Server provides an [[X Window System core protocol|X11 protocol extension]] &mdash;the DRI extension&mdash; that the DRI clients use to coordinate with both the [[windowing system]] and the DDX driver.<ref name="DRI extension">{{cite web|last1=Owen|first1=Jens|last2=Martin|first2=Kevin|title=DRI Extension for supporting Direct Rendering - Protocol Specification|url=http://dri.sourceforge.net/doc/dri_extensions_low_level.txt|access-date=18 May 2016|date=11 May 1999}}</ref> As part of the DDX driver, it's quite common that the X Server process also dynamically links to the same DRI driver that the DRI clients do, but to provide hardware-accelerated 3D rendering to the X clients using the [[GLX]] extension for indirect rendering (for example, remote X clients that can't use direct rendering). For 2D rendering, the DDX driver must also take into account the DRI clients using the same graphics device.
* the access to the video card or graphics adapter is regulated by a kernel component called the [[Direct Rendering Manager]] (DRM).<ref name="Faith 1999">{{cite web|last1=Faith|first1=Rickard E.|title=The Direct Rendering Manager: Kernel Support for the Direct Rendering Infrastructure|url=https://dri.sourceforge.net/doc/drm_low_level.html|date=11 May 1999|access-date=18 May 2016|archive-date=21 May 2024|archive-url=https://web.archive.org/web/20240521055530/https://dri.sourceforge.net/doc/drm_low_level.html|url-status=dead}}</ref> Both the X Server's DDX driver and each X client's DRI driver must use DRM to access the graphics hardware. DRM provides [[Synchronization (computer science)|synchronization]] to the shared resources of the graphics hardware &mdash;resources such as the command queue, the card registers, the video memory, the DMA engines, ...&mdash; ensuring that the concurrent access of all those multiple competing user-space processes don't interfere with each other. DRM also serves as a basic security enforcer that doesn't allow any X client to access the hardware beyond what it needs to perform the 3D rendering.

== DRI1 ==
In the original DRI architecture, due to the memory size of [[video card]]s at that time, there was a single instance of the screen [[front buffer]] and [[back buffer]] (also of the ancillary [[depth buffer]] and [[stencil buffer]]), shared by all the DRI clients and the X Server.<ref name="Packard 2008" /><ref name="Packard 2009" /> All of them rendered directly onto the back buffer, that was [[Page flipping|swapped]] with the front buffer at [[vertical blanking interval]] time.<ref name="Packard 2008" /> In order to render to the back buffer, a DRI process should ensure that the rendering was [[Clipping (computer graphics)|clipped]] to the area reserved for its [[Window (computing)|window]].<ref name="Packard 2008" /><ref name="Packard 2009" />

The [[Synchronization (computer science)|synchronization]] with the X Server was done through [[Unix signal|signals]] and a [[shared memory]] buffer called the SAREA.<ref name="Packard 2009" /> The access to the DRM device was exclusive, so any DRI client had to [[Lock (computer science)|lock]] it at the beginning of a [[Rendering (computer graphics)|rendering]] operation. Other users of the device &mdash;including the X Server&mdash; were blocked in the meantime, and they had to wait until the lock was released at the end of the current rendering operation, even if it wouldn't be any conflict between both operations.<ref name="Packard 2009" /> Another drawback was that operations didn't retain memory allocations after the current DRI process released its lock on the device, so any data uploaded to the graphics memory such as [[Texture mapping|textures]] were lost for upcoming operations, causing a significant impact on graphics performance.

Nowadays DRI1 is considered completely obsolete and must not be used.

== DRI2 ==
Due to the increasing popularity of [[compositing window manager]]s like [[Compiz]], the Direct Rendering Infrastructure had to be redesigned so that X clients could also support redirection to "offscreen pixmaps" while doing direct rendering. Regular X clients already respected the redirection to a separate pixmap provided by the X Server as a render target &mdash;the so-called offscreen pixmap&mdash;, but DRI clients continued to do the rendering directly into the shared backbuffer, effectively bypassing the compositing window manager.<ref name="Packard 2008" /><ref name="Høgsberg 2007">{{cite web|last1=Høgsberg|first1=Kristian|title=Redirected direct rendering|url=http://hoegsberg.blogspot.com/2007/08/redirected-direct-rendering.html|date=8 August 2007|access-date=25 May 2016}}</ref> The ultimate solution was to change the way DRI handled the render buffers, which led to a completely different DRI extension with a new set of operations, and also major changes in the [[Direct Rendering Manager]].<ref name="dri2proto spec 2.0" /> The new extension was named "DRI2", although it's not a later version but a different extension not even compatible with the original DRI &mdash;in fact both have coexisted within the X Server for a long time.

In DRI2, instead of a single shared (back) buffer, every DRI client gets its own private [[back buffer]]<ref name="Packard 2008" /><ref name="Packard 2009" /> &mdash;along with their associated [[depth buffer|depth]] and [[stencil buffer|stencil]] buffers&mdash; to render its [[Window (computing)|window]] content using the [[hardware acceleration]]. The DRI client then [[Page flipping|swaps]] it with a false "[[front buffer]]",<ref name="Packard 2009" /> which is used by the compositing window manager as one of the sources to compose (build) the final screen back buffer to be swapped at the [[Vertical blanking interval|VBLANK interval]] with the real front buffer.

To handle all these new buffers, the Direct Rendering Manager had to incorporate new functionality, specifically a graphics [[Memory management|memory manager]]. DRI2 was initially developed using the experimental [[Direct Rendering Manager#Translation Table Maps|TTM]] memory manager,<ref name="Packard 2008" /><ref name="Høgsberg 2007" /> but it was later rewritten to use [[Graphics Execution Manager|GEM]] after it was chosen as the definitive DRM memory manager.<ref name="Høgsberg DRI2 GEM" /> The new DRI2 internal buffer management model also solved two major performance bottlenecks present in the original DRI implementation:

* DRI2 clients no longer lock the entire DRM device while using it for rendering, since now each client gets a separate render buffer independent from the other processes.<ref name="Packard 2009" />
* DRI2 clients can allocate their own buffers (with textures, vertex lists, ...) in the video memory and keep them as long as they want, which significantly reduces video [[memory bandwidth]] consumption.

In DRI2, the allocation of the private offscreen buffers (back buffer, fake front buffer, depth buffer, stencil buffer, ...) for a window is done by the X Server itself.<ref name="Packard 2012 DRI-Next" /><ref name="Willis 2013" /> DRI clients retrieve those buffers to do the rendering into the window by calling operations such as {{mono|DRI2GetBuffers}} and {{mono|DRI2GetBuffersWithFormat}} available in the DRI2 extension.<ref name="dri2proto spec 2.0" /> Internally, DRI2 uses ''GEM names'' &mdash;a type of global handle provided by the [[Graphics Execution Manager|GEM API]] that allows two processes accessing a DRM device to refer to the same buffer&mdash; for passing around "references" to those buffers through the [[X Window System core protocol|X11 protocol]].<ref name="Willis 2013" /> The reason why the X Server is in charge of the buffer allocation of the render buffers of a window is that the [[GLX|GLX extension]] allows for multiple X clients to do [[OpenGL]] rendering cooperatively in the same window.<ref name="Packard 2012 DRI-Next" /> This way, the X Server manages the whole lifecycle of the render buffers along the entire rendering process and knows when it can safely recycle or discard them. When a window resize is performed, the X Server is also responsible for allocating new render buffers matching the new window size, and notifying the change to the DRI client(s) rendering into the window using an InvalidateBuffers event, so they would retrieve the GEM names of the new buffers.<ref name="Packard 2012 DRI-Next" />

The DRI2 extension provides other core operations for the DRI clients, such as finding out which DRM device and driver they should use ({{mono|DRI2Connect}}) or getting authenticated by the X Server in order to be able to use the rendering and buffer facilities of the DRM device ({{mono|DRI2Authenticate}}).<ref name="dri2proto spec 2.0" /> The presentation of the rendered buffers in the screen is performed using the {{mono|DRI2CopyRegion}} and {{mono|DRI2SwapBuffers}} requests. {{mono|DRI2CopyRegion}} can be used to do a copy between the fake front buffer and the real front buffer, but it doesn't provide any synchronization with the vertical blanking interval, so it can cause ''tearing''. {{mono|DRI2SwapBuffers}}, on the other hand, performs a VBLANK-synchronized swap between back and front buffer, if it's supported and both buffers have the same size, or a copy ([[Bit blit|blit]]) otherwise.<ref name="dri2proto spec 2.0" /><ref name="Packard 2012 DRI-Next" />

== DRI3 ==
Although DRI2 was a significant improvement over the original DRI, the new extension also introduced some new issues.<ref name="Packard 2012 DRI-Next" /><ref name="Willis 2013" /> In 2013, a third iteration of the Direct Rendering Infrastructure known as DRI3 was developed in order to fix those issues.<ref name="Packard 2013 DRI3000" />

The main differences of DRI3 compared to DRI2 are:

* DRI3 clients allocate their render buffers, instead of relying on the X Server for doing the allocation, which was the method supported by DRI2.<ref name="Packard 2012 DRI-Next" /><ref name="Willis 2013" />
* DRI3 gets rid of the old insecure [[Graphics Execution Manager|GEM]] buffer sharing mechanism based on ''GEM names'' (global GEM handles) for passing buffer objects between a DRI client and the X Server in favor of the one more secure and versatile based on [[Direct Rendering Manager#PRIME|PRIME DMA-BUFs]], which uses [[file descriptor]]s instead.<ref name="Packard 2012 DRI-Next" /><ref name="Willis 2013" />

Buffer allocation on the client side breaks [[GLX]] assumptions in the sense that it's no longer possible for multiple GLX applications to render cooperatively in the same window. On the plus side, the fact that the DRI client is in charge of its own buffers throughout their lifetime brings many advantages. For example, it is easy for the DRI3 client to ensure that the size of the render buffers always match the current size of the window, and thereby eliminate the artifacts due to the lack of synchronization of buffer sizes between client and server that plagued window resizing in DRI2.<ref name="Packard 2012 DRI-Next" /><ref name="Willis 2013" /><ref name="Packard 2013 DRI3" /> A better performance is also achieved because now DRI3 clients save the extra round trip waiting for the X Server to send the render buffers.<ref name="Willis 2013" /> DRI3 clients, and especially compositor window managers, can take advantage of keeping older buffers of previous frames and reusing them as the basis on which to render only the damaged parts of a window as another performance optimization.<ref name="Packard 2012 DRI-Next" /><ref name="Willis 2013" /> The DRI3 extension no longer needs to be modified to support new particular buffer formats, since they are now handled directly between the DRI client driver and the DRM kernel driver.<ref name="Packard 2012 DRI-Next" /> The use of file descriptors, on the other hand, allows the kernel to perform a safe cleanup of any unused GEM buffer object &mdash;one with no reference to it.<ref name="Packard 2012 DRI-Next" /><ref name="Willis 2013" />

Technically, DRI3 consists of two different extensions, the "DRI3" extension and the "Present" extension.<ref name="Packard 2013 DRI3000" /><ref name="Edge 2013" /> The main purpose of the DRI3 extension is to implement the mechanism to share direct rendered buffers between DRI clients and the X Server.<ref name="Packard 2013 DRI3" /><ref name="Edge 2013" /><ref name="dri3proto spec" /> DRI clients allocate and use GEM buffers objects as rendering targets, while the X Server represents these render buffers using a type of X11 object called "pixmap". DRI3 provides two operations, {{mono|DRI3PixmapFromBuffer}} and {{mono|DRI3BufferFromPixmap}}, one to create a pixmap (in "X Server space") from a GEM buffer object (in "DRI client space"), and the other to do the reverse and get a GEM buffer object from an X pixmap.<ref name="Packard 2013 DRI3" /><ref name="Edge 2013" /><ref name="dri3proto spec" /> In these DRI3 operations GEM buffer objects are passed as [[DMA-BUF]] file descriptors instead of GEM names. DRI3 also provides a way to share synchronization objects between the DRI client and the X Server, allowing both a serialized access to the shared buffer.<ref name="Edge 2013" /> Unlike DRI2, the initial {{mono|DRI3Open}} operation &mdash;the first every DRI client must request to know which DRM device to use&mdash; returns an already open file descriptor to the device node instead of the device node filename, with any required authentication procedure already performed in advance by the X Server.<ref name="Packard 2013 DRI3" /><ref name="Edge 2013" />

DRI3 provides no mechanism to show the rendered buffers on the screen, but relies on another extension, the ''Present'' extension, to do so.<ref name="dri3proto spec" /> ''Present'' is so named because its main task is to "present" buffers on the screen, meaning that it handles the update of the framebuffer using the contents of the rendered buffers delivered by client applications.<ref name="Edge 2013" /> Screen updates have to be done at the proper time, normally during the [[vertical blanking interval|VBLANK interval]] in order to avoid display artifacts such as ''[[Screen tearing|tearing]]''. Present also handles the synchronization of screen updates to the VBLANK interval.<ref name="presentproto spec" /> It also keeps the X client informed about the instant each buffer is really shown on the screen using events, so the client can synchronize its rendering process with the current screen refresh rate.

Present accepts any X pixmap as the source for a screen update.<ref name="presentproto spec" /> Since pixmaps are standard X objects, Present can be used not only by DRI3 clients performing direct rendering, but also by any X client rendering on a pixmap by any means.<ref name="Packard 2013 DRI3" /> For example, most existing non-[[OpenGL|GL]] based [[GTK+]] and [[Qt (software)|Qt]] applications used to do [[double buffer]]ed pixmap rendering using [[XRender]]. The Present extension can also be used by these applications to achieve efficient and non-tearing screen updates. This is the reason why Present was developed as a separate standalone extension instead of being part of DRI3.<ref name="Packard 2013 DRI3" />

Apart from allowing non-GL X clients to synchronize with VBLANK, Present brings other advantages. DRI3 graphics performance is better because Present is more efficient than DRI2 in swapping buffers.<ref name="Edge 2013" /> A number of OpenGL extensions that weren't available with DRI2 are now supported based on new features provided by Present.<ref name="Edge 2013" />

Present provides two main operations to X clients: update a region of a window using part of or all the contents of a pixmap ({{mono|PresentPixmap}}) and set the type of presentation events related to a certain window that the client wants to be notified about ({{mono|PresentSelectInput}}).<ref name="Edge 2013" /><ref name="presentproto spec" /> There are three presentation events about which a window can notify an X client: when an ongoing presentation operation &mdash;normally from a call to {{mono|PresentPixmap}}&mdash; has been completed ({{mono|PresentCompleteNotify}}), when a pixmap used by a {{mono|PresentPixmap}} operation is ready to be reused ({{mono|PresentIdleNotify}}) and when the window configuration &mdash;mostly window size&mdash; changes ({{mono|PresentConfigureNotify}}).<ref name="Edge 2013" /><ref name="presentproto spec" /> Whether a {{mono|PresentPixmap}} operation performs a direct copy ([[Bit blit|blit]]) onto the front buffer or a [[Page flipping|swap]] of the entire back buffer with the front buffer is an internal detail of the Present extension implementation, instead of an explicit choice of the X client as it was in DRI2.

== Adoption ==
{{Update-section|date=June 2020}}
Several open source DRI drivers have been written, including ones for [[ATI Technologies|ATI]] Mach64, ATI Rage128, ATI Radeon, 3dfx Voodoo3 through Voodoo5, [[Matrox]] G200 through G400, SiS 300-series, [[Intel]] i810 through i965, [[S3 Graphics|S3]] Savage, [[VIA Technologies|VIA]] UniChrome graphics chipsets, and [[nouveau (graphics)|nouveau]] for [[Nvidia]]. Some graphics vendors have written closed-source DRI drivers, including [[ATI Technologies|ATI]] and [[PowerVR]] Kyro.

The various versions of DRI have been implemented by various operating systems, amongst others by the [[Linux kernel]], [[FreeBSD]], [[NetBSD]], [[OpenBSD]], and [[OpenSolaris]].

== History ==
The project was started by Jens Owen and Kevin E. Martin from Precision Insight (funded by [[Silicon Graphics]] and [[Red Hat]]).<ref name="DRI history"/><ref name="DRI design document">{{cite web|last1=Owen|first1=Jens|last2=Martin|first2=Kevin E.|title=A Multipipe Direct Rendering Architecture for 3D|url=http://dri.sourceforge.net/doc/design_high_level.html|date=15 September 1998|access-date=16 April 2016|archive-date=3 March 2016|archive-url=https://web.archive.org/web/20160303230126/http://dri.sourceforge.net/doc/design_high_level.html|url-status=dead}}</ref> It was first made widely available as part of [[XFree86]] 4.0<ref name="DRI history"/><ref>{{cite web|title=Release Notes for XFree86 4.0|url=http://www.xfree86.org/4.0/RELNOTES2.html#12|website=XFree86 Project|date=7 March 2000|access-date=16 April 2016}}</ref> and is now part of the [[X.Org Server]]. It is currently maintained by the [[free software community]].

Work on DRI2 started at the 2007 X Developers' Summit from a proposal by [[Kristian Høgsberg]].<ref>{{cite web|title=X Developers' Summit 2007 - Notes|url=http://www.x.org/wiki/Events/XDS2007/Notes/|website=X.Org|access-date=7 March 2016}}</ref><ref>{{cite mailing list|mailing-list=xorg|last=Høgsberg|first=Kristian|title=DRI2 Design Wiki Page|date=3 October 2007|url=https://lists.x.org/archives/xorg/2007-October/028746.html}}</ref> Høgsberg himself wrote the new DRI2 extension and the modifications to [[Mesa (computer graphics)|Mesa]] and [[GLX]].<ref>{{cite mailing list|mailing-list=xorg|last=Høgsberg|first=Kristian|title=Plans for merging DRI2 work|date=4 February 2008|url=https://lists.x.org/archives/xorg/2008-February/032412.html}}</ref> In March 2008 DRI2 was mostly done,<ref>{{cite mailing list|mailing-list=xorg|last=Høgsberg|first=Kristian|title=DRI2 committed|date=15 February 2008|url=https://lists.x.org/archives/xorg/2008-February/032693.html}}</ref><ref>{{cite mailing list|mailing-list=xorg|last=Høgsberg|first=Kristian|title=DRI2 direct rendering|date=31 March 2008|url=https://lists.x.org/archives/xorg/2008-March/034048.html}}</ref><ref name="Høgsberg 2008 DRI2">{{cite web|last1=Høgsberg|first1=Kristian|title=DRI2 Direct Rendering|url=http://hoegsberg.blogspot.com/2008/03/i-just-committed-last-bit-of-dri2-work.html|date=31 March 2008|access-date=20 April 2016}}</ref> but it couldn't make into [[X.Org Server]] version 1.5<ref name="Høgsberg DRI2 GEM">{{cite mailing list|mailing-list=xorg|last=Høgsberg|first=Kristian|title=Backing out DRI2 from server 1.5|date=4 August 2008|url=https://lists.x.org/archives/xorg/2008-August/037512.html}}</ref> and had to wait until version 1.6 from February 2009.<ref>{{cite web|title=Server 1.6 branch|url=http://www.x.org/wiki/Server16Branch/|website=X.org|access-date=7 February 2015}}</ref> The DRI2 extension was officially included in the X11R7.5 release of October 2009.<ref>{{cite web|title=Release Notes for X11R7.5|url=http://www.x.org/releases/X11R7.5/doc/RELNOTES.html|website=X.Org|access-date=20 April 2016}}</ref> The first public version of the DRI2 protocol (2.0) was announced in April 2009.<ref name="dri2proto 2.0">{{cite mailing list|mailing-list=xorg-announce|last=Høgsberg|first=Kristian|title=[ANNOUNCE] dri2proto 2.0|date=20 April 2009|url=https://lists.x.org/archives/xorg-announce/2009-April/000827.html}}</ref> Since then there have been several revisions, the most recent being version 2.8 from July 2012.<ref name="dri2proto 2.8">{{cite mailing list|mailing-list=xorg-announce|last=Airlie|first=Dave|title=[ANNOUNCE] dri2proto 2.8|date=11 July 2012|url=https://lists.freedesktop.org/archives/xorg-announce/2012-July/002001.html}}</ref>

Due to several limitations of DRI2, a new extension called DRI-Next was proposed by Keith Packard and Emma Anholt at the X.Org Developer's Conference 2012.<ref name="Packard 2012 DRI-Next" /> The extension was proposed again as DRI3000 at [[Linux.conf.au]] 2013.<ref name="Willis 2013" /><ref name="Packard 2013 DRI3000" /> DRI3 and Present extensions were developed during 2013 and merged into the X.Org Server 1.15 release from December 2013.<ref>{{cite web|last1=Packard|first1=Keith|title=[ANNOUNCE] xorg-server 1.14.99.901|url=http://lists.freedesktop.org/archives/xorg/2013-November/056148.html|website=X.org|date=November 2013 |access-date=9 February 2015}}</ref><ref>{{cite web|last1=Larabel|first1=Michael|title=X.Org Server 1.15 Release Has Several New Features|url=https://www.phoronix.com/scan.php?page=news_item&px=MTU1NDQ|website=Phoronix|access-date=9 February 2015}}</ref> The first and only version of the DRI3 protocol (1.0) was released in November 2013.<ref name="dri3proto 1.0">{{cite mailing list|mailing-list=xorg-announce|last=Packard|first=Keith|title=[ANNOUNCE] dri3proto 1.0|date=1 November 2013|url=https://lists.x.org/archives/xorg-announce/2013-November/002349.html}}</ref>

<gallery>
Linux graphics drivers 2D.svg|2D drivers inside of the [[display server|X server]]
Linux graphics drivers Utah GLX.svg|Indirect rendering over [[GLX]], using [[Utah GLX]]; separate: [[fbdev]]
Linux graphics drivers DRI early.svg|Early DRI: [[Mode setting]] is still being performed by the [[X display server]], which forces it to be run as [[superuser|root]]
Linux graphics drivers DRI current.svg|Finally all access goes through the [[Direct Rendering Manager]]
Linux graphics drivers DRI Wayland.svg|In Linux kernel 3.12 ''render nodes'' were introduced; [[Direct Rendering Manager|DRM]] and the [[KMS driver]] were split. [[Wayland (display server protocol)|Wayland]] implements direct rendering over [[EGL (API)|EGL]]
</gallery>

== See also ==
{{Portal|Free Software}}
* [[Direct Rendering Manager]]
* [[Mesa (computer graphics)|Mesa 3D]]
* [[X Window System]]

== References ==
{{reflist|30em|refs=
<ref name="dri2proto spec 2.0">{{cite web|last1=Høgsberg|first1=Kristian|title=The DRI2 Extension - Version 2.0|url=https://www.x.org/releases/X11R7.7/doc/dri2proto/dri2proto.txt|website=X.Org|date=4 September 2008|access-date=29 May 2016}}</ref>
<ref name="dri3proto spec">{{cite web|last1=Packard|first1=Keith|title=The DRI3 Extension - Version 1.0|url=https://cgit.freedesktop.org/xorg/proto/dri3proto/tree/dri3proto.txt|date=4 June 2013|access-date=30 May 2016}}</ref>
<ref name="presentproto spec">{{cite web|last1=Packard|first1=Keith|title=The Present Extension - Version 1.0|url=https://cgit.freedesktop.org/xorg/proto/presentproto/tree/presentproto.txt|date=6 June 2013|access-date=1 June 2016}}</ref>
<ref name="Edge 2013">{{cite web|last1=Edge|first1=Jake|title=DRI3 and Present|url=https://lwn.net/Articles/569701/|website=LWN.net|date=9 October 2013|access-date=26 May 2016}}</ref>
<ref name="Packard 2008">{{cite web|last1=Packard|first1=Keith|title=X output status july 2008|url=http://keithp.com/blogs/X_output_status_july_2008/|date=21 July 2008|access-date=26 May 2016}}</ref>
<ref name="Packard 2009">{{cite web|last1=Packard|first1=Keith|title=Sharpening the Intel Driver Focus|url=http://keithp.com/blogs/Sharpening_the_Intel_Driver_Focus/|date=24 April 2009|access-date=26 May 2016}}</ref>
<ref name="Packard 2012 DRI-Next">{{cite web|last1=Packard|first1=Keith|title=Thoughts about DRI.Next|url=http://keithp.com/blogs/DRI-Next/|date=28 September 2012|access-date=26 May 2016}}</ref>
<ref name="Packard 2013 DRI3000">{{cite web|last1=Packard|first1=Keith|title=DRI3000 — Even Better Direct Rendering|url=http://keithp.com/blogs/DRI3000/|date=19 February 2013|access-date=26 May 2016}}</ref>
<ref name="Packard 2013 DRI3">{{cite web|last1=Packard|first1=Keith|title=Completing the DRI3 Extension|url=http://keithp.com/blogs/dri3_extension/|date=4 June 2013|access-date=31 May 2016}}</ref>
<ref name="Willis 2013">{{cite web|last1=Willis|first1=Nathan|title=LCA: The X-men speak|url=https://lwn.net/Articles/536484/|website=LWN.net|date=11 February 2013|access-date=26 May 2016}}</ref>
}}

== External links ==
{{Commons category}}
* [http://dri.freedesktop.org/wiki/ Direct Rendering Infrastructure project home page]
* Current specification documents (always updated to the most recent version):
** [https://cgit.freedesktop.org/xorg/proto/dri2proto/tree/dri2proto.txt The DRI2 Extension] (Kristian Høgsberg, 2008)
** [http://cgit.freedesktop.org/xorg/proto/dri3proto/tree/dri3proto.txt The DRI3 Extension] (Keith Packard, 2013)
** [https://cgit.freedesktop.org/xorg/proto/presentproto/tree/presentproto.txt The Present Extension] (Keith Packard, 2013)

{{Freedesktop.org}}

[[Category:Direct Rendering Infrastructure| ]]
[[Category:Freedesktop.org]]