Direct Rendering Infrastructure
DRI has also been adapted to provide OpenGL acceleration on a framebuffer console without a display server running.
[7] DRI implementation is scattered through the X Server and its associated client libraries, Mesa 3D and the Direct Rendering Manager kernel subsystem.
In the classic X Window System architecture the X Server is the only process with exclusive access to the graphics hardware, and therefore the one which does the actual rendering on the framebuffer.
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.
[12] The access to the DRM device was exclusive, so any DRI client had to lock it at the beginning of a rendering operation.
[12] 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 textures were lost for upcoming operations, causing a significant impact on graphics performance.
Regular X clients already respected the redirection to a separate pixmap provided by the X Server as a render target —the so-called offscreen pixmap—, but DRI clients continued to do the rendering directly into the shared backbuffer, effectively bypassing the compositing window manager.
[15][16][18] 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.
[15] The use of file descriptors, on the other hand, allows the kernel to perform a safe cleanup of any unused GEM buffer object —one with no reference to it.
[17][19] The main purpose of the DRI3 extension is to implement the mechanism to share direct rendered buffers between DRI clients and the X Server.
[19] Screen updates have to be done at the proper time, normally during the VBLANK interval in order to avoid display artifacts such as tearing.
[18] For example, most existing non-GL based GTK+ and Qt applications used to do double buffered pixmap rendering using XRender.
Some graphics vendors have written closed-source DRI drivers, including 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.
The project was started by Jens Owen and Kevin E. Martin from Precision Insight (funded by Silicon Graphics and Red Hat).
[4] 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.
