Monday, March 31, 2008

DRI2 Direct Rendering

I just committed the last bit of DRI2 work for now to the xserver, mesa and xf86-video-intel repos. This work enables direct rendering to redirected windows:

So what's going on in this screenshot? Totem is playing the trailer from the new blender open movie project, Big Buck Bunny. While this looks to be a great follow-up to their previous movie, Elephants Dream, the interesting thing here is that it's playing using textured video under the batchbuffer branch of the intel driver, backed by the kernel video memory manager (TTM). Traditionally the X video extension (Xv) has been implemented by an overlay mechanism that lets the driver configure the hardware to scan out the pixels in the video area from a different buffer, doing color conversion and scaling on the fly. In other words, as the hardware scans through video memory to send the pixels to the monitor, it flips to read from a different buffer as it enters the window that shows the video. It's a fairly simple mechanism and it's cheap to implement in hardware, but it doesn't work for redirected windows. Textured video uses the 3D hardware to do scaling and color conversion, and since that is just regular 3D rendering, it can be redirected just fine, as seen in the screenshot. The textured video work was done by Eric Anholt and it's been in the intel driver for a while now - what's new here is that it runs under DRI2.

Also in this screenshot we have good old glxgears and MacSlows cool RGBA GLX demo. Both of these GLX applications are doing direct rendering to redirected windows. The main motivation behind the DRI2 work was to get redirected, accelerated rendering working. The first step got AIGLX (indirect rendering) working, and with this last bit, direct rendering now also works. The RGBA demo further demonstrates that we can now create a window with an RGBA visual and render to it from OpenGL and the compositing manager (in this case compiz) will composite it and blend it correctly with the rest of the desktop contents.

With Xv and Open GL finally working under composite, the intel driver is in pretty good shape. We're getting closer to a point where we can ship with a compositing manager enabled by default. In Fedora 9, we're shipping all this as a technology preview kind-of thing. DRI2 still has a number of crashers that I'm chasing and it's very new code. There will be an xorg.conf option or similar that will enable the batchbuffer branch of the intel driver and the DRI2 infrastructure. Hopefully by the time Fedora 10 comes out, it will be on by default.

23 comments:

Anonymous said...

How easy is it going to be to port this kind of stuff to other drivers, notably Radeon (which is what I have)? It would be great to be able to run Compiz and have it perform reasonably and not crash.

Anonymous said...

Sounds great, but could somebody explain a little what's new on the screenshot totem wise? As I understood it wasn't possible to do XV in an environment with direct or indirect rendering, but in modern systems like Ubuntu Gutsy it seems to work fine nowadays.

Just curious, I'dlike to understand this coolness a bit better :)

Anonymous said...

So the next thing you need to do is getting anti-aliasing to work in compiz. Without it, the screenshot looks horrible.

Anonymous said...

Wow, many thanks for your work! This is absolutely wonderful. Things are really happening on the freedesktop front in a way I couldn't have imagined a few years back. Looking forward to when things are well integrated in distributions.

Anonymous said...

Dear krh,
You are the bestest.

xoxo,
Daniel

morphado said...

cool, will be available to G945 !

Anonymous said...

Seconding the question about Radeon. Both here and on the mailing list you mention Intel specifically. How much of this is driver-specific?

Dan Nicholson said...

You...freaking...rock.

TJ said...

Cool! I'm wondering about HD video playback performance, though. Xv handles outputting 1920x1080 video on G965 just fine, but I haven't seen smooth HD textured vide playback on Intel hardware yet. But then again, I should check again with xserver 1.5/intel-batchbuffer/mesa git...

Anonymous said...

Wow, thank you!

I anxiously look forward to the day I can enable composited environments on my machines without having to worry about odd side effects. (Unfortunately, I have to wait for multi-session DRM, as we use multi-user features a lot.) I wish I were graphics-saavy enough to help out.

OasisGames said...

Finally, the greatest new addition of 2008 is here! What kind of crashes are we talking about? Will they potential hinder basic use of my laptop? I'm obligated to get this running my machine as soon as possible, being a C-F dev, so anything small isn't a problem to me (I deal with them already with git compiz, which tends to just randomly die and "Crash Handler" doesn't even catch it)

Now all we need is input redirection. Too bad that was pushed back an entire year...

OasisGames said...
This comment has been removed by the author.
OasisGames said...

Well, that was an eventful compilation. Everything worked after many painful minutes of... getting things to work.

DRI2 is amazing!

Deleted/reposted to say this:
KRH - you don't use texture filtering in Compiz? How utterly ugly. It looks so much better with smoothing.

Maurizio Monge said...

I thought that i was aware of all the new stuff about X/Mesa, but i did not know about DRI2, and i'm truly impressed.
Just out of curiosity, will this fix (when possible) the problem that an application using dri may easily completely lock the xserver (some time ago i had the bad idea of running "gdb glxgears" from within X to see what was going on in the dri driver, something that is possible with proprietary nvidia drivers. You can well believe that i had to push the reset button of my machine :) ). I read in the spec about back buffers, clipping handled by the drm and "atomicity", i hope that this will help.

Anonymous said...

I have one question that I find very important:
Will the old Xv overlay be still available once this branch is in the main tree?
What I am worried about is the older hardware, as for example we still have lots of boxes with intel 810 to 855gm to 915 which is pretty decent in regulx X + xcompmgr + XV plus some small GL applications (for example I can use blender in 855GM okay) but after trying compiz with the video plugin and patched mplayer I found out that 855 card for example just CAN'T play full screen video (for example 420p video scaled to 1680x1050) while Xv does it pretty fine and no CPU overloads.
What I mean is that your work is important but linux was well known for its ability to power up older hardware, will your work remove that from one of the most used driver on the low end computers?
That will be just awful! You see if Xv is removed and all is done as textured video this will mean ppl will have to trow away their laptops, or stick to an older distribution and no updates (not all developing software is related to this feature).
So can you please answer my question, will this work once merged with the main branch strip the power from the older hardware (pre-hardware accel. textures and so on on the intel IGP).
Thanks

OasisGames said...

It's not textured video, it's redirected XV. Your problems were the entire point in making XV redirected - because X11/xshm is slow and doesn't work well.

At least I'm pretty sure that's what's going on...

Anonymous said...

"Textured video uses the 3D hardware to do scaling and color conversion, and since that is just regular 3D rendering"....

I think you are wrong:) It is exactly playing video using the 3D pipe in the video chip, which is virtually missing in the older hardware....

OasisGames said...

Am I still the only one with a video of this godsend? Seriously...

Anonymous said...

Kristian, this is so cool I could cry :) Totally wicked stuff!!!

Anonymous said...

From reading around at several places, it seems that DRI2, and consequently, Gallium3D, will require fragment programs. As far as I know, this means an OpenGL 2.0 requirement, which means R300 and up. And so far, that seems to be where development is headed.
R200 cards have ATI_fragment_shader, but, once again, as far as I know, no one has bothered to actually fully support it, (except WINE it seems...which is useless without a supporting driver).
Will R200 users be SOL, even though the hardware is capable?

Anonymous said...

What do i have to do to get this working on ubuntu hardy with intel X3000 graphics?

What do i need to compile and install? Only the intel driver? Do I have to configure anything elsa to enable direct rendering to redirected windows in compiz fusion?

OasisGames said...

@josch:
You'll need to build the entire X server stack. Mesa, X server, DRM/DRI, intel-batchbuffer, etc.

Cecily said...

You've been tagged! I know it's your geek blog but you should take the questionnaire!