Now that DRI2 was removed from the Xorg7.4 release, there is a lot of whining around why it was not released as is so that we have at least something working.

The first thing one has to understand, is that the current Xserver rendering architecture is horribly outdated; there was no work done to keep it up to date during the Xfree days and even when Xorg started, the primary goal was to uncouple the different parts to allow asynchronous releases.

So currently there is not one field where construction done but several. These are 2D Acceleration, Memory Management, 3D Acceleration and 2D Modesetting. And they are all being worked on at the same time to speed things up.

But the problem is that more or less all of these depend on proper Memory Management, which is also the hardest thing to get right.

Now lets look at how Xorg works today; every Xorg driver implements its own way of memory management and provides the DRI1 functionality when it comes to 3D. Furthermore it is responsible for modesetting, which is quite suboptimal, since some perliminary modesetting is already done in kernel, so it can output messages during bootup. The Xorg driver resets the hardware again when it is loaded.

Kernel Based Modesetting

In order to solve this duplication the modesetting code is about to be moved into the kernel, so the hardware can be setup once and for all. But since modesetting involves memory management which is not done properly yet too.

Memory Manager

The idea here is to share as much code between the drivers as possible and to provide a common API for the userspace. (the new memory manager will live inside the kernel) So a memory manager consits of an API, a shared part and a hardware specific part. The first proposal came in form of TTM from Tungsten Graphics. TTM had a quite complicated API which many developer also thought of as not being able to suit new graphics cards. The shared code part was already written and some drivers like noveau started to use it. But then Intel introduced GEM, which had a simpler API and suited modern graphics cards better. Although GEM currently contains only Intel specific code, developers started to pick it up. There is a branch of the ATI driver which provides a similar API to GEM. The bottom line here is that there is no stable API yet, but it will likely be more similiar to GEM then to TTM.

3D Acceleration

DRI2 is a restructuring of the direct rendering infrastructure which was needed in order to redirect direct rendering. Currently when an application wants to draw an OpenGL window, it does this directly to the framebuffer. With DRI2 it will be redirected to some offscreen memory so the Compositing Manager can do fancy things with the output. This obviously depends on a stable memory management API and thus had to be changed when GEM was introduced, because DRI2 was designed only after TTM in the first place.

2D Acceleration

in the 2D acceleration area EXA was set as the way to go. But then Intel again introduced UXA – this time it is nothing different. It provides the same API as EXA, but takes advantage of the new GEM Memory manager. It was just given a new name because much of the old code was ripped out. This work will be most likely be used by the other drivers too.

Hope this helps too clear things up a bit. As you can see, changing the Memory Manager means changing all the other stuff too. Therfore it is important to get it right in the first place.

  • A very neat article. You seem informed, able to write, and an Ubuntu user. Have you considered adding yourself to the Ubuntu Weblogs project, so that more people can find discover this information?

    Alternatively, if you participate in Ubuntu, you could apply for membership and place yourself on Planet Ubuntu. Membership isn’t limited to MOTU or core-devel. Participation could be in the form of marketing, support, etc.

  • Thanks for clearing up all the new vocabulary. TTM, GEM and UXA are new words in town, nice to see that they actually mean something.


  • Dave Lentz

    Thank you for enlightening those of us on the “outside”. It appears we are going through growing pains, but the wait will be worth it. If we’re going to build an open-source rendering infrastructure, then let’s take the time to do it right. There was a lot of FUD about the Intel team writing GEM, but it appears they were doing this while the AMD/ATI crew was catching up on the rapid release of new architecture generations. There was also a lot of griping about too much code forking, but this is not the case. The code is being updated.

  • Locitus of Borg

    When I understand things correct, we need all this things to be hooked together to work as intended, since all this stuff depends on each other. So, when can we suppose to see all this fancy new X stuff ready to be usable out of the box (i.e. Debian Sid, Ubuntu will probably deliver a bit later)?

  • Locitus of Borg

    edit: Sorry, I forgot. I mean with Intel hardware (X4500 graphics in a laptop).

  • Intel will give you no advantage here, since the infrastructure has to be in place first. And in order to change the infrastructure you have to update all drivers at once. I suppose we will see this with Mesa 7.3/ 7.4 which will at least take another 6 Months, since they are working on Gallium 3D for that.

  • Hi
    It’s better to put reference link

  • Simple yet informative. Keep them coming !

  • Thanks, excellent article. 🙂

  • Pingback: Una versión que promete « Noticias del web()

  • Tomek

    So, if modesetting will be done “once and for all”, then I will not be able to change screen resolution afterwards?

  • VladNistor

    There seems to be an incompatibility between High Memory Support (64GB) in the kernel and UXA that people are not talking about…

  • Pingback: El Blog de Marcelo! » Ubuntu 9.10 – Alpha 3()

  • Pingback: Alphabet Soup, Anybody? « Doesn't Not Compute()