Mesa 7.4 Released, Fixes The 7.3 Bugs

[phoronix]

Phoronix: Mesa 7.4 Released, Fixes The 7.3 Bugs

Just a bit more than two months have passed since Mesa 7.3 was released (and about one week since the first 7.4 release candidate), but this evening Brian Paul announced the final release of Mesa 7.4. This new Mesa release incorporates bug-fixes since the 7.3 release...

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

[MùPùF]

Great !

It gives me a 40% faster glxgears on my r3xx radeon !
Wonderful !

At the same time, full-HD videos are still not supported while flash fullscreen ones are becoming watchable without a lot of tearing and a really low framerate.

Waiting for Mesa 7.5 and the DRI2 radeon driver now !

By the way, I have a strange (but really good) behavior. According to my Xorg logs, I haven't any DRI2 capabilities. But, my videos and glxgears are looking great on the cube (they are at the right place, not painted on the front buffer anymore).
How is it possible ?? Wasn't it supposed to be DRI2's work ?

[bridgman]

Yeah, it's not supposed to do that yet ;)

Which distro are you running ?

[MùPùF]

I'm running ArchLinux.
Here are the packages versions :

xorg-server 1.6.0-1
mesa 7.4-0 --> It also worked with the 7.3.0 version
xf86-video-ati 6.12.0-1 --> It also worked with the 6.11.0 version
libdrm 2.4.5-2

It works with the 2.6.28 and 2.6.29 kernel versions.

In case you ask, ArchLinux tries to stay as vanilla as possible.
I checked, there are not patches or anything that could lead to this behavior.

It also seems like Rendering to Redirected works well because Firefox's scrolling is as fast with compiz than with metacity.

[dungeon]

Lighting (i think?) in doom3 is broken for me on r200:o. (self compiled mesa-7.4, other games seems OK).

http://i263.photobucket.com/albums/ii149/smokidungeon/shot00001.jpg

P.S. No, No, dynamic ligthing is now really broken everywhere not just in doom3, spoted in every single quake3 based games i have.

I knew probably what is wrong here, because every time i've seen "bugfix" in core is about "reference counting":

Fixed bad reference counting for 1D/2D texture arrays

that is very bad for r200 driver. Just like:

Implement mutex/locking around texture object reference counting.
http://cgit.freedesktop.org/mesa/mesa/commit/?id=e279a0a076b7a3c8d60138c19870784c260c9d67

And i hope those will never be fixed...

[KDesk]

@MùPùF, I think you are using the catalyst driver http://www.phoronix.com/scan.php?page=article&item=amd_catalyst93_composite&num=1 or some unreleased code hehe :)

[MùPùF]

@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.

Here is a part of my Xorg log :
(II) LoadModule: "radeon"
(II) Loading /usr/lib/xorg/modules/drivers//radeon_drv.so
...

You can see it here : http://pastebin.com/m1c2818ef

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 !

[dungeon]

Seems to fonts now have some weird "filtering" or maybe that is another bug? Anyway, these fonts are really bad! Again that is not just in RTCW, the same is in Doom3 too.

mesa-7.3
http://i263.photobucket.com/albums/ii149/smokidungeon/mesa73.jpg

mesa-7.4
http://i263.photobucket.com/albums/ii149/smokidungeon/mesa74.jpg

Is there anybody who can now clearly read what are mission objectivites in here?:D
http://i263.photobucket.com/albums/ii149/smokidungeon/blind.jpg

So, i don't know how this can be called "just" bug fix release?

[d2kx]

It has been released for the spring distributions anyway I think.

[MùPùF]

Seems to fonts now have some weird "filtering" or maybe that is another bug? Anyway, these fonts are really bad! Again that is not just in RTCW, the same is in Doom3 too.

Have you filled a bug on http://bugs.freedesktop.org ?

I'm sorry, I can't try it out because I can't play with my XPress 200M (I can barely play on TeeWorlds in window mode in 640*480).

[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 :D

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 :p

[bridgman]

So in other words, we're screwed double

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

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 :D

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.

[DanL]

Anyone know what the chances are that this makes its way into Ubuntu Jaunty?

[bugmenot]

I think the chance is very low, because Jaunty gets released in less then a month. Not enough time for testing etc. Also Jaunty is already frozen, so no new packages without exception.
I hope for 9.10 :)

[d2kx]

I think the chance is very low, because Jaunty gets released in less then a month. Not enough time for testing etc. Also Jaunty is already frozen, so no new packages without exception.
I hope for 9.10 :)

Don't hope for 9.10. Instead, hope for Mesa 7.5/7.6 :)

[suokko]

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).

I got same effect when running glxgears using mesa software renderer over ssh.

[MùPùF]

I got same effect when running glxgears using mesa software renderer over ssh.

Yep, that's understandable.

The fact is that it IS hardware accelerated, my CPU usage is really really low even when playing videos.
That's why I asked the question, it did this when I installed the XServer 1.6.

[dungeon]

Have you filled a bug on http://bugs.freedesktop.org ?

I'm sorry, I can't try it out because I can't play with my XPress 200M (I can barely play on TeeWorlds in window mode in 640*480).

I posted it on nabble:

http://www.nabble.com/Dynamic-ligthing-is-broken-in-7.4%2C-maybe-td22754754.html

someone with R400 (X700) have dynamic lighting regression too in q3a.

I think none distro will include plain mesa-7.4, it has so many regression...

http://i263.photobucket.com/albums/ii149/smokidungeon/Prey-mesa-73.jpg
http://i263.photobucket.com/albums/ii149/smokidungeon/Prey_mesa-74.jpg

[chaos386]

I think the chance is very low, because Jaunty gets released in less then a month. Not enough time for testing etc. Also Jaunty is already frozen, so no new packages without exception.
I hope for 9.10 :)

I thought 7.4 was the stable release of 7.3 and as such will be bugfixes only, no new features? If that's the case, it seems reasonable to assume it'll make it's way into Jaunty eventually.

[bugmenot]

I thought 7.4 was the stable release of 7.3 and as such will be bugfixes only, no new features? If that's the case, it seems reasonable to assume it'll make it's way into Jaunty eventually.

Well, I did not think at that by now. You could be right :)

[some-guy]

Either 7.4, or 7.3 with a lot of of fixes applied

[dungeon]

Have you filled a bug on http://bugs.freedesktop.org ?

I'm sorry, I can't try it out because I can't play with my XPress 200M (I can barely play on TeeWorlds in window mode in 640*480).

Both these bugs in mesa core are now fixed by Roland Scheidegger (bug #20965, #20966)

Fixed in master (ebc1478e501d43e0de54e7b6c3edfbc81d7d20c6) and mesa_7_4_branch (7be149cfd131c0b3f7d4337bb83e6fba5f563bf9)

[d2kx]

Mesa 7.4 is now used by Ubuntu 9.04.