Diagram of upcoming X features

[suacy]

I've been trying to figure out what all these famous 3-letter acronyms (DRI2, GEM, KMS, Gallium3D, et al) mean and how they all fit together. I was thinking it would be helpful to make a diagram showing how they are related. I'd also like to note the expected release (version number and/or ETA) of each component, and the common user problems it would solve.

Anyways, here's what I can gather from various articles and wikis. Please be patient with my ignorance and correct any errors.


KMS puts all the modesetting into the kernel and makes the boot up and VT switching easy.
GEM or TTM: puts proper (?) video memory management in place for GPUs. This will be the source of a significant speed boost for OpenGL apps. Somehow along with DRI2 will fix flickering issues with compositing and video playback or opengl applications (redirected direct rendering RDR?). Is also required for Gallium3D (the replacement for Mesa), which gives us OpenGL3, and offscreen rendering required especially for Wine's D3D.

I hope that's close!

I really have no idea on dates on any of this stuff except I think that radeon is getting KMS and GEM support in 2.6.30. The timing of the rest of it is a mystery to me.

I'm going to start drawing a diagram and I'll integrate corrections as you guys help me out. Thanks!

[bridgman]

KMS uses GEM/TTM, so KMS can't go into the kernel until GEM/TTM is ready as well.

GEM/TTM (most drivers are using GEM API over TTM internals) move memory management into the kernel and make it mo' better. Having improved memory management is a pre-requisite for higher levels of GL support (things like FBOs & VBOs) which in turn will improve app performance.

DRI2 is better in a variety of ways, and also makes a common solution for RDR possible. RDR is what takes care of flickering 3D under a compositor.

Gallium3D is a replacement for the current HW driver portion of Mesa, not all of Mesa. Mesa can run over the old HW driver model or over Gallium3D. Gallium3D doesn't *have* to have DRI2 and GEM/TTM but that's how it is written today and nobody feels like changing that.

GL2 is already pretty much working over Gallium3D today, so having Gallium3D drivers for a GPU (along with the DRI2 and GEM/TTM pre-requisites) should give GL2 support for that GPU.

GL3 doesn't *require* Gallium3D any more than GL2 does, but unless a big problem is found with Gallium3D it seems likely that most GL2 and GL3 development will happen over Gallium3D.

IIRC the Intel drivers already implement most or all of GL2 using the older Mesa HW driver model, so GL2 without Gallium3D is possible -- it's just that any new implementations should probably be built over Gallium3D.

So... Gallium3D depends on DRI2 and GEM/TTM. RDR depends on DRI2 and (AFAIK) GEM/TTM. DRI2 depends on GEM/TTM. KMS depends on GEM/TTM.

GEM/TTM is really important

[suacy]

Thanks for the great reply! Forgive the following questions as I'm trying to get a handle on all of this. I will try to put all this information together into some easy to understand resource for us mere mortals.

First a question on the big picture.
Is this a good representation of how these all fit together?

API:    Mesa
        --Gallium3D--*
X:      Radeon driver
Kernel: GEM/TTM - DRI2

*Gallium3D sits in the middle and makes X drivers easier to write and Mesa simpler and easier to handle. Basically just another abstraction layer, right?

Second, about order and timing:
Now I'm assuming these things will fall into place from the bottom level on up.

According to his blog (http://airlied.livejournal.com/) Dave Airlie is going to have GEM and KMS working on radeon by Fedora 11. I think Fedora does a lot of cutting edge, out-of-mainline stuff, so I don't know if that means it will be merged in 2.6.30 or have to wait until 2.6.31. I guess that could depend on how fussy Linus gets about it - he had some colorful things to say when GEM was first merged...
I think you (bridgman) said that the end of year releases would be when the end user would start seeing this stuff and that makes sense.


I have no idea how difficult it is get Gallium3D going once all that is into place. Will that be a long time coming?

Thanks again for your patience.

[bridgman]

I think the end goal is to have both the X driver (2D, Xv) and Mesa driver (3D) sitting on top of Gallium3D. The kernel has KMS (modesetting) and GEM/TTM. DRI2 is kind of distributed around.

There will probably be at least one more video acceleration driver sitting on top of Gallium3D - VDPAU, VA-API, XvBA, XvMC or all of the above.

In terms of timing (and I'm just collecting comments from others here) it doesn't seem highly likely that GEM/TTM will make it into 2.6.30 for Radeon parts. Once GEM/TTM *is* in the kernel, though, everything else should fall in place behind it since the current Fedora work is available as a development environment for all the other pieces.

MostAwesomeDude is bravely doing the first Gallium3D-on-Radeon implementation and it seems to be going pretty well so far. Once that gets a bit further we'll know a lot more about what to expect. There is a lot of modified Mesa code ready to run on top of Gallium3D, which has a fair amount of testing already (on 915, SW rendering and Cell) but not that much on a modern discrete GPU (just Nouveau so far).

[suacy]

First attempt

Is this diagram accurate?
http://img25.imageshack.us/img25/1629/xstackdiagram.png

I think if I showed it to my wife she would say that it's ugly.

[nanonyme]

There will probably be at least one more video acceleration driver sitting on top of Gallium3D - VDPAU, VA-API, XvBA, XvMC or all of the above.

I'd personally put my money on VDPAU and XvMC considering iirc I was told there's at least some level of XvMC support in Gallium via a state tracker and it's possible some student (group) might get interested in using that idea of making a VDPAU state tracker as a Google Summer of Code project as given on X.Org's wiki.

[bridgman]

I think if I showed it to my wife she would say that it's ugly.

It's not as ugly as mine :



DRI2 is kind of hard to draw because it involves all of the components. Officially it's an X extension (implemented in the X server and driver, used by the other components) but AFAIK the actual implementation details are more complicated. Think of it as being like the Force; it surrounds and penetrates all the components, and binds the entire driver stack together.

[suacy]

Second Take

Here's my second attempt, am I getting closer to something accurate?


I figure a green splat is a good representation of something as nebulous as DRI2 or the force.

[bridgman]

Yeah, the green splat is good

Maybe replace "X" on the left with "Userland" or something, since the upper boxes include X, Mesa and hypothetical future video drivers.

[suacy]

Take three

Yeah, the green splat is good

Maybe replace "X" on the left with "Userland" or something, since the upper boxes include X, Mesa and hypothetical future video drivers.

Ok, here's my third try. I gave it a clandestine title.
http://img8.imageshack.us/img8/1629/xstackdiagram.png

Some clarifying questions:
GEM brings the potential for greater 3D performance but the rest of the driver stack will have to be modified to take advantage of that. So improving 3D speed will be a process and likely one of the last things to fall into place. Does that sound right?

Is the best way for amateurs to help the progress of all this new stuff would be to try out Fedora 11 on a livecd or second partition, test and report bugs so airlied can get it in mainline and rock-solid quickly? Maybe we can channel all the mob rage around here into a flurry of testing.