Editing Direct Rendering Infrastructure (section)

== 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" />