Linux graphics Stack

1. Display and mode setting: DRM. DRM defines connector/encoder/CRTC to support display (including multi-Monitor). And kms makes mode setting happens in kernel space.

2. 2d acceleration: X Server exa/uxa extension. vendor shocould write a X Server Driver which implements exa or uxa (shocould be upstreamed ). uxa is an enhancement Design of exa, proposed by Intel, so gem is used in uxa. DRM has no direct 2D acceleration interface definitions (E. g: memory copy/move, bmove, color space conversion ...), this is defined in exa/uxa extensions. but vendor's X Server Driver will use DRM functions, mostly is buffer manipulations.

3. 3D acceleration: via Mesa. Mesa has 2 parts:

Libgl. So -- the implementation of OpenGL spec, the default OpenGL implementation library in Linux. This libgl. So translates OpenGL callings to Mesa-specified instructions.

DRI driver -- the driver accepts the Mesa-specified instructions generated by libgl. So and call DRM functions to get them accelerated in GPU. shocould be upstreamed.

 

DRM: Has userspace libdrm & kernel space DRM driver.

Libdrm: Implemented DRM APIs. vendor can hook it's implementations as well as add more APIs which used by exa/uxa Driver (2D) or dri Driver (3D ). that's why the build result of libdrm normally has 2 Libraries (E. g: libdrm. so & libdrm_intel.so ). vendor Codes of libdrm shocould be upstreamed.

Kernel drm driver: works under kernel DRM framework, shocould be upstreamed. Cause vendor can add APIs in libdrm, so kernel DRM driver can handle vendor specified IOCTLs.

Glx: X Server Extension of OpenGL. X server has DRI/dri2 extensions as well.

They're working with libgl. So in Mesa. By these extensions, mesa can do:

1. direct rendering: libgl. so in Mesa try to figure out whether dri driver is ready in Mesa. if so, Glx returns some Infos (such as window size, position ...) or create off-screen buffers (via DRI/dri2 x extension) for Mesa. the rendering is handled in Mesa's dri driver -- no relations with X server.

2. indirect rendering: libgl. so in Mesa can't find out Mesa's dri driver. so it queries whether dri is available in X server. if so, it pass the Mesa-specified instructions which generated by libgl. so to X server. and Glx/DRI/dri2 extensions of X server handles the rest things. normally it's software rendering which implemented by Mesa as well. aiglx (accelerated indirect Glx) seems has some solutions to accelerate this.

 

So Mesa handles a lot of works in Linux 3D graphics stack. And it has lots of relations with X server as well (Glx and DRI x extensions ).

 

An important reason that why we involve so many components is, decouple the dependencies of all of these guys. according to this design, DRM is not related with X server so it works with other programs as well (E. g: Wayland ). mesa is the same.