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.