Editing Direct Rendering Infrastructure (section)

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