GEM is the new memory manager replacing TTM. It is said to enable better memory managment which to the end user means better acceleration - when drivers using it are well developed.
KMS enables changing VT's (i.e. to X and out of X) without all that blinking, flickering and whatever - so it'll look better and the name Kernel Mode Setting suggests taking the code out of Xorg and into the kernel.
DRI2 is the new rendering infastructure. When drivers make good use of it, thing should be better, faster, more reliable than with DRI. I guess ;]
1. GEM/TTM give us a general-purpose memory manager in the kernel, which allows X and Mesa to share memory objects properly for the first time. Sharing memory objects between X and Mesa helps a lot with things like pixmap/texture conversion (you don't need to copy any more) and is a pre-requisite for KMS, DRI2 and some higher-level GL functions.
TTM had barely been implemented before being replaced with GEM, so the "big deal" here is not so much GEM replacing TTM as having a decent memory manager in the kernel module (drm) where we didn't have one before.
2. KMS allows all of the different graphics drivers to be replaced with a single driver in the kernel, so rather than passing control from one driver to another when doing a VT switch or suspend/resume one driver can maintain control all the time. This will hopefully eliminate a class of problems and make VT switch & suspend/resume more reliable.
3. DRI2 is being used as a foundation for Redirected Direct Rendering in the open drivers (the ability to redirect the output from a direct-rendering application through a compositor) which will allow flicker-free 3D under Compiz, among other things.
Gallium3D and dri2 are entirely separate layers, and aren't necessarily dependent on each other. However, the Gallium3D development going on right now is being done to target dri2, because dri2 will be rolled out before Gallium development is going full swing, therefore writing a dri (1) driver would be pretty pointless.
Actually, Gallium3D doesn't need X, or anything else in particular (you could even in theory write Windows drivers using Gallium3D, I believe). Mesa is designed to be as modular as possible.
Yep, Gallium3D is sorta one level higher in the driver stack. Easiest way to think about the direct rendering stack is something like :
Mesa GL interface (no change)
Mesa HW driver interface (replace with / rebuild over Gallium3D)
DRI/DRM (update to use DRI2 protocols instead of DRI1)
Applications call Mesa, which was initially a software GL renderer. It also has an internal driver interface which allows certain functions to be hardware accelerated. That HW driver interface is unique to Mesa. Mesa calls drm to talk to the hardware, and drm uses the DRI protocols to find out important things like "where is the window I am supposed to draw to" and "has the window moved since the last time I drew something ?".
Gallium3D is a low-level driver interface which is designed around modern shader-based GPUs and is intended to support a number of different high level APIs. Mesa is being modified to use Gallium3D rather than the built-in HW driver interface.
The DRI code provides a mechanism direct rendering calls through Mesa to stay in sync with window information managed by the X server and with 2d/video rendering done through the X server (aka indirect rendering). DRI2 is a new and simplified version of the DRI protocols and code.
@techmage89 & bridgman: thanks for explanation. the x stack is really complicated
@KDesK: glucose is something like exa and xaa. as far as i know, glucose could be used by gallium3d as high level api (as brigdman calls in another thread related to intel-things..). or am i missunderstanding something?! (probably )
Thanks to everyone for the explanations. Right now I'm mostly concerned with clean, judder and tear free video playback that doesn't get messed up when using more than one monitor, which depending on the hardware and driver combination seems to be a hit or miss right now. I suppose we will see improvements on that front?
Glucose is a 2D acceleration API written over the OpenGL stack. As Regenwald said, these days a Glucose-like API is more likely to be written over Gallium3D (the low level interface) than OpenGL, and I expect the standard EXA and Xv APIs would be used, so what we are really talking about is EXA and Xv being built over Gallium3D rather than directly programming the hardware.
Thomas and others have been working on a "generix X driver" which will use KMS for modesetting and Gallium3D for 2D and video acceleration -- that's probably a pretty good hint of the eventual future. I forget what the project is called but the source is in freedesktop.org.