[RS482] low performance due to removal of _tnl_ProgramCacheInit()

[sergks]

[Problem]
Performance regression on Xpress 200M for Jaunty.

[Impact]
Affects users of older R300-based chipsets, causing a performance regression which can make the system unusable in some situations.

[Development Solution]
The proposed patch to solve this is present upstream and has been included in Ubuntu Karmic for some time now with no ill effect.

[Patch]
Minimal patch which is confirmed by 5 users to improve performance with no side effects not already present with existing code:
http://launchpadlibrarian.net/27634168/r300_context_tnlcache_fix.patch

[Reproduction]
With affected hardware, run a GL application such as Neverball. Note the rendering performance and cpu utilization. With patch applied, rendering will be faster and cpu usage lower.

[Regression Potential]
The patch only affects code that is invoked on R300-class hardware, so any regression this could cause will be limited in scope to a narrow subset of users.

Comment #22 indicates that upstream feels there may be some risk of freeze issues with this patch, however this has not been seen in testing so far. If the freeze can be reproduced by anyone, then this patch should not go in, since a freeze regression would be more severe than a performance regression.

Five people have tested this patch so far. It would be more comfortable seeing this patch tested more widely, but this may be the limit of what can be expected with just PPA testing. It is recommended that ample time be given for testing this patch before putting into -updates.

[Original Report]
My Xpress 200M is almost dead after I upgraded the system to Ubuntu 9.04.

glxgears:
1256 frames in 5.0 seconds = 251.181 FPS
1224 frames in 5.0 seconds = 244.754 FPS
1673 frames in 5.0 seconds = 334.345 FPS
1610 frames in 5.0 seconds = 321.985 FPS

I had above 1100 FPS in 8.10. I deleted the old xorg.conf - did not help. Then did dpkg-reconfigure xserver-xorg - no improvements. I do not see errors in Xorg.log. Everything is working (compiz, some games) but very slow.
I believe that something is wrong with the card detection:

radeontool --debug
Found card 1002:5955 (30000)
(unknown card)
Radeon found. Base control address is b80b2000; base framebuffer address is a7f2d000.

ProblemType: Bug
Architecture: i386
DistroRelease: Ubuntu 9.04
Package: xserver-xorg-video-ati 1:6.12.1-0ubuntu1
ProcEnviron:
 SHELL=/bin/bash
 LANG=ru_RU.UTF-8
ProcVersion: Linux version 2.6.28-11-generic (buildd@rothera) (gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4) ) #36-Ubuntu SMP Fri Mar 20 19:40:40 UTC 2009
SourcePackage: xserver-xorg-video-ati
Uname: Linux 2.6.28-11-generic i686

[lspci]
00:00.0 Host bridge [0600]: ATI Technologies Inc RS480 Host Bridge [1002:5950] (rev 01)
     Subsystem: Hewlett-Packard Company Device [103c:30a4]
01:05.0 VGA compatible controller [0300]: ATI Technologies Inc Radeon XPRESS 200M 5955 (PCIE) [1002:5955]
     Subsystem: Hewlett-Packard Company Device [103c:30a4]

[sergks (sergks)]

I forgot to mention that there are no changes in performance if I disable the desktop effects.

[sergks (sergks)]

The same problem after full re-installation of the system. Can this be fixed in Jaunty?

[Bryce Harrington (bryce)]

On Wed, Apr 08, 2009 at 09:51:20PM -0000, sergks wrote:
> The same problem after full re-installation of the system. Can this be
> fixed in Jaunty?

Final Freeze is coming up within the day, so unless you can identify a
specific patch to pull, probably not. (With how little time remains,
I'm just focusing on bugs where patches are already at hand.)

[David (davidmarch007)]

I can confirm this in Jaunty.

david@ubuntu-laptop:~$ glxgears
Running synchronized to the vertical refresh. The framerate should be
approximately the same as the monitor refresh rate.
1061 frames in 5.0 seconds = 212.088 FPS
1409 frames in 5.0 seconds = 281.755 FPS
1400 frames in 5.0 seconds = 279.827 FPS
1382 frames in 5.0 seconds = 276.358 FPS
1389 frames in 5.0 seconds = 277.713 FPS
1333 frames in 5.0 seconds = 266.511 FPS
1429 frames in 5.0 seconds = 285.785 FPS

david@ubuntu-laptop:~$ radeontool --debug
Found card 1002:5975 (30000)
  (unknown card)
mapping ctrl region

david@ubuntu-laptop:~$ lspci | grep Xpress
01:05.0 VGA compatible controller: ATI Technologies Inc RS482 [Radeon Xpress 200M]

david@ubuntu-laptop:~$ uname -a
Linux ubuntu-laptop 2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17 01:57:59 UTC 2009 i686 GNU/Linux

This is on an Acer laptop and it is a pretty common card. A fix would likely help many.

[David (davidmarch007)]

UPDATE:

Upgrading to 2.6.30rc2 did NOT solve this issue.

david@ubuntu-laptop:~$ glxgears
1386 frames in 5.0 seconds = 277.199 FPS
1406 frames in 5.0 seconds = 281.172 FPS
1375 frames in 5.0 seconds = 274.887 FPS
1419 frames in 5.0 seconds = 283.761 FPS
1405 frames in 5.0 seconds = 280.881 FPS

david@ubuntu-laptop:~$ uname -a
Linux ubuntu-laptop 2.6.30-020630rc2-generic #020630rc2 SMP Wed Apr 15 14:00:27 UTC 2009 i686 GNU/Linux

[sergks (sergks)]

There is a solution to this problem: http://www.nabble.com/R300-regression-td23108996.html
I patched r300_context.c (I did this manually), re-compiled the mesa and now I am back:
glxgears
5655 frames in 5.0 seconds = 1130.871 FPS
5656 frames in 5.0 seconds = 1131.106 FPS
5654 frames in 5.0 seconds = 1130.648 FPS

Sorry, I can not provide the patch. I do not know how to do this.

[sergks (sergks)]

Update:
This solution is preliminary since it may result in lockups on some systems. Please check the last post in the link I provided.

[Pavol Rajzák (rapasoft)]

542 frames in 5.0 seconds = 108.259 FPS
546 frames in 5.0 seconds = 109.064 FPS
524 frames in 5.0 seconds = 104.709 FPS
565 frames in 5.0 seconds = 112.983 FPS
548 frames in 5.0 seconds = 109.523 FPS

i have the same problem on ATI FireGL 9000, glxinfo says direct rendering is enabled, but CPU is used at 100%...

[czatan (dplucinski)]

I can do this in Jaunty x86_64

 Ati 1100 with AMD Turion(tm) 64 Mobile Technology MK-36 in acer 5100

1950 frames in 5.0 seconds = 389.986 FPS
2096 frames in 5.0 seconds = 418.787 FPS
1988 frames in 5.0 seconds = 397.550 FPS
2186 frames in 5.0 seconds = 437.070 FPS
2075 frames in 5.0 seconds = 414.925 FPS

and
dariusz@drubuntu:~$ cat /proc/mtrr
reg00: base=0x000000000 ( 0MB), size= 2048MB, count=1: write-back
reg01: base=0x070000000 ( 1792MB), size= 256MB, count=1: uncachable
reg02: base=0x0d0000000 ( 3328MB), size= 256MB, count=1: write-combining

[Du (duwei-1987)]

I'm also experiencing this problem,I had about 3000 FPS in Ubuntu 8.04 with the restricted driver installed,but only 300 FPS in Ubuntu 9.04(no such driver listed)

[Dakkiott (oticojimenez)]

I have the same problem on MSI RS482M4 board (Ati Xpress 200), I will try this patch and come back.

(Sorry my bad English)

[Dakkiott (oticojimenez)]

Guys... you are great, the FPS are now x2... (but some slow the compilation jajaja)
Thank you very much!

PD: the attachment is the *.deb patched for x86!!

[Bryce Harrington (bryce)]

Um, "Patch for Ati Radeon Xpress 200" is a deb not a patch. If you will attach the patch itself, we can look into pulling it into ubuntu proper.

[sergks (sergks)]

Ok, guys. There will not be any solution for this problem in Mesa 7.4 and even, I think, in Mesa 7.5. However, this problem has been already fixed in the radeon-rewrite branch. You can try Tormod Volden's packages for radeon-rewrite here: https://launchpad.net/~xorg-edgers/+archive/radeon . They work fine on my Xpress 200M.

[Jeremy Wilkins (wjeremy)]

I also have a 200M chipset on a laptop and have been experiencing the same troubles. I followed the link that sergks left there and installed those components, I also installed the newer radeon drivers, but it messed up my ability to run any GL programs that would run before, GLX gears runs beautifully however, and so does desktop effects. I will try using the older driver again to be sure that it isn't as a result of the new driver alone.

[Jeremy Wilkins (wjeremy)]

More on the previous post. It appears that the updated Mesa does fix this problem, but other programs like warzone 2100 and wine are built against mesa 1.4 libraries and they crash the whole system. The updated radeon drivers don't seem to have any noticeable effect. In order to implement this fix with the 1.6 base, just about every Mesa linked 3D program would also need updating. I doubt this will ever happen, but the fix mentioned above can be applied to the 1.4.0 branch. The details of the official patch are here:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=ed4c6cbe017b4e8bacb7e012d4baaf77a20a2c33

We just need to backport it.

[Jeremy Wilkins (wjeremy)]

This is the official patch, but it may or may not work against 1.4 sources.

[Jeremy Wilkins (wjeremy)]

This patch applies successfully on the 1.4 branch, I am compiling a test package to confirm success or failure on the stability side.

[Jeremy Wilkins (wjeremy)]

This patch is the wrong one. It is an old patch. The correct patch has similar results to the mesa libraries mentioned above.

[Jeremy Wilkins (wjeremy)]

Updated patch. This one moves one of the TNL lines. Apparently it improves performance, but as the author mentioned it causes lockups for some things. I will test is thoroughly.

[Jeremy Wilkins (wjeremy)]

After testing the patch on amd64, I have not noticed any instabilities, and all GL programs tested so far seem to work normally and much faster. The whole system is tremendously more responsive and my GLX gears get double the scores on my Radeon 200M that it was getting with the unpatched mesa. The results were immediately noticeable upon installation.

[Irom Nike (senseless-one)]

i have the same problem with my toshiba a215 laptop.

$ glxgears
Running synchronized to the vertical refresh. The framerate should be
approximately the same as the monitor refresh rate.
1311 frames in 5.0 seconds = 262.136 FPS
1573 frames in 5.0 seconds = 314.562 FPS
1609 frames in 5.0 seconds = 321.686 FPS
1532 frames in 5.0 seconds = 306.386 FPS
1607 frames in 5.0 seconds = 321.279 FPS

$ lspci |grep VGA
01:05.0 VGA compatible controller: ATI Technologies Inc RS690M [Radeon X1200 Series]

$ uname -a
Linux laptop 2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17 01:57:59 UTC 2009 i686 GNU/Linux

and i have no idea how to use any patches...

[Jeremy Wilkins (wjeremy)]

Irom Nike: You should be able to try out the .deb file posted above, but be warned that it is an untested binary and may break something. If you installed the jaunty-updates version of mesa, then you may need all the mesa related packages updated with the patch versions. I am on my laptop (a 64bit platform) right now and 300kms from home, but I could assist in compiling a full set of 32bit binaries once I get home, since my home server is a 32bit OS. I might even be able to compile them remotely, but I have been having troubles with that computer since I upgraded it to jaunty (Almost a cliche). It isn't jaunty's fault on that machine, it has been sick for some time, the upgrade just exposed its issues.

BTW. I have done more tests with that patch against desktop effects, games, wined3d, etc. It has been rock solid for me, but my computer has no TCL. I am uncertain whether a card with TCL would break or not.

Bryce Harrington: I am curious if a personal ppa is in order? Will this patch get pushed to updates or backports? If not, I am ok to open a ppa in the mean time for only those with cards that are suffering until the radeon-rewrite code becomes the norm. In testing this code on my 200M fairly well with all the 3d pressure of desktop effects with magic lamp and desktop cube enabled, it hasn't crashed once and has run like a dream. It is faster than I ever remember my card functioning and the constant memory leak issues that I used to experience seem to have gone away. Videos that used to pin my cpu (3d texture mapped) now don't even make the computer busy at all. 3D video games run faster than I ever remember them running, and likewise don't tax the computer anymore, and the general stability of the system seems to have improved. Obviously, because of the reduced cpu usage my computer consistently runs cooler and the battery lasts longer. I would like those with TCL capabilities to offer their experiences too. If it locks up TCL supporting cards, we obviously can't send the patch to the updates repo, but we can reserve it only to certain models in a ppa.

[Bryce Harrington (bryce)]

Hi Jeremy,

Thanks for chasing down a patch. I've packaged it for jaunty and stuck it in my ppa for testing:

  https://edge.launchpad.net/~bryceharrington/+archive/ppa

It might be feasible for an SRU, so I'll add the jaunty task and mark it fixed in karmic since this patch is already included in the version we have there. But I'd like to see more extensive testing done to be sure it doesn't cause regressions first. If you can scare up half a dozen people to give it a try and we find no regressions, then we can look at SRUing it.

[Irom Nike (senseless-one)]

thanks for response.

i updated everything using Bryce Harrington's PPA.
i see no improvements in glxgears FPS, but now it does not occupy cpu anymore.
well i know that glxgears is not a benchmark, but it is still impossible to play any 3D games.

compiz works quite well except some horizontal distortions when moving windows or desktop cube.

anyway thanks for your work guys!

p.s. sorry for my pure english.

[Jeremy Wilkins (wjeremy)]

Bryce: Thank you for compiling it in your ppa, I will try the new packages you uploaded right away to make sure the patches applied well.

BTW If you are changing the summary, you can add high cpu to that. It is a common result everyone experiences.

[Jeremy Wilkins (wjeremy)]

I have tested the packages in your ppa and they work fine. The speed is improved in the same way. Desktop effects works, games work. I haven't tested wined3d yet. My R300 always had graphical glitches in wine with these drivers anyhow. Now I just need more testers.

[Jeremy Wilkins (wjeremy)]

Irom: Can you give me the output of the following commands at the command line:

glxinfo | grep direct

glxinfo | grep OpenGL

It also looks like your driconf settings may not be their default values. Try the default settings first, then experiment from there. It is strange that glxgears thinks you are running in vsync mode, but your results don't exhibit that.

[Irom Nike (senseless-one)]

Jeremy Wilkins:

$ glxinfo | grep direct
direct rendering: Yes

$ glxinfo | grep OpenGL
OpenGL vendor string: DRI R300 Project
OpenGL renderer string: Mesa DRI R300 20060815 x86/MMX+/3DNow!+/SSE2 NO-TCL
OpenGL version string: 1.3 Mesa 7.4
OpenGL extensions:

i removed .drirc file from my home directory and then run driconf again.
the result:
$ cat .drirc
<driconf>
    <device screen="0" driver="r300">
        <application name="Default">
            <option name="force_s3tc_enable" value="false" />
            <option name="texture_coord_units" value="8" />
            <option name="fthrottle_mode" value="2" />
            <option name="disable_stencil_two_side" value="false" />
            <option name="tcl_mode" value="3" />
            <option name="texture_depth" value="0" />
            <option name="fp_optimization" value="0" />
            <option name="def_max_anisotropy" value="1.0" />
            <option name="no_rast" value="false" />
            <option name="command_buffer_size" value="8" />
            <option name="round_mode" value="0" />
            <option name="dither_mode" value="0" />
            <option name="disable_lowimpact_fallback" value="true" />
            <option name="texture_image_units" value="8" />
            <option name="disable_s3tc" value="false" />
            <option name="color_reduction" value="1" />
            <option name="vblank_mode" value="1" />
        </application>
    </device>
</driconf>

[Irom Nike (senseless-one)]

... and it gives me no changes in 3D performance.

$ glxgears
1586 frames in 5.0 seconds = 317.067 FPS
1593 frames in 5.0 seconds = 318.553 FPS
1542 frames in 5.0 seconds = 308.372 FPS
1591 frames in 5.0 seconds = 318.190 FPS

here's nothing about vsync now.

[Andrew Starr-Bochicchio (andrewsomething)]

I've been running the PPA package for about 24 hours now. I haven't experienced any issues, no lock ups. I am getting much better frame rates from glxgears, but honestly I'm not really _feeling_ any noticeable performance improvements either.

$ glxinfo | grep OpenGL
OpenGL vendor string: DRI R300 Project
OpenGL renderer string: Mesa DRI R300 20060815 x86/MMX+/3DNow!+/SSE2 NO-TCL
OpenGL version string: 1.3 Mesa 7.4
OpenGL extensions:

$ glxgears
3633 frames in 5.0 seconds = 726.518 FPS
5347 frames in 5.0 seconds = 1069.324 FPS
5353 frames in 5.0 seconds = 1070.466 FPS
5296 frames in 5.0 seconds = 1059.027 FPS

Thanks all for your work!

[Jeremy Wilkins (wjeremy)]

Irom: Hmmm... It sounds to me like you are experiencing another issue entirely. I'm afraid yours might not be resolved until the Radeon-Rewrite code comes into action. What happens if you use the links above regarding radeon-rewrite and the new radeon drivers? You will have to undo those changes if you want other OpenGL apps to still run without freezing your system, but if that solves your problem for glxgears and desktop effects then you may need to wait for those drivers. Unless we can pull a patch from upstream. I think this is the link:
https://launchpad.net/~xorg-edgers/+archive/radeon

If you try this mesa and follow the directions on the page for the radeon drivers too, to see if that fixes it. Then undo the mesa install and see if maybe just the drivers alone may fix the issue. Please report your findings.

[Irom Nike (senseless-one)]

i'm not sure that i have understood everything correctly. sorry.

first of all i removed the Bryce Harrington's PPA from my sources.list.
then i added there the entries from https://launchpad.net/~xorg-edgers/+archive/radeon

updated libgl1-mesa-dri, libgl1-mesa-glx, libglu1-mesa and mesa-utils.
restarting X and see no improvements.

$ glxgears
Running synchronized to the vertical refresh. The framerate should be
approximately the same as the monitor refresh rate.
1560 frames in 5.0 seconds
1589 frames in 5.0 seconds
1618 frames in 5.0 seconds
1518 frames in 5.0 seconds
1372 frames in 5.2 seconds

well it says about vsync again somewhy. i didn't even touch driconf or .drirc. and as you can see glxgears do not calculate the FPS in its output.

after this i downloaded and installed xserver-xorg-video-radeon_6.12.99+git20090604.32c218c5-0ubuntu0tormod_i386.deb from https://launchpad.net/~tormodvolden/+archive/ppa

and got the same results with glxgears..

[Tormod Volden (tormodvolden)]

Irom, it seems like you did it correctly. For glxgears, Bryce removed the FPS output since it was "abused" for benchmarking.

[Jeremy Wilkins (wjeremy)]

I'm starting to wonder if there is another separate driver problem hampering the RS690 chipset. You did mention that your CPU wasn't being pinned high anymore. I think that is the main fix that this patch brings, but my chipset is RS482 Xpress 200M, so it may be a different problem as well. If you had fglrx drivers installed previously did you run the command:
sudo apt-get remove --purge xorg-driver-fglrx

In order to make the new drivers function normally the proprietary drivers need to be purged out first.

[Irom Nike (senseless-one)]

i had no fglrx drivers installed.

i mentioned one more thing today. my CPU works at ondemand mode at 800 MHz.
it turned to 1.9 GHz with old mesa packages with glxgears. today with new mesa i can manually put CPU to performance mode and then glxgears run up to 590 FPS and desktop effects start to work a bit better. but i don't think that performance mode is a good idea, because cpu and the whole laptop get really hot.
i don't know if it is informative..

[Jeremy Wilkins (wjeremy)]

590fps is normal on the RS690 chipset with the open source drivers. I get around 570fps which is similar. So it looks like it is working to me. My guess is that you are suffering from a power management problem instead, which may be related to the new video power management code. Besides that, your configuration sounds like it is functioning normally to me. If you want faster 3d however, you'll need to initiate performance mode. Unfortunately, the ondemand power saving mode isn't smart enough to realize that you want faster 3d graphics, it just looks at cpu demand. They should fix this problem eventually, but it may be valid to submit a separate bug report about power management affecting 3d performance. That said, I don't think I experience this problem in ondemand mode, but I probably don't have the same cpu, system board or possibly driver that you do and I run in 64bit mode. I have reverted my configuration to the stock jaunty drivers with the exception of the patched mesa libraries.

[Bryce Harrington (bryce)]

Okay, sounds like there are two positive test cases so far. See if you can find two or three more people to give it a test; even if they are not experiencing low performance but can test the package to verify it does not cause regression, that would be enough.

[Jeremy Wilkins (wjeremy)]

Bryce: Can you bring in the recent patch for 7.4-0ubuntu3.2 and recompile and bump this version to 7.4-0ubuntu3.3~bug347569~1 as the current mesa still does not have this fix? I noticed after upgrading to recent mesa that it is slow again. Robert Hooker (Sarvatt) added a patch for LP#256021, and LP#257600 which has been released as ubuntu3.2 already.

[Jeremy Wilkins (wjeremy)]

Everyone: I need more people to test this patch. Preferably if your video supports TCL or is a different generation R200/400/R500, so we have evidence of whether it is stable, or if regressions occur.

[Irom Nike (senseless-one)]

Do you need any more reports from me?
In my case the patch is stable and i see no regressions or something like this.

[Jeremy Wilkins (wjeremy)]

I have tested this change on an RV350 card Radeon 9600 which supports TCL with no negative side effects. The cpu usage seems lower and the desktop effects more responsive. I used to get lockups with 3D on this card (cpu overheat maybe), but they are gone now.

[Mads Michelsen (madchine)]

lspci:
01:05.0 VGA compatible controller: ATI Technologies Inc RC410 [Radeon Xpress 200M]

Problem was confined to slow OpenGL rendering.

Results of using the PPA packages:
- glxgears get an increase from 3-400 to around 500
- much improved rendering in Neverball
- decreased CPU use when running Neverball

I have only just installed it - will watch for side effects and report if any. Is there some more specific results you would like to see?

[Miroslav (dzundam-deactivatedaccount)]

The same problem on my Dell Vostro 1000
CPU AMD TurionX2 2000MHz, 6GB RAM, ATi RS485 IGP chipset (Xpress 1150)

[$ glxgears @ powersave governor CPU@800MHz]
956 frames in 5.0 seconds = 191.193 FPS
982 frames in 5.0 seconds = 196.330 FPS
992 frames in 5.0 seconds = 198.368 FPS

[$ glxgears @ performance governor CPU@2000MHz]
2461 frames in 5.0 seconds = 492.120 FPS
2461 frames in 5.0 seconds = 492.170 FPS
2470 frames in 5.0 seconds = 493.977 FPS

[$ lspci | grep VGA]
01:05.0 VGA compatible controller: ATI Technologies Inc RS482 [Radeon Xpress 200]

[$ uname -a]
Linux ;-);-);-) 2.6.28-13-generic #45-Ubuntu SMP Tue Jun 30 22:12:12 UTC 2009 x86_64 GNU/Linux

[$ glxinfo | grep OpenGL]
OpenGL vendor string: DRI R300 Project
OpenGL renderer string: Mesa DRI R300 20060815 NO-TCL
OpenGL version string: 1.3 Mesa 7.4
OpenGL extensions:

[$ glxinfo | grep direct]
direct rendering: Yes

Almost 100% CPU usage, framerate highly depends on CPU frequency.

After I upgraded libgl1-mesa-dri, libgl1-mesa-glx, libglu1-mesa and mesa-utils:

[$ glxinfo | grep OpenGL]
OpenGL vendor string: DRI R300 Project
OpenGL renderer string: Mesa DRI R300 (RS400 5974) 20090101 NO-TCL
OpenGL version string: 1.4 Mesa 7.6-devel
OpenGL extensions:

[$ glxgears @ powersave governor CPU@800MHz]
Running synchronized to the vertical refresh. The framerate should be
approximately the same as the monitor refresh rate.
3000 frames in 5.0 seconds
3029 frames in 5.0 seconds
2999 frames in 5.0 seconds

[$ glxgears @ performance governor CPU@2000MHz]
4914 frames in 5.0 seconds
4963 frames in 5.0 seconds
4944 frames in 5.0 seconds

Good job, less CPU usage and better performance. No issues yet except
this "vertical refresh" message.

[Bryce Harrington (bryce)]

I've put in an SRU for this patch. Ideally, I would have liked to see more testers since I'm a bit iffy on this patch, but if I count correctly there have been 5 testers which I guess is close enough.

I've updated the patch to include the ubuntu3.2 change, although that one seems to be stuck in -proposed. In looking at it again, it's a trivially good patch, I think they're just waiting on some feedback from users who have run that version without problem, so you guys could probably help out by commenting on bug #256021 that you've run this version from ubuntu-proposed and give it your thumbs up. That would enable that fix to go in, which would enable this one to go through too.

Btw, for future reference, going forward I am no longer going to accept performance regression feedback that uses glxgears numbers. Everyone knows it's not any good as a benchmark, so reports that still use its numbers anyway are questionable whether the reporter actually knows what they're talking about. ;-) In this regard, it was good to see the reference made to Neverball, because otherwise the only factual data this bug report would have is on glxgears.

[Jeremy Wilkins (wjeremy)]

I agree it is an invalid benchmark for performance testing, but notable cpu usage differences are. BTW. This will become invalid for Karmic. The new drivers in place there work fine out of the box,

[Martin Pitt (pitti)]

Accepted mesa into jaunty-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

[Jeremy Wilkins (wjeremy)]

I regret not testing these changes more. They seem to increase hard lockups for 3D activity considerably. After updating the drivers and dri to the versions supplied by an independent ppa utilizing an updated driver from upstream, no lockups occur anymore. The ppa comes from here:
https://launchpad.net/~fabio-pedretti/+archive/ppa

[Tormod Volden (tormodvolden)]

Jeremy, is it enough to only install the xserver-xorg-video-ati (and -radeon) package from the PPA?

[Jeremy Wilkins (wjeremy)]

I haven't tried that, but as I understand it, they are tightly integrated and it's the DRM module that is crashing the system anyways, not the radeon driver piece, however the driver DOES need to be updated to solve the problem too. The radeon package only contains the xorg-driver loadable module, which provides the DRM piece access to provide the DRI interface for X programs. We need the DRM piece updated as the current one is buggy. The old one mistreats non-TCL cards and misuses the CPU, and the current one crashes often on TCL cards. I just don't see being able to quickly pass a whole DRM/driver upgrade process as this will affect everyone on all systems. BTW the driver/drm on that site is mainly for radeon, so I'm not sure how the upgrade would affect Intel/nv/nouveau drivers.

I have been testing these new drivers and DRM on a TCL enabled card and they are stable and functional without needing any upgrade to Mesa. I have had a crash running WoW on wine, but that was after playing for hours in D3D mode. I couldn't even get into the world at all before with the current drivers without kernel locking the system. The crash I experienced only took down wine, not X, so it was more likely a wine problem. If we could possibly pull these patches for the radeon branch of DRM alone that would be great, but I think considerable core DRM updates exist in this newer version which may prevent it. One more thing to note: I noticed that if I run the 2.6.30 kernel with these new modules the system runs fluidly and when I ran 2.6.28 I received random freezing which would resume after a few seconds until one time I received a total hard lock (numlock no longer worked). So there is a problematic kernel portion involved in this too. I am running on ext4, so that may be the problem there. This was in WoW of course, but I expect similar results in any other intense 3D apps.

All OpenGL apps/games I've tried work just fine (extreme tux racer, warzone 2100, blender).
Oh, and for a real teaser, WoW runs at 10-20 FPS in a busy area in wine D3D mode on my Radeon 9600 without needing to disable any extensions (I could not get opengl mode to work unfortunately). All other 3D apps are equally fluid and nice. It's not a superb card by any stretch of the imagination, so likely all radeon cards should see impressive improvements. Still need to test non-TCL cards though for the original problem of this thread. My non-TCL laptop has been upgraded to karmic so this driver is not necessary anymore for it. It runs fine.

The caveats are that I noticed a few graphical anomolies in wine d3d with the texture handling, but nothing that causes tremendous harm. It was working better than I've ever seen on OSS radeon drivers.

[Jeremy Wilkins (wjeremy)]

Correction to above. WoW OpenGL mode for wine works just fine with these drivers with a few minor glitches: disappearing text inside buildings and classic white minimap problem, but the D3D mode performs equally well with less problems. The current drivers just hard lock the system.

[Martin Pitt (pitti)]

This proposed update has been in -proposed for half a year without any feedback. Therefore it was removed from hardy-proposed again.

[John Doe (jodo-deactivatedaccount)]

Why? I'm seeing this Report the first time now. I've wondered all the time why the GFX-Performance was slowing down more and more. This should definitly beeing fixed.