DRI2 Sync + Swap Extensions Near Reality

[phoronix]

Phoronix: DRI2 Sync + Swap Extensions Near Reality

When running a modern Linux graphics driver stack in a composited environment there is a lot less tearing -- particularly with regard to video playback, but OpenGL applications too -- now than there was in the past, but there is still room for improvement. One of the ways to improve this is by properly controlling the display of buffers with how often the swaps occur and to sync them with the monitor's refresh rate or the rate at which the compositor is running...

http://www.phoronix.com/vr.php?view=NzY1Ng

[RealNC]

When running a modern Linux graphics driver stack in a composited environment there is a lot less tearing [...] now than there was in the past

Orly? Xgl, which is old was running flawlessly without tearing :D

[ripps818]

Cool, could this fix the performance issues with textured video playback with the kms ati drivers?

[Louise]

Is tearing and flicker the same?

[BlackStar]

Is tearing and flicker the same?

No.

Simply put, tearing occurs when the back-to-front buffer swap happens out of sync with the monitor's refresh rate. This means that the scanout starts before the front buffer is completely refreshed, which results in the monitor displaying both old and new data at the same time. The "tear" is a (usually) horizontal line at the point where the split between old and new data lies. VSync takes care of this artifact - unfortunately, vsync is not easy to implement under AIGLX using the current infrastructure, hence this work.

Flicker is the artifact that occurs when using direct rendering (DRI1) on a composited environment. The compositor normally redirects all rendering to an off-screen area to perform composition, before spitting the result back to screen. However, DRI1 is oblivious to this procedure and renders directly on screen, overwriting the compositor's output (flicker!) DRI2 solves this issue.

[panda84]

Orly? Xgl, which is old was running flawlessly without tearing :D

Yes, because, AFAIK (I'm no expert at all), Xgl was a whole reimplementation of X protocol over OpenGL. A drawback was that you weren't able to run any OpenGL thing inside Xgl itself, which is not funny in any way.

BTW, is antialiasing possible with ATI open drivers? I'd like to see smooth edges on my cube! :D

[bugmenot]

Thanks Jesse! :)

[oneman]

This kind of thing is what I've been waiting for in Linux Desktop graphics for a decade. Go Go Go!!

[Louise]

No.

Simply put, tearing occurs when the back-to-front buffer swap happens out of sync with the monitor's refresh rate. This means that the scanout starts before the front buffer is completely refreshed, which results in the monitor displaying both old and new data at the same time. The "tear" is a (usually) horizontal line at the point where the split between old and new data lies. VSync takes care of this artifact - unfortunately, vsync is not easy to implement under AIGLX using the current infrastructure, hence this work.

Flicker is the artifact that occurs when using direct rendering (DRI1) on a composited environment. The compositor normally redirects all rendering to an off-screen area to perform composition, before spitting the result back to screen. However, DRI1 is oblivious to this procedure and renders directly on screen, overwriting the compositor's output (flicker!) DRI2 solves this issue.

In that case, I have a lot of tearing :D

Where in the OSS ATi graphics driver stack does VSync belong? DRI2?

[DanL]

Where in the OSS ATi graphics driver stack does VSync belong? DRI2?

I think vsync might need support for interrupts, which the open-source ATI drivers lack (because of lack of documentation).

[bridgman]

Actually until a week or so ago it was lack of being able to make interrupts work on 6xx/7xx even with access to all the internal docs :D

Alex has interrupts running now and we're going through the usual IP review of the info that was required to make 'em work. We're talking about 6xx/7xx only here, of course -- interrupts have been working on earlier GPUs for a while.

[Louise]

Actually until a week or so ago it was lack of being able to make interrupts work on 6xx/7xx even with access to all the internal docs :D

Alex has interrupts running now and we're going through the usual IP review of the info that was required to make 'em work. We're talking about 6xx/7xx only here, of course -- interrupts have been working on earlier GPUs for a while.

Good timing :)

Where in the dependency tree in the Feature Matrix does VSync belong?

Will it be hard to implement?

[chrisr]

The most infuriating "feature" of Fedora 11 is that its Xorg implementation became incompatible with -git almost immediately. (The -git xorg driver couldn't compile against Fedora's libdrm.) Will this new vsync work mean that the same will now happen for Fedora 12?

[bridgman]

Fedora has been running months *ahead* of upstream for the last couple of releases. I think that should slow down after F12.

[chrisr]

Fedora has been running months *ahead* of upstream for the last couple of releases. I think that should slow down after F12.

Being "ahead" of upstream doesn't matter, because the packages aren't compatible with each other. I've had this problem with xorg-drv-ati almost since Fedora 11 was released:

In file included from radeon_textured_video.c:171:
radeon_textured_videofuncs.c: In function ‘RADEONDisplayTexturedVideoCP’:
radeon_textured_videofuncs.c:119: error: too few arguments to function ‘radeon_cs_space_check’
radeon_textured_videofuncs.c: In function ‘R200DisplayTexturedVideoCP’:
radeon_textured_videofuncs.c:510: error: too few arguments to function ‘radeon_cs_space_check’
radeon_textured_videofuncs.c: In function ‘R300DisplayTexturedVideoCP’:
radeon_textured_videofuncs.c:1054: error: too few arguments to function ‘radeon_cs_space_check’
radeon_textured_videofuncs.c: In function ‘R500DisplayTexturedVideoCP’:
radeon_textured_videofuncs.c:2507: error: too few arguments to function ‘radeon_cs_space_check’
make[2]: *** [radeon_textured_video.lo] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

And I'm desperate to be rid of it. But that's going to take a userspace compatible with libdrm > 2.4.11. As will using KMS with my 2.6.31.5 kernel.

Roll on, Fedora 12!

[bridgman]

Yeah, that's the problem with being seriously ahead of upstream. If you're further ahead than just "waiting for the merge window" there's usually a reason the code isn't in the kernel yet. F10 and F11 had a lot of "proof of concept" code, which needed non-trivial changes before it went into the kernel. That said, every distro has a purpose, and Fedora's purpose at the time was proving out new technology.

I imagine early releases of F12 would treat you better than trying to update F11 with upstream bits.

[Raine]

Will this benefit also who uses NVidia proprietary drivers?

[elanthis]

Will this benefit also who uses NVidia proprietary drivers?

Nvidia does not use dri or anything else in the Linux graphics stack besides the core protocol bits of xorg.