Wednesday, August 8, 2007

Redirected direct rendering

Also known as AWESOME. Normally, when an application renders to an X window, the contents appear in the framebuffer immediately. The COMPOSITE extensions lets an application, typically the compositing manager, redirect that rendering to an offscreen pixmap. The compositing manager is then responsible for compositing the window contents into the framebuffer, for example by mapping it onto a cube or a wobbly window. All regular X rendering respect this redirection, since the rendering requests go to the X server, which can then target it to whichever pixmap it wants.

However, the default rendering mode for accelerated OpenGL, direct rendering, is a little different. With direct rendering, the application goes through an initial setup sequence with the X server, to acquire the address of the framebuffer and the shared back and depth buffers. After this step, the application renders by programming the GPU directly to render into those buffers. This, of course, is a feature - direct rendering acheives a siginificant performance boost over having to send every request to the X server. However, the direct rendering application isn't aware that a window might have been redirected and renders to the framebuffer regardless. This is typically not what you want:


DO NOT WANT

To me, this is one of the biggest problems in our rendering stack. I'm convinced that the composited desktop has to be a standard feature of the future Linux desktop: Whether or not you want spinning cubes and wobbly windows, there is no denying the benefits of flickerless redraws and ARGB visuals. Unfortunately, with a bug like this, we can't really enable it by default. Especially when interest in OpenGL backed toolkits (clutter and pigment) is starting to pick up.

What you want, is to let the OpenGL driver know when a window is redirected and make it target its rendering to the offscreen pixmap. Conceptually, it's easy enough and we've known how to do it for a while, but there's a lot of details to get right. One of the big pieces of the puzzle fell in place with Tungstens Graphics' DRM memory manager (TTM). Dave Airlie and I added TTM support to EXA and the intel DDX driver, and from there I was able to make the DRI driver render into the TTM buffers allocated by EXA. And given that the Pixmaps for the redirected windows are now backed by TTM buffer objects, we can add a zero-copy texture from pixmap implementation to the mix:


DELICIOUS

If you want to try it out, I have the code in the exa-ttm branch in my personal drm, xserver, mesa and xf86-video-intel repositories on freedesktop.org. It's not at all easy to set up and the current implementation is only a prototype. It will be a while before this stuff can get upstream; we need to discuss how we want the interfaces between DRI/DDX/DRM/EXA to look etc, but hopefully we can figure that out at XDS.

14 comments:

Unknown said...

Seeing that working makes me *so happy*. Well done everyone involed.

Anonymous said...

Christian, you're right that this is urgent to have. Beside it's the only drawback aiglx still has compared to xgl.

Anything for radeon/r300 yet someone can test? I'd love to get started with it.

Hanno ( http://www.hboeck.de )

Anonymous said...

Anything for radeon/r300 yet someone can test? I'd love to get started with it.

Same hope here. I hoped also that by this time someone implemented EXA render acceleration for ATI r300 cards, but it seems that nobody had the time to do it.

Apparently it should not be too hard a work; I'm not a real programmer and I know only the theory of how X works but I thought I could at least have a try at it this summer; unfortunately I didn't graduate last spring as I anticipated and I won't have time for other things at least until november.

Anonymous said...

Seeing this makes me cry when I think I only have a radeon/r200...

Snark

Anonymous said...

Kristian, you are some wicked hacker! I owe you and Dave not just one beer but a whole crate of something for that! I totally love you folks!

I got to get that onto my laptop now!

Best regards...

MacSlow

Wesley said...

Hmm.. Doesn't the Glucose-2 project try to fulfill the same goal?

moo said...

Seeing this makes me cry when I think I only have a radeon/r200...

I feel the same way :(

Kristian Høgsberg said...

Aw, don't cry. We're going to make it work for radeons too :)

Anonymous said...

Can't wait for this to land in debian/unstable ...

Unknown said...

Kristian is so beautiful to see that someone is working on this problem, especially cause it seems that a great part of linux community simply ignores it (lucky nvidia owners ? :D).
I've been looking for months to understand whether this is a video driver or xorg related "bug", and now im glad i have found your work!

Just a question: i know gnu/linux community has to deal with a huge amount of work under a lot of aspects, but WHY nobody speaks of these things ( i mean this opengl redirecton... or xv problems too)??

The blogosphere is full of "new version of compiz", "compiz default in next ubuntu/fedora/whatever.." and nobody writes something about your work... nobody writes about the patch mr raveman wrote for mplayer MONTHS ago that solves xv problems for ati/radeon users, nobody ports this patch for gstreamer/xine...

We, as a community, have to face all this issues to make compositing desktop the default in new linux distros. This is far more important than any compiz plugin or feature :)
Again, your work is great!

greetings for everybody from italy!

Andrea Zanchi

Anonymous said...

Anyone have any idea how far away this is on R100/R200 cards? Months? Years? What needs to be done for them to support it?

Also, if glxgears (for example) were to be run with LIBGL_ALWAYS_INDIRECT, would it be compositable right now?

coulix said...

hum now i see why i got flickering videos under compiz with player opengl mode, on moving windows.

To fix ASAP, many laptops use 945G

Anonymous said...

Hi, I would know where can I find more info about that, and how is the progress, how many months or years could it take?

Götz

Anonymous said...

Hi,

I have just read this article right now, and I would like to know how to give it a try under Ubuntu/Gutsy.

Since I see you said 'If you want to try it out, I have the code in the exa-ttm branch in my personal drm, xserver, mesa and xf86-video-intel repositories on freedesktop.org.'

Now the question is can I check it under Ubuntu/Gutsy ? And is there any little howto ?

A++