[gutsy] horrible performance with ati open source drivers

[waxhell]

Binary package hint: xserver-xorg-video-ati

Hardware information:
---

ATI Radeon 8500DV
Athlon XP 1700+ (Tbred)
nForce 1 based mobo
768MB ram

Some real quick background:
---
I get random black screens of nothingness when booting up the computer. This occurs about one in every two boots or so.

Adding Option "BusType" "PCI" to my xorg.conf fixed this issue, however I did notice a sizable drop in performance.

The real bug:
---
After upgrading to gutsy from Feisty, I've been getting a large drop in performance with the opensource 'ati' driver.

xorg likes to thrash about at 100% CPU when anything is drawing to the screen (konqueror, konsole, firefox, etc).

With Option "BusType" "PCI" removed from my xorg.conf, glxgears used to give 3000+ fps in Feisty. Now in Gutsy, it gives about 1200fps. However, given the instabilities in booting, I don't operate very often with this flag enabled. I mainly observed this difference while troubleshooting this issue.

With Option "BusType" "PCI" in my xorg.conf, glxgears drops to about 70fps.

I've tried various combinations of options to help things out but nothing seems to help, including the following:
  option "AGPMode" "4"
  option "AccelMethod" "EXA"
  option "ColorTiling" "on"
  option "EnablePageFlip" "on" <-- this option causes glxgears to start merging frames together
  option "AGPFastWrite" "false"
  option "BusType" "PCI"
  option "AccelDFS" "true"
  option "DMAForXv" "true"
  option "GARTSize" "64"
I've also tried disabling DRI, Composite, and AIGLX.

I've found that usability wise, the best results have been with DRI disabled. It looks like 3d performance is completely shot, becuase glxgears causes xorg to steal all usable CPU cycles. I have to ssh in and kill the glxgears process in order for my system to start responding again. 2D seems to be relatively ok (xorg doesn't thrash around at 100% in this configuration, only about 20-30%). This still is slower than my configuration under feisty.

[waxhell (waxhell)]

One slight discrepancy. the xorg.conf that I linked was wrong. The only difference was that
option "GARTSize" "128" was uncommented. This is somewhat weird, as commenting out DRI did not stop DRI form loading. The only way I can disable DRI is to use the GARTSize option and pass a size that's too large.

This issue started showing up when i reset my xorg.conf with 'sudo dpkg-reconfigure -phigh xserver-xorg'. Before, I could comment out the Load "dri" line, and it would work fine. I copied over the old configs and this still persisted. Not sure what's going on.

[waxhell (waxhell)]

On EXA versus XAA for my configuration:

In Gutsy:
It seems that on my system EXA tends to refresh the screen in large lag blocks. XAA seems much more smooth and the OS seems more usable.

In Feisty:
EXA seemed significantly faster than XAA and tended to tax the CPU less.

[Timo Aaltonen (tjaalton)]

Try setting "Virtual 1680 1050" in the Display -subsection of screen (where Modes is).

This looks like a dupe of 134817

[waxhell (waxhell)]

Still looks like DRI is slowing down my computer massively, even when virtual is reduced down to my screen size.

No change in fps with glxgears and also Xorg is still thrashing at 80-100% cpu when I'm scrolling around or loading large graphical areas in a browser. Took a look at 134817, and it doesn't seem to offer any assistance (that submitter did end up fixing his issues with the Virtual command).

[waxhell (waxhell)]

I was able to duplicate (actually make worse) the slow draw rate with DRI enabled under XAA by using the:
Option "XAANoOffscreenPixmaps" "Enable"

With that option enabled, it sounds like most of my CPU is being used to draw the screen. The splash for KDE is unbearably slow to watch.

I had tried that option before in Feisty, and it seemed to slow down 2D a slight bit, but in my current setup, it's unbearable.

I've also tried dropping down to a 16 bit depth, doesn't seem to make a difference.

[J Fry (j-fry)]

Just a note to say I've got the same problem as waxhell since upgrading to Gutsy release candidate today. Under Feisty my 1.5GHz 1.5GB Dell D600 (ATI Mobility Radeon 9000) laptop ran perfect well with open source ATI driver and Compiz Fusion (with all the bells and whistles: wobbly windows, reflection, glgears animation inside cube, transparency, animated skydome etc). Running Gutsy, xorg hogs the CPU and performance is dire for everything.

Happy to supply any info needed to diagnose problem. My xorg.conf is attached.

[waxhell (waxhell)]

Jem Fry: did you try disabling DRI to see if that helps things out? I'm not sure how that would impact your performance though, as you're running Compiz.

3d acceleration for me with DRI disabled is horrible, but at least the 2D speeds along fine.

[Tormod Volden (tormodvolden)]

Jem, your xorg.conf is not good for the new ati driver. Try without one, and see http://wiki.debian.org/XStrikeForce/HowToRandR12 for more information.

[waxhell (waxhell)]

Seems like some of the CPU thrashing has gone away with the addition of (with DRI enabled):

        Option "MigrationHeuristic" "greedy"

EXA doesn't seem to run as well as XAA.

Glxgears still reports 77fps though.

[Nigel Roberts (nigel-nobiscuit)]

I get similar problems with my Toshiba Tecra S1 with a Mobility 9000 R250 i.e. desktop is unbearably slow both with and without compiz going. Feisty was fine with compiz running.

Xorg.0.log reports that DRI is enabled, however glxinfo says that indirect rendering is being used and nothing shows when I set the debug variables. I also get kernel messages about mtrrs not being found:

[ 2743.024000] mtrr: no MTRR for a8000000,2000000 found
[ 2745.508000] agpgart: Found an AGP 2.0 compliant device at 0000:00:00.0.
[ 2745.508000] agpgart: Putting AGP V2 device at 0000:00:00.0 into 4x mode
[ 2745.508000] agpgart: Putting AGP V2 device at 0000:01:00.0 into 4x mode
[ 2746.812000] [drm] Setting GART location based on new memory map
[ 2746.812000] [drm] Loading R200 Microcode
[ 2746.812000] [drm] writeback test succeeded in 2 usecs

Is it possible that drm is trying to use the wrong mtrr? a8000000,2000000 suggests it's looking for a 32MB mtrr at a8000000, however:

$ cat /proc/mtrr
reg00: base=0x00000000 ( 0MB), size= 512MB: write-back, count=1
reg01: base=0xb0000000 (2816MB), size= 64MB: write-combining, count=1
reg02: base=0xa8000000 (2688MB), size= 128MB: write-combining, count=2

I'd try and change the AGP aperture like it says in the wiki, but the laptop bios doesn't have this option.

[Brian Murray (brian-murray)]

Thanks for taking the time to report this bug and helping to make Ubuntu better. In the development cycle for Intrepid there have been some vast improvements in the open source ati video driver and we could use your help testing them. Could you please download the latest Alpha CD image of Intrepid and test this particular bug just using the Live CD? You can find the latest image at http://www.ubuntu.com/testing . Your testing can help make Ubuntu and the open source ati driver even better! Thanks in advance.

[Bryce Harrington (bryce)]

We're closing this bug since it is has been some time with no response from the original reporter. However, if the issue still exists please feel free to reopen with the requested information. Also, if you could, please test against the latest development version of Ubuntu, since this confirms the bug is one we may be able to pass upstream for help.