Mesa 7.4 Released, Fixes The 7.3 Bugs

[bridgman]

@KDesk : No, I don't. I've been using radeon for almost a year now.
Moreover, I'm running a 2.6.29 kernel and xserver 1.6. Both are incompatible with the latest AMD's driver.

Everyone agrees it is strange so. I can do a screencast if you want. But I can assure you, this is REALLY great !! Every single animation is so smoooooooooth ! And the CPU load while playing with compiz approaches 0 !

Yep, you're definitely running radeon. Unless you picked up a KMS driver stack from Fedora (which seems unlikely given the version numbers) I don't have a good explanation for why you are getting RDR, but I guess it's a good problem to have. Don't touch anything on that system

If you *are* running a KMS stack somehow, then you're seeing what everyone else should start to see in a few months.

[MùPùF]

I did compile a KMS stack, but I changed back because of instabilities.

But I'm sure I'm using the normal stack now, pacman (the package manager of ArchLinux) would have warned me if I didn't.

So, for those who haven't my chance, I can assure you it is AWESOME !

My glxgears in action, RDR but not tear-free:
http://fs.mupuf.org/files/glxgears2.png

[RealNC]

How on earth did you make that picture?

[MùPùF]

How on earth did you make that picture?

$ glxgears

And then grabbed the window and moved it while pressing the screenshot key.

I have no clues why the background is transparent though.

[RealNC]

Tearing is an effect of the monitor. It never shows in screenshots, only with pictures taken with a camera... :P Why is it showing on your screenshot?

[MùPùF]

Are you sure that tearing is an effect of the monitor ?
I thought it had to see with changing the front buffer while updating the screen. I didn't activate V-Sync (I should start looking for it).

Whatever, it has always been this way with the radeon driver on my laptop. Usually, you can barely see it but it is quite visible with glxgears. I guess it is because it is not really accelerated (look at the poor FPS rate, and a core of my CPU is fully used).

[bridgman]

When you add a compositor into the mix, you can get tearing at the compositor level as well and that *does* show up in screen shots.

[RealNC]

Didn't think of that.

So in other words, we're screwed double

[bridgman]

So in other words, we're screwed double

Only temporarily -- I'm sure that's a great comfort

MacOS and Vista were designed around a compositor, while X/DRI has a variety of compositors which can be inserted in what is fundamentally a non-composited stack. There probably needs to be a standard way to handle buffer queues all the way from app through compositor to screen so that :

(a) only completed images get composited,

(b) only completed frames from the compositor get displayed on the screen,

(c) screen updates are synchronized with vblank, and

(d) fixed-rate apps like video playback can either double or drop frames as needed to stay in sync with the display refresh, and games can reliably cap at display refresh rate.

Working the other way - genlocking the display refresh rate to the video frame rate -- sounds attractive but is tough to implement reliably.

Krh's work on Wayland is a good example of "designing around a compositor from day one". Whether the future is something like Wayland or just knowledge and ideas from Wayland going back into the current graphics stack, that's what it's going to take.

The good news is that a lot of this can probably be hacked into the current stack (the current tear-free code in radeon/radeonhd is essentially an innovative hack), it just won't work all the time or in all configurations.

[MùPùF]

Only temporarily -- I'm sure that's a great comfort

MacOS and Vista were designed around a compositor, while X/DRI has a variety of compositors which can be inserted in a non-composited stack. I don't think the changes required will be huge, but there needs to be a standard way to handle buffer queues from app to compositor and compositor to screen so that only completed images get composited, only completed frames from the compositor get displayed on the screen, screen updates are synchronized with vblank, and fixed-rate apps like video playback can either double or drop frames as needed to stay in sync with the display refresh, or that the display refresh can be synchronized to the video frame rate.

Krh's work on Wayland is a good example of "designing around a compositor from day one". Whether the future is something like Wayland or just knowledge and ideas from Wayland going back into the current graphics stack, that's what it's going to take.

The good news is that a lot of this can probably be hacked into the current stack (the current tear-free code in radeon/radeonhd is essentially an innovative hack), it just won't work all the time or in all configurations.

Thanks for the explanation. Wayland is surely a good project, I can't wait to find an Intel GPU to try it out.

Do you think GEM will be the perfect way to pass buffers from the compositor to the driver ? It would be faster than copying each frame (it is a supposition). I think it is the way Wayland implements everything.