[RV100] very poor Xorg performance on various older graphics HW - XAA no longer works

Radeon Mobility M7 LW [Radeon Mobility 7500] has same slowdown.

Scrolling in OpenOffice.org and LyX is almost impossible, and let's xorg use 99% cpu.
Also playing flash-videos is sluggish.

Changing to XAA acceleration solves this. (Approx. same performance as Intrepid)

Radeon r100-rv200 should use XAA accelration. EXA is a big regression!

Switching back to XAA acceleration on my ThinkPad X32 seems to give me the performance as seen in Hardy.

Section "Device"
 Identifier "Configured Video Device"
 Option "RenderAccel" "on"
 Option "AccelMethod" "XAA"
 Option "AGPMode" "4"
EndSection

eMachines m6809 laptop with ATI Radeon Mobility 9600
Has very poor video performance under Intrepid / Jaunty, very poor (stuttering/choppy) flash playback in full screen - nearly un-usable.

Adding the folling option greatly increase performance under Jaunty:

Option "AccelDFS" "on"
Option "AccelMethod" "XAA"
Option "MigrationHeuristic" "smart" # "greedy" works well also
Option "EnablePageFlip" "on"
Option "EnableDepthMoves" "on"
Option "ColorTiling" "on"
Option "FBTexPercent" "0"
Option "RenderAccel" "on"

Performance is still not quite as good Hardy with ATI's closed drivers, but much better than Jaunty or Intrepid defaults.

Adding those options to xorg.conf increases performance on my laptop using Jaunty, now. Its not as good as when I was using the catalyst drivers with Hardy, but its good enough to watch flash movies without the screen tearing.

On Hardy I was getting 1000+ fps in glxgears, but with Jaunty and the above changes to xorg.conf I get about 310.

Xorg with XAA acceleration method in Jaunty is still slower than in Hardy. I tested two very simple benchmarks:

Open a Gnome Terminal, and run "top".

1. Moving window: Move the Gnome Terminal window, and watch the CPU usage of the Xorg process.
2. Test scrolling: Open another Gnome Terminal, and type the following command:
   $ while : ; do dmesg; done

In both cases, Xorg consumes about 50% of CPU cycles in Jaunty, and 25% in Hardy.

crjackson's solutions works fine with me, even using EXA works well.

hello,

can you read my bug report ( Bug #365886 ) to see if your probleme is the same (i think that mine is duplicate). I have mostly the problem with firefox and the gnome-system-monitor can you confirm that?
thanks
jb

I also notice this 2 bugs whitch could be related Bug #366299 Bug #366224

Had the same problem with my old ATI M6 LY (as the original poster), see http://ubuntuforums.org/showthread.php?t=1108844 . Today I upgraded my PC at work, and got the same poor performance with a Radeon 9200 Pro. Switching to XAA also brought back the performance I was used to in Intrepid.

Is there any way to detect whether an ATI card works better with EXA or XAA (besides trying)?

Thinkpad X31 User. Fix seems to work for me as well.

Changing from EXA to XAA fixes the problem for:

IBM R40 2722 GDG with ATI Technologies Inc Radeon Mobility M7 LW [Radeon Mobility 7500] rev 0

I'm also a ThinkPad X31 user (Radeon Mobility M6 LY). EXA performance is horrible compared to XAA. XAA should be the default for this card.

Bug confirmed on IBM Thinkpad T41 / ATI RV250. Fixed by changing to XAA as suggested by Wenzhuo Zhang's 2009-04-19 xorg.conf change.

crjackson's options really improved things for me. ATI Radeon Mobility 9600. Had been using the fglrx drivers under Intrepid, but support was dropped by ATI in their xserver 1.6 compatible drivers, so I am using the open source drivers now. I had been contemplating downgrading back to Intrepid, or worse downgrading just xserver to 1.5, but this saved me from that insanity, thank you crjackson!

confirming problem of Jaunty xorg eating up way too many CPU cycles and making the system generally sluggish. I also confirm the XAA fix.

Furthermore, I did experience screen artifacts and corruption as reported by some other people here. I hope that maybe they'll be gone, too.

I'll send a bug report upstream and include a link here in a minute.

Forget the most important information. My computer is a Thinkpad X24.

01:00.0 VGA compatible controller [0300]: ATI Technologies Inc Radeon Mobility M6 LY [1002:4c59]
 Subsystem: IBM Device [1014:0239]
 Flags: bus master, stepping, fast Back2Back, 66MHz, medium devsel, latency 66, IRQ 11
 Memory at e0000000 (32-bit, prefetchable) [size=128M]
 I/O ports at 2000 [size=256]
 Memory at c0100000 (32-bit, non-prefetchable) [size=64K]
 [virtual] Expansion ROM at c0120000 [disabled] [size=128K]
 Capabilities: <access denied>
 Kernel modules: radeonfb

Solution works for me too. My System is a Dell Latitude D600.

01:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV250 [Mobility FireGL 9000] (rev 01)
        Subsystem: Dell Device 011d
        Flags: bus master, VGA palette snoop, stepping, 66MHz, medium devsel, latency 32, IRQ 11
        Memory at e8000000 (32-bit, prefetchable) [size=128M]
        I/O ports at c000 [size=256]
        Memory at fcff0000 (32-bit, non-prefetchable) [size=64K]
        [virtual] Expansion ROM at fc000000 [disabled] [size=128K]
        Capabilities: <access denied>
        Kernel modules: radeonfb

I'm just wondering if using a much older Acceleration Method can be a solution for good...

I'm I the only person on the planet using ubuntu that experiences changing of performance? After using the pc for anytime from 1 hours to 6 hours, when performance is generally sluggish on flash video and firefox scrolling, out of nowhere performance just explodes and everything starts working great. I tried to have a look at various logs but nothing really stands out as to reveal what happens.

I tried the recommended xorg.conf configuration on an ATI Mobility Radoen 9700 running radeon driver, lspci describes as:

01:00.0 VGA compatible controller: ATI Technologies Inc RV350 [Mobility Radeon 9600 M10]

And saw no visible increase in performance. Xorg.0.log reveals this weird sequence though:

(**) RADEON(0): Option "AccelMethod" "XAA"
(**) RADEON(0): Using XAA acceleration architecture
(II) RADEON(0): XAA Render acceleration unsupported on Radeon 9500/9700 and newer. Please use EXA instead.
(II) RADEON(0): Using XFree86 Acceleration Architecture (XAA)

I guess the XAA parameter passes, it's in use, but... maybe it's not?

No one with the same graphics card/chipset (300s series) sees this on the log?

On Wed, May 13, 2009 at 23:33, JorgeAzevedo <email address hidden> wrote:
> I'm I the only person on the planet using ubuntu that experiences
> changing of performance?

Hopefully not.. :)

> After using the pc for anytime from 1 hours to
> 6 hours, when performance is generally sluggish on flash video and
> firefox scrolling, out of nowhere performance just explodes and
> everything starts working great.

Interesting. I will try this, with XAA things are still not that crash
hot. Things "seem" slower than in Intrepid but it is hard to gauge.
oocalc for one still seems slow.

> 01:00.0 VGA compatible controller: ATI Technologies Inc RV350 [Mobility
> Radeon 9600 M10]

Seems we are identical (Mine is a T42 Thinkpad running the internal
15" LCD + 27" LCD via DVI on a docking station).

01:00.0 VGA compatible controller: ATI Technologies Inc RV350
[Mobility Radeon 9600 M10]

> No one with the same graphics card/chipset (300s series) sees this on
> the log?

I see this also:

 636 (II) RADEON(0): Direct rendering enabled
 637 (II) RADEON(0): XAA Render acceleration unsupported on Radeon
9500/9700 and newer. Please use EXA instead.
 638 (II) RADEON(0): Render acceleration disabled

But didn't think much of it. Perhaps there is more to this than
originally thought. I will go back to EXA and wait a few hours
instead of getting impatient. I am very interested in your exact
config so that I can try to replicate what you are getting.

--
Andrew Janke
(<email address hidden> || http://a.janke.googlepages.com/)
Canberra->Australia +61 (402) 700 883

Andrew Janke,

Than for the interest man, I've been experiencing this for ages. Didn't happen to me in intrepid, only in hardy and now in Jaunty.
Strangely enough, I now can tell that performance has boosted by listening to to the fan. It jumps to maximum speed and sticks there. Maybe the GPU has some kind of frequency scaling?

What info do you need for my "exact config"? I didn't do anything, I'm running Jaunty installed via wubi and the default config just worked like this. I will happily provide any logs, outputs or config files, but I really don't know which ones.

It's weird your xorg.log gives a different output since we have the same graphics card. I'm not an expert, but if your one says that you have render acceleration is disabled, your performance should be notebly afected?

Can people who experience this problem please try to enable DRI?

1) Add 'Load "glx" ' and 'Load "dri" ' to your Modules section of xorg.conf
2) Add "Mode 0666" to a section DRI which you may have to create
3) restart X

http://dri.freedesktop.org/wiki/DriTroubleshooting

The problem should be gone now without resorting to XAA, according to upstream

http://bugs.freedesktop.org/show_bug.cgi?id=21611

Upstream has also suggested a patch to "use XAA in low memory situations or when the DRI is disabled". Unfortunately, it does apply cleanly to Jaunty source or I would have prepared a package for testing in my PPA. I tried adapting the patch to the Jaunty source, but it is beyond my skills. Can one of the xserver packagers please take a look?

of course, "it does *not* apply cleanly"

Rolf Leggewie, I just tried your suggestion by adding the following to xorg.conf:

  Section "Module"
   Load "glx"
 Load "dri"
  EndSection

  Section "DRI"
 Mode 0666
  EndSection

It doesn't help. Xorg log (see attachment) shows that glx and dri are enabled by default:

(II) "glx" will be loaded. This was enabled by default and also specified in the config file.
(II) "dri" will be loaded. This was enabled by default and also specified in the config file.

The upstream fix seems to work for me. I see the same information that Wenzhuo Zhang is seeing in xorg log about glx and dri being enabled by default, but video performance is dramatically improved over default and still noticeably improved over XAA.

If I try those lines I get the same messages as Wenzhuo Zhang ... but in addition, it looks like either with or without the lines, I'm apparently no longer getting dri at all. glxinfo tells me:
OpenGL renderer string: Software Rasterizer
whereas in intrepid it said:
OpenGL renderer string: Mesa DRI R200 20060602 AGP 8x x86/MMX+/3DNow!+/SSE2 TCL
And googleearth tells me "You are currently running Google Earing in 'OpenGL' with software emulation." which it doesn't do in intrepid. That's with the AccelMethod and DRI lines commented out of the Device section of xorg.conf.

Also tried it. With the default screen size of 1024x768 (notebook TFT panel) it's still nothing near the XAA speed. When switching to dual-screen resolution 2304x1024, some options (like ColorTiling) get disabled according to Xorg.log because the card can't handle it at this resolution. And performance gets even worse.

So for me, XAA is still the best way to go. (ATI Technologies Inc Radeon Mobility M6 LY)

With the Load glx, Load dri and Mode 0666 lines in xorg.conf I still get crashes (even though I don't seem to be getting hardware opengl any more), so it doesn't solve the problem for me.

@Rolf, note that loading the glx module explicitly doesn't do anything for recent X.org versions (it's autoloaded and so is "dri" module). Further, the permissions on the dri device node are also no longer in use because that device now has an ACL on it (so the "Mode 0666" stuff is obsolete). If you do "ls -l /dev/dri/card0" you will notice that the permissions have a small "+" char next to it, that indicates the presence of an ACL. You can see the ACL using the command "getfacl /dev/dri/card0".

Nice job with finding that patch btw. We usually never commit patches into Ubuntu before they are accepted by upstream though, so it would be useful if you first made sure that the upstream git versions has the bug fixed, then we can cherry pick patches for Ubuntu.

This bug affects me too!

How can I try the upstream solution? (Without compiling anything, that is...)

Currently my Mobile 9000 (RV250) causes a CPU load of about 25% and very sluggish behavior under 9.04 (8.10 was fine). But I can resize Konsole nearly smoothly.
Forcing the system to XAA it's useable again - but not perferect: resizing Konsole looks like giving me only 1 frame/second.

BTW: using EXA I also had DRI running (as far as I can tell).

Having a rotten graphics system is really bad for me, so please help me to get an acceptable solution!

Everyone with 32MB memory, please continue to use EXA but add this to /etc/X11/xorg.conf under Section "Device":
Option "FBTexPercent" "0"

At least for my Mobility 9000 EXA is completely fine with that. It pushes the texture memory to system and frees as much memory as possible for EXA.

If you have eg. only 16MB memory on the gfx card, you may try to be wild and try, in addition to FBTexPercent, this:
Option "DepthBits" "16"

It halves the memory usage for depth buffer, causing problems in some 3D applications but giving even more memory to EXA. Don't know if it's enough with 16MB RAM but it might be just enough together with FBTexPercent 0 to have EXA working also on those. If you have 32MB you might want to experiment it as well, if you find something that is still slow after setting FBTexPercent.

@Timo Jyrinki:
Thank you! Your solutions seems to work fine at my setup.
Added Option "FBTexPercent" "0" to my xorg.conf.

Maybe it is slightly faster than XAA!? Not sure yet!

@Timo Jyrinki:
On my Mobility M6 LY (16MB), EXA with both of your optimizations is still slower than XAA. Using EXA, showing the selection list of "Gnome Do" (down arrow) is presented in 3 hard steps whereas using XAA it is smoothly animated. Same goes for expanding the playlist in VLC player.

could anyone who has a IBM X31 paste his/her xorg.conf?

I have the very same problem on Thinkpad T42, changing xorg.conf improves the situation, but still non as good as it used to be in intrepid or hardy.

lspci | grep VGA:

01:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV250 [Mobility FireGL 9000] (rev 02)

Ups, my laptop is a T41, not a T42. Sorry. I bought it quite a while ago and do not remember anymore ;-)

I believe the pain is self-inflicted in Ubuntu. The responsible patch is 104_use_exa.patch. I hope that upstream will help us out of this with a proper patch that selects EXA by default but drops back to XAA in low-memory situations.

Stay tuned.

BTW, if there is anybody who can write proper code, can you pleaes take a look at http://bugs.freedesktop.org/attachment.cgi?id=26476 (104_use_exa.patch) and make it work more like http://bugs.freedesktop.org/attachment.cgi?id=25890 ?

Here is a debdiff against Karmic with a patch provided by Alex Deucher (actually I rebased the problematic 104 patch against the one from Alex). I have recompiled this package for Jaunty in my PPA. Please test and report. Remember to uncomment any lines forcing XAA in xorg.conf.

https://launchpad.net/~r0lf/+archive

Come on people, if you don't test and give feedback, we are not going to get this bug fixed in Jaunty.

Unfortunately, this patch does not fix the situation for me. Going back to XAA in xorg.conf.

@Rolf: I can't test as my question above ("How can I try the upstream solution? (Without compiling anything, that is...)") wasn't answered...

By the way, my system has dedicated 64 MB VRAM for the Mobility Radeon 9000... So I doubt that's a low memory situation.

Chris wrote:
> @Rolf: I can't test as my question above ("How can I try the upstream
> solution? (Without compiling anything, that is...)") wasn't answered...
>

It was answered, you just didn't read carefully enough ;-) I'm pretty
sure I added a link to my PPA somewhere in this bug report.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

I've tried the PPA driver now.

Without XAA the Xorg task uses constantly 10 - 50% of the CPU (a few
applications are open, but in the background; in the foreground only a
Konsole with top is running).

With XAA the Xorg taks stays under 5% (same setup)

:(

I didn't try Option "FBTexPercent" "0" so far.
OpenGL is also broken.

If it matters: my system has a Mobility Radeon 9000 with 64 MB VRAM:

01:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV250
[Mobility FireGL 9000] (rev 01)
        Subsystem: Acer Incorporated [ALI] Device 001f

        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping+ SERR+ FastB2B+ DisINTx-
        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 66 (2000ns min), Cache Line Size: 32 bytes

        Interrupt: pin A routed to IRQ 10

        Region 0: Memory at d8000000 (32-bit, prefetchable) [size=128M]

        Region 1: I/O ports at 3000 [size=256]

        Region 2: Memory at d0100000 (32-bit, non-prefetchable)
[size=64K]
        [virtual] Expansion ROM at d0120000 [disabled] [size=128K]

        Capabilities: <access denied>

        Kernel modules: radeonfb
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEAREIAAYFAkpXgeMACgkQoWM1JLkHou1WxgCggmJqJHcxY+GfDla8rkV/sUKu
cm8AnA9q2tXxWIbpb5qUvlK9XgxivZ28
=iVDY
-----END PGP SIGNATURE-----

I just installed the PPA version again and had a closer look. With and
without XAA my Xorg defaults to VESA?!?

I think you're better off asking someone on the forum. I am just a novice
user.

On Fri, Jul 17, 2009 at 11:22 AM, Chris <email address hidden> wrote:

> I just installed the PPA version again and had a closer look. With and
> without XAA my Xorg defaults to VESA?!?
>
>
> ** Attachment added: "Xorg.0.log"
> http://launchpadlibrarian.net/29194672/Xorg.0.log
>
> --
> very poor Xorg performance on various older graphics HW - XAA solves this
> https://bugs.launchpad.net/bugs/363238
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in X.org XServer - ATI gfx chipset driver: Confirmed
> Status in “xserver-xorg-video-ati” package in Ubuntu: Triaged
>
> Bug description:
> Binary package hint: xserver-xorg-video-radeon
>
> Just installed Jaunty RC on my ThinkPad X32. I am experiencing very poor
> Xorg performance. The Xorg process consumes about 25% CPU even when there is
> no user activity. If there is any screen activity, say moving the
> Gnome-terminal window, its CPU usage instantly climbs to 80% or more.
>
> Affected cards:
> 01:00.0 VGA compatible controller [0300]: ATI Technologies Inc Radeon
> Mobility M6 LY [1002:4c59]
> Subsystem: IBM Device [1014:052f]
>
> 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility M7
> LW [Radeon Mobility 7500]
> Subsystem: IBM Device 0530
>
> 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV250
> [Mobility FireGL 9000] (rev 01)
> Subsystem: Dell Device 011d
>

edintzis wrote:
> I think you're better off asking someone on the forum. I am just a novice
> user.
>

Nonsense!

It depends on what one wants to achieve. Bugs are fixed in LP. I'm
sure there is good support to get things running in the forum. But
there is good information in this ticket as well on how to alleviate the
effect of this bug.

As I already said here, the patch unfortunately is not a proper fix.
We're still looking for that. With the XAA workaround, the pressure is
somewhat off, though ;-)

> I just installed the PPA version again and had a closer look. With and
> without XAA my Xorg defaults to VESA?!?

The latest xserver-xorg seems to not recognize this card anymore. To force it to use the ati driver, add the line

  Driver "ati"

to the Section "Device" in your /etc/X11/xorg.conf .

Markus Birth wrote:
> The latest xserver-xorg [...]

Please always specify what version exactly you are using. "Latest"
means nothing, it could be latest Ubuntu (which has several releases of
its own), latest Debian (again, several releases) or latest upstream
(trunk and I assume a bunch of releases, too). So, please specify what
version exactly you are using, because otherwise any information added
is close to useless.

FWIW, I think I've always had the ati driver specified explicitly in
xorg.conf, so I did not see any changes.

Rolf Leggewie schrieb:
> Please always specify what version exactly you are using.

My attached Xorg.0.log a few posts above
(https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/363238/comments/51)
was with your current, latest driver out of your ppa.

BTW: currently I'm using the latest official ubuntu driver again ("the
old dirver") with Option "FBTexPercent" "0" (and, just to be sure,
Virtual 1400 1050).
This leads to EXA rendering with acceptable performance (Xorg stays
usually between 5 and 15% CPU; Compiz is working). But OpenGL is still
broken.

104_use_exa.patch has been dropped from the Karmic package

I'm glad I found this thread. I'm having the same problem, with a wrinkle: I'm getting "OpenGL renderer string: Software Rasterizer" from glxinfo no matter what I do, even though my Xorg.0.log seems to indicate that DRI is loading fine--at least I don't see any obvious errors.

Changing from EXA to XAA helped a lot, but I still can run my CPU up to 100% in 40 seconds running just glxgears, the LXDE desktop, and one terminal window.

I'm on a Radeon Mobility M6 LY and a custom-built kernel from Ubuntu source. Hardware is a Sharp PC MM 20 with Transmeta Efficeon processor.

I've attached my Xorg.0.log with details, if anyone would care to have a look. My xorg.conf is in the following post.

I figured out my issue with getting software rasterization -- it was the permissions on the device. Based on this bug report here:

http://bugs.freedesktop.org/show_bug.cgi?id=19492

I tried both "glxinfo" and "sudo glxinfo" and noted that in the former case I got software rasterization, while in the latter case I was getting "Mesa DRI Radeon..." As recommended in that bug report I set the permissions on /dev/dri/card0 to 0666 and am now getting Mesa DRI when I'm not the root user as well. Now EXA acceleration seems to be working quite well.

Martin Olsson wrote:

> @Rolf, note that loading the glx module explicitly doesn't do anything for recent X.org
> versions (it's autoloaded and so is "dri" module). Further, the permissions on the dri
> device node are also no longer in use because that device now has an ACL on it (so the
> "Mode 0666" stuff is obsolete). If you do "ls -l /dev/dri/card0" you will notice that the
> permissions have a small "+" char next to it, that indicates the presence of an ACL.
> You can see the ACL using the command "getfacl /dev/dri/card0".

Interestingly, the permissions on the dri device node apparently still do have some relevance; at least they made a big difference in my case. Is there perhaps a bug lurking here?

from the upstream bug:

--- Comment #42 from Alex Deucher <email address hidden> 2009-08-01 13:57:48 PST ---
committed:
f564460e94c9d0f1cf3ff4b8535481b2b8b4e9c1

http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=f564460e94c9d0f1cf3ff4b8535481b2b8b4e9c1

This bug was fixed in the package xserver-xorg-video-ati - 1:6.12.99+git20090629.f39cafc5-0ubuntu6

---------------
xserver-xorg-video-ati (1:6.12.99+git20090629.f39cafc5-0ubuntu6) karmic; urgency=low

  * Add 111_use_xaa_for_lowmem_or_nodri.patch: Default to XAA in low
    memory situations or when the DRI is disabled. Fixes very poor Xorg
    performance on older graphics hardware.
    (LP: #363238)

 -- Bryce Harrington <email address hidden> Mon, 17 Aug 2009 09:37:36 -0700

Thank you for pushing that patch into Karmic. FWIW, the performance of the karmic driver is this abyssmal when compared to the Jaunty version. I went back to my patched jaunty driver.

Also my Ati radeon 9600pro , 128Mb, is affected.

i have the package xserver-xorg-video-ati - 1:6.12.99+git20090929.7968e1fb-0ubuntu1 and the bug isn't fixed.

the XAA workaround solve this.

see: http://doc.ubuntu-fr.org/radeon#bug

my config: P4 2.4Ghz, 1Go RAM, Radeon 9000 (rv250), xubuntu 9.10, free radeon driver of course.

i have the package xserver-xorg-video-ati - 1:6.12.99+git20090929.7968e1fb-0ubuntu1 and the bug isn't fixed.

the XAA workaround solve this.

see: http://doc.ubuntu-fr.org/radeon#bug

my config: P4 2.4Ghz, 1Go RAM, Radeon 9000 (rv250), xubuntu 9.10, free radeon driver of course.

> Launchpad Janitor wrote on 2009-08-17: #63
>
> This bug was fixed in the package xserver-xorg-video-ati - 1:6.12.99+git20090629.f39cafc5-0ubuntu6
>
> ---------------
> xserver-xorg-video-ati (1:6.12.99+git20090629.f39cafc5-0ubuntu6) karmic; urgency=low
>
> * Add 111_use_xaa_for_lowmem_or_nodri.patch: Default to XAA in low
> memory situations or when the DRI is disabled. Fixes very poor Xorg
> performance on older graphics hardware.
> (LP: #363238)
>
> -- Bryce Harrington <email address hidden> Mon, 17 Aug 2009 09:37:36 -0700

Did anyone test performance with KMS enabled?

why only RV100? My RV350 is still working much better with XAA than EXA.

Please, change again that summary

Il 22/03/2010 03:22, Robert Hooker ha scritto:
> ** Summary changed:
>
> - very poor Xorg performance on various older graphics HW - XAA solves this
> + [RV100] very poor Xorg performance on various older graphics HW - XAA solves this
>
>

If you're seeing the same symptoms but with different hardware, and can reproduce the problem on Lucid please file a NEW bug, don't reopen this one.

It seems that XAA can no longer be enabled in Lucid, and the problem is still reproducible: Open Gnome-Terminal, run "top", and then keep moving the Gnome-Terminal window, the cpu usage of Xorg instantly climbs to 80% or more. So the problem has not been fixed yet.

Although the cpu usage of Xorg is still high, I feel that the performance is better than in Jaunty.

Thanks for letting us know the issue is resolved.

Ahem, Bryce, I think you need to read more carefully. Wengzhuo *explicitly* stated that the issue is *not* resolved. Reopening.

Alright, well look - first this already has been sent upstream and is marked fixed there. So this is a lame duck bug report. Second, this is a bug against really old hardware, which is not really much of a priority for us. Third, it's a performance issue, which while important is not something we generally do a lot of work on at the distro level except in macro terms.

I am closing the bug as wont fix because I think whatever needs done here needs to be done upstream. Normally I would help you by sending the bug upstream, but since this already has an upstream task that is closed, that is no longer possible. If you are willing to file a NEW bug, we might still help out. But otherwise I think it's best we close this bug and encourage you to go upstream directly to get their assistance for this hardware.

Hi all,
I just went through all the posts here but I experience another problem:
with XAA I get seriously corrupted graphics in some applications. Especially in adobe acrobat the scrollbars are just garbage and the pop up messages from the network manager are just random dots.
With EXA the rendering is fine but performance is poor as mentioned here in the forum.

Karmic
01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility M6 LY
X.Org X Server 1.6.4
Release Date: 2009-9-27
X Protocol Version 11, Revision 0
Build Operating System: Linux 2.6.24-23-server i686 Ubuntu
Current Operating System: Linux bp1-laptop 2.6.31-21-generic #59-Ubuntu SMP Wed Mar 24 07:28:56 UTC 2010 i686

a follow up: DRI was disabled because of not enough memory available. I increased the video memory and things got worse. Both XAA and EXA gave corrupted output.

a second follow up. With DRI it just won't work. Here are my setting which give reasonable speed and no garbage on the screen:

Section "Device"
        Identifier "Configured Video Device"
        Driver "radeon"
        Option "AGPMode" "4"
        VideoRam 65536
        Option "AccelMethod" "EXA"
        Option "MigrationHeuristic" "greedy"
        Option "AGPSize" "64"
        Option "DRI" "off"
EndSection

Hi,
I'm testing Radeon 7000VE (RV100) on Lucid 10.4 and I got this issue, moving to XAA didn't help...
For the momet I set the xorg option as suggested by arbeitstier in comment #78 and is better.

can't complain under Lucid. It works out of the box with my Radeon Mobility M6 LY. It's still a bit slow but then it's not the fastest laptop I've got with 1.2GHz clock.

There are a couple of options which are now ignored under Lucid. For me this works best:

Section "Device"
        Identifier "Configured Video Device"
        Driver "radeon"
        VideoRam 65536
        Option "AccelMethod" "EXA"
EndSection

Just to add informations :
This problem was present in karmic, upgrading to lucid didn't change anything and I tried to manually compile the last stable radeon drivers (xf86-video-ati-6.13.0) and it still doesn't solve the problem.

So, at least for my board :
$ sudo lspci | grep VGA
01:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV100 QY [Radeon 7000/VE]

with no xorg config file (wich means using EXA acceleration) and using a poor performance CPU, Xorg operations are sluggish, CPU usage is high (sometimes stucked at 100%).

I've tried all proposed solutions presented here, disabled all possible "bling bling" effects in gnome/kde and hardly got a few spare CPU cycles.
I'm unable to switch to XAA for a test has it seams to be disabled in recent drivers (log files show it doesn't care about my Option "AccelMethod" "XAA" and still talks about using EXA)
I'll have a try at finding an old driver version if XAA is still able to be activated with recent xorg version

Funny note for the end : It is so sluggish with EXA "acceleration", that I choose to just disable acceleration
(Option "NoAccel" "Yes")
This gives me better 2D performances, with the drawback of disabling OpenGL wich I need to renable with 2 xorg.conf files whether I want GL or not.
Maybe I'll have a try with the vesa driver ? :-)

Dô, I forgot :

This bug here :
https://bugs.launchpad.net/ubuntu/+source/sun-java6/+bug/250931

Really really looks a duplicate of this one, it's just that it's even easier to spot it with java applications than qt/gtk ones.

Also there is a good test case in it (bad-linux-java.tgz) wich should expose the problem to anyone affected by the bug.
You'll probably get 1 or 2 FPS with the bug while it's very smooth without the bug, Try with or withou t(Option "NoAccel" "Yes") acceleration to see the difference

@sly

I have not upgraded to lucid yet, but did you try with and without KMS enabled? (radeon.modeset=0 as bootparam)

I didn't know such a thing existed.

So I tried to add (blindly) radeon.modeset=0 to my kernel boot options, and strange things happens ;-)

- I had a bug during the boot process screen resolution that is now corrected
- My X display is corrupted, resolution is good but a green flavour color is added all over the screen
- GL is disabled,

Diff between Xorg logs about KMS shows :
with radeon.modeset=0 :
(II) [KMS] drm report modesetting isn't supported.
[drm] failed to load kernel module "radeon"
(EE) RADEON(0): [dri] RADEONDRIGetVersion failed to open the DRM
[dri] Disabling DRI.

without :
(II) [KMS] Kernel modesetting enabled.
(II) RADEON(0): KMS Color Tiling: disabled

i had this bug with xubuntu 9.10, with Radeon 9000 (rv250).
the XAA workaround solved it.

now i did a new install of xubuntu 10.04. and it seems this bug is gone.

my config: P4 2.4Ghz, 1Go RAM, Radeon 9000 (rv250), xubuntu 10.04 (free radeon driver).

This bug
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/444139
looks connected with ours. Is it a duplicate?