*** Welcome to piglix ***

Direct Rendering Infrastructure

DRI-1.0
Original author(s) Precision Insight, Tungsten Graphics
Developer(s) freedesktop.org
Initial release August 1998; 18 years ago (1998-08)
Stable release
2.4.x / February 2009
Development status maintained, marked for obsoletion
Written in C
Platform POSIX
Type Framework / API
License MIT and other licenses
Website dri.freedesktop.org
DRI-2.0
Original author(s) Kristian Høgsberg et al.
Developer(s) freedesktop.org
Initial release September 4, 2008; 8 years ago (2008-09-04)
Stable release
2.8 / July 11, 2012; 4 years ago (2012-07-11)
Development status active
Written in C
Platform POSIX
Type Framework / API
License MIT and other licenses
Website dri.freedesktop.org
DRI-3.0
Original author(s) Keith Packard et al.
Developer(s) freedesktop.org
Initial release November 1, 2013; 3 years ago (2013-11-01)
Stable release
1.0 / November 1, 2013; 3 years ago (2013-11-01)
Development status active
Written in C
Platform POSIX
Type Framework / API
License MIT and other licenses
Website dri.freedesktop.org

The Direct Rendering Infrastructure (DRI) is a framework for allowing direct access to graphics hardware under the X Window System in a safe, efficient way. The main use of DRI is to provide hardware acceleration for the Mesa implementation of OpenGL. DRI has also been adapted to provide OpenGL acceleration on a framebuffer console without a display server running.

DRI implementation is scattered through the X Server and its associated client libraries, Mesa 3D and the Direct Rendering Manager kernel subsystem. All of its source code is free software.

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. All that X clients do is communicate with the X Server to dispatch rendering commands. Those commands are hardware independent, meaning that the provides an 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 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 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 a third party process to do so, saving all the IPC overload. 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.


...
Wikipedia

...