Linux “Graphics Driver Stack” Explained

We get this question a lot about radeonhd: “When is 3D going to be supported?”

The short answer: never; 3D acceleration is the domain of Mesa.

But, of course, it’s not as simple as that.  For the long answer, read on…

More than Meets the Eye

Your Linux “video card driver” is not a single blob of code.  As with any sufficiently large piece of software, things need to be broken up into discrete components for both technical and maintainability reasons.  And, there is no doubt a complete graphics stack is large: the AMD Catalyst driver is a 93MB download.  That’s over one hundred Mega bytes of executable code and supporting data.  In that humongous pile of bytes are roughly half a dozen different components working together to deliver your polygonal needs, without counting the configuration tools.  This, unfortunately, is not common knowledge.

In the open source world, our drivers are much more svelte, partly because less features are supported, and also because application-specific optimizations are omitted.  Unlike the proprietary drivers, however, the boundaries of separation are clearly visible.  In respect to “driver” code that is specific to a particular hardware, there are, more or less, three separate components involved:

• X display driver
• Mesa DRI driver
• Kernel DRM driver

Indeed, in true UNIX fashion, all of these are actually worked on as completely separate projects, albeit with significant overlap in the personnels involved. (Proprietary drivers from AMD and nVidia provide equivalents to all three in a single package.)

DDX: People’s Favourite Barking Tree

When the words “Linux video card driver” are invoked, the DDX is what people typically think of.  And, for good reason: historically, when configuring X11, the DDX was one of the few things that had to be configured by the user, and could be selected. This is your radeonhd, radeon, nv, and intel.

The main function of these drivers is to provide mode setting: that is, selecting the screen resolution, colour depth, turning outputs on and off, etc. The X server uses the DDX to perform basic, essential hardware manipulation so that you can have a graphical display at all.  Each DDX is hardware-specific: indeed, it stands for Device Dependent X (but this trivia is not very important.)

That’s not all.

A DDX also provides hooks that allow the X server to offload certain drawing operations to the GPU so that they can be accelerated.  XAA, EXA, and UXA all fall under the DDX’s domain, in addition to Xv.  The former group is responsible for things like moving windows around your desktop, scrolling a website in your favourite browser, and compositing desktop effects.  The latter handles video rendering.

To summarize, everything 2D is the domain of the DDX.  And, in simple terms, it is its only domain.  If you are looking for 3D acceleration, this is not the tree to be barking up at.

Mesa DRI Driver: The Invisible Hero

OpenGL is the method with which applications achieve 3D rendering under Linux.  Unfortunately, but for good reasons, it is not possible to go from an OpenGL function call to manipulating hardware states in a single step.  Multiple translations must be done under the hood to convert those calls into something that the GPU can understand.

Mesa is largely divided into two parts: an OpenGL compatible library stack that applications can call into, and DRI drivers that translate Mesa-internal instructions into forms that the video hardware can understand and execute.

After a call is made to the Mesa library and it has been translated into a GPU-specific language, the resulting operations need to be sent to the hardware for execution.  Mesa, however, cannot do this without help as it lives in user space:  only kernel space code is allowed to touch hardware directly.  Note that DDX is one of very few exceptions to this rule: it is technically user space code but allowed direct hardware access, for better or worse.

Unfortunately, sending these instructions through the DDX, and hence X, is not fast enough.  This point finally brings us to…

DRM: Bridge to the Hardware

The final piece of the driver stack is the Direct Rendering Manager.  Oversimplified, it exposes certain features of the hardware with an abstraction layer to user space such that applications like Mesa can make use of a GPU more efficiently.

It is also the job of the DRM layer to provide measures that ensure multiple applications that require working closely with the hardware to not step on each other’s toes.

DRM drivers are Linux kernel modules, which are accessed by user space through libdrm.

All Together Now

So, say you have a shiny new RadeonHD 4870.  What driver features would it take to have it “working under Linux”?

First of all, you need a DDX that can properly mode set the GPU. radeonhd and radeon have both been capable of this for some time.

For fast 2D, again, support needs to be added to the appropriate DDX.  Mostly done, as above.

In terms of accelerated 3D, support from both Mesa and the kernel are required.  As of this writing, work on both are progressing nicely but remain in experimental states.  And, in this particular case, changes were required to libdrm as well.

It should now be clear that, for newer video hardware, there is rarely a trivial answer to the question “Does it work in Linux?”  In fact, it can be downright confusing.

Now, Lets Make It Complicated

Video hardware rarely change completely from generation to generation.  This means that the same code is often times used to operate GPUs from multiple generations.  Understanding which version of which component you need can occasionally become a messy affair.

To draw an example from the Radeon world, R3xx (Radeon 9xxx) and R5xx (Radeon X1xxx) GPUs share a similar 3D engine, but the mode setting engines are drastically different.  Therefore, while you can use the same Mesa DRI driver on both (r300_dri.so), radeonhd will not work on the former.  As for DRM, radeon (note that there is a kernel module and a DDX bearing this name) takes care of everything. (There are, of course, oddities from those generations that do not fit in to this generalization.)

Furthermore, there is currently a push in Linux to move video mode setting into the kernel (Intel is already there).  Kernel Mode Setting, more commonly referred to as KMS, brings the user- and kernel-space separation back to X, relieving the responsibility of hardware manipulation from the DDXes and putting it solely in the DRM drivers.  The details of this topic will—perhaps—be explored another time.

So, Now You Know

Armed with this knowledge, your task is to now educate your fellow Linux users regarding the mistaken concept of “The Linux Graphics Driver”.  Your efforts will, hopefully, help reduce the need for developers to repeat this explanation, again and again.