简介

Who develop it

• Started by Jens Owen and Kevin E. Martin of Precision Insight.
• First made widely available as part of XFree86 4.0 and is now part of the X.Org Server.
• Currently maintained by Tungsten  and others in the free software community.

What is it

An interface and a free software implementation used in the X Window System to securely allow user applications to access the video hardware without requiring data to be passed (slowly) through the X server.

Who use it

Its primary application is to provide hardware acceleration of the Mesa implementation of . Mesa 的硬件加速就是通过 DRI 来实现的。

It has also been adapted to provide  acceleration on a framebuffer console without an X Server running.

详细的综述

Architecture

来自参考资料4

libGL:

1. Present a  compatible API to the client application;
2. Implement the GLX API (the glue between  and X);
3. Find and load the appropriate 3D driver;
4. Dispatch the received  API calls to the 3D driver, or fallback to the X server if no 3D driver was found;

3D driver:

1. Implement the  API;
2. Transform the received vertex and texture data into the hardware native format;
3. Keep a backup of the graphics hardware state which is relevant to its drawing context;
4. If DMA is supported by the hardware, fill in DMA buffers with the vertex and texture data and signal the DRM module to dispatch it to the hardware;
5. Provide software fallbacks for all operations not supported in hardware.

DRI extension:

1. Context/window setup;

2D Driver:

1. Detect and initialize hardware;
2. Reserve on-board memory for 3D operations;
3. Synchronize 2D operations with 3D ones;
4. Identify which 3D driver and DRM module to load;
5. Communicate the current cliprect list;
6. Authorize client access to the DRM module;

DRM core module

1. Thin OS kernel abstraction layer for portability

DRM module:

1. Graphical hardware lock;
2. Allocate a pool of DMA buffers (in the AGP aperture if possible);
3. Memory map the DMA buffers to client virtual address space;
4. Dispatch the DMA buffers written by the clients;

SAREA:

1. Store dirty hardware specific state;
2. Store cliprects.

Details:

Data Flow Diagram

DRI Data Flow Diagram

This overview diagram shows the different paths which the data takes from the program to the graphics hardware.

Starting at the left from the top.

Direct rendering program (3D):

Direct rendering (3D data) -> 3D data ->  Hardware

Direct rendering program (2D):

X Protocol Encode -> Protocol Decode -> DIX -> XAA -> DDX Driver ->  Hardware

3D and 2D commands share the same transport / protocol arrow / stream between the indirect rendering program (client) and the X Server. It's not until the protocol is decoded in the X Server that they diverge.

Indirect rendering program (2D):

X Protocol Encode -> Protocol Decode -> DIX -> XAA -> DDX Driver ->  Hardware

Indirect rendering program (3D):

X Protocol Decode -> GLX -> Mesa (including SW rasterizer) -> DDX Driver ->  Hardware

Control Flow Diagram

DRI Control Flow Diagram

3D and 2D commands share the same transport / protocol arrow / stream between the indirect rendering program (client) and the X Server. It's not until the protocol is decoded in the X Server that they diverge.

Indirect rendering program (3D):

X Protocol Decode -> GLX -> Mesa (including SW rasterizer) -> DDX Driver ->  Hardware

Indirect rendering program (2D):

X Protocol Encode -> Protocol Decode -> DIX -> XAA -> DDX Driver ->  Hardware

2D only program (2D):

X Protocol Encode -> Protocol Decode -> DIX -> XAA -> DDX Driver ->  Hardware

RM and 2D commands share the same transport / protocol arrow / stream between the indirect rendering program (client) and the X Server. It's not until the protocol is decoded in the X Server that they diverge.

Direct rendering program (2D):

X Protocol Encode -> Protocol Decode -> DIX -> XAA -> DDX Driver ->  Hardware

Direct rendering program (RM):

X Protocol Encode -> Protocol Decode -> DRI Module (-> DDX Driver) -> DRM Lib =>> SAREA & Kernel

Direct rendering program (3D):

Direct rendering (3D data) -> 3D data ->  Hardware

Resource management:

SAREA & Kernel

3DDRP Internals:

Origins of 3D , RM , 2D & RM (x transport)

DRI Low-Level Design Documents

DRI  Support

The DRI  support consists of several pieces:

• DRM is a combination of at least two kernel modules, one of core DRM code and others providing APIs to userland to access different classes of video hardware.
• The userland driver module contains an  driver that typically prepares buffers of commands to be sent to the hardware by the DRM and interacts with the windowing system for synchronization of access to the hardware.
• Additional code provides access to the interface provided by the driver module. In X this is the libdri.so support module and a DRI-enabled DDX (2D driver). In the framebuffer implementation this is MiniGLX, which initializes the DRM and provides some X APIs to the userland driver despite the lack of an X Server.

新进展

• Work on DRI2 started at the 2007 X Developers' Summit. The new rendering infrastructure improves several shortcomings of the old design, including removing internal locks and adding proper support for offscreen rendering, so that compositing and XVideo/ applications are properly managed.

SeeAlso