Editing Direct Rendering Infrastructure (section)

== 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.