(NEED EXA): r100 / r200 / r300: poor compiz performance

[Nicolò Chieffo]

Binary package hint: xserver-xorg-video-ati

xserver-xorg-video-ati 1:6.6.193-1ubuntu1
The performance in compiz 1:0.5.2-0ubuntu3 with an ati mobility radeon 9700 64MB ram is poor:

- the graphical speed is really influenced by the cpu usage
- lots of animations are not fluid

[Nicolò Chieffo (yelo3)]

The performance in compiz with an ati mobility radeon 9700 64MB ram is poor.
- the graphical speed is really influenced by the cpu usage
- most animations are not fluid
- scrolling in all apps is really bad (especially in firefox)

I had to through compiz away :(

my distribution: ubuntu gutsy
my packages:
compiz 0.5.2-0ubuntu3
xserver-xorg-video-ati 6.6.193-1ubuntu1
xserver-xorg 7.2-5ubuntu6
xserver-xorg-core 1.3.0.0.dfsg-6ubuntu3
mesa 7.0.1-1ubuntu1
libdrm2 2.3.0-4ubuntu1

my xorg.conf only includes the option XAANoOffscreenPixmpas, to fix another bug (I've also tried to remove this option but the result is the same)

[Michel-tungstengraphics (michel-tungstengraphics)]

(In reply to comment #0)
> The performance in compiz with an ati mobility radeon 9700 64MB ram is poor.
> - the graphical speed is really influenced by the cpu usage
> - most animations are not fluid

Should be fixed when using mesa 7.0.1, xserver 1.3.99 and xf86-video-ati 6.6.193 or newer with EXA.

> - scrolling in all apps is really bad (especially in firefox)

That's probably not specific to running with compiz but due to RENDER acceleration not having been implemented yet for R300 generation cards.

[Nicolò Chieffo (yelo3)]

I only miss -core 1.3.99, will it be released soon?

[Nicolò Chieffo (yelo3)]

Downstream (ubuntu) is asking for the patches that makes radeon cards usable with compiz, and EXA back to run. Please. if you can find them, they will be included in the upcoming 7.10 release.
I hope you will give us a hand, and locate them.

Thanks

[Nicolò Chieffo (yelo3)]

Upstream said:
fixed in xserver 1.3.99 using EXA for Accel. I hope that patches can
be cackported or someone will do a xserver 1.3.99 deb to test it.

[Airlied-freedesktop (airlied-freedesktop)]

The Fedora rawhide contains a couple of server patches to bring up the 1.3 server to support TFP and news EXA, to avoid bringing in 1.4 server.

[Nicolò Chieffo (yelo3)]

Thanks for the information.
Which fedora version?
Can you guide me to these patches? or at least where all xserver-xorg-core patches are?

[Airlied-freedesktop (airlied-freedesktop)]

I think the ubuntu guys should be able to find them, but the build system RPMS are at

http://koji.fedoraproject.org/koji/buildinfo?buildID=13789

[Nicolò Chieffo (yelo3)]

Ok. I will tell them. whith this, do you say that running fedora 7 (which has this patches included) will eliminate problems with EXA and compiz? if so I will try immediately.
If it is fedora 8 instead of 7, tell me.

[Airlied-freedesktop (airlied-freedesktop)]

It's fedora rawhide which will be 8 eventually, I haven't backported this stuff to F7, but the RPMs can be installed from what I hear..

[Nicolò Chieffo (yelo3)]

I will download fedora 8, and test it, thanks.
Then I will post my results here!

[Nicolò Chieffo (yelo3)]

I had a look at the site. do you think that those 2 are enough? or others should be applied too?
xserver-1.3.0-newglx-offscreen-pixmaps.patch
xserver-1.3.0-exaupgrade.patch

[Airlied-freedesktop (airlied-freedesktop)]

you also need the mesa7 patch and Mesa 7.0.1 to build against..

[Nicolò Chieffo (yelo3)]

ubuntu gutsy already includes mesa 7.0.1, so I think that this patch is included

[Nicolò Chieffo (yelo3)]

Upstream indicated me that fedora has applied to xserver 1.3 the
needed patches, and they can be found somewhere like here
http://koji.fedoraproject.org/koji/buildinfo?buildID=13789

[Linus Mannervik (glitter)]

1.3.99 seems to be available in Debian Experimental: http://packages.debian.org/experimental/x11/xserver-xorg-core
...but only for i386, so I can't really try it out on this ppc machine.

[Michel-tungstengraphics (michel-tungstengraphics)]

(In reply to comment #10)
> xserver-1.3.0-newglx-offscreen-pixmaps.patch
> xserver-1.3.0-exaupgrade.patch

These look unrelated, just xserver-1.3.0-mesa7.patch seems to contain all the needed xserver bits. Then you also need to make sure you have xf86-video-ati commit 975da595f032c145ad74079ff8edeaead779dc7b and build it against the patched xserver. Mesa 7.0.1 already contains all the needed Mesa bits.

[Nicolò Chieffo (yelo3)]

Michel, so if I have mesa 7.0.1 as a package, does this mean that I also have the needed xorg patch?

as for the xf86-video-ati I'm not really sure how to identify the current commit... I only know that the ubuntu version is xserver-xorg-video-ati 6.6.193-1ubuntu1

[Michel-tungstengraphics (michel-tungstengraphics)]

(In reply to comment #14)
> Michel, so if I have mesa 7.0.1 as a package, does this mean that I also have
> the needed xorg patch?

No.

> as for the xf86-video-ati I'm not really sure how to identify the current
> commit... I only know that the ubuntu version is xserver-xorg-video-ati
> 6.6.193-1ubuntu1

6.6.193 has it, but it'll need to be rebuilt against the patched xserver.

[Nicolò Chieffo (yelo3)]

The ubuntu developer which is following this bug gave me this page. Is it possible that you can identify the patch here?
https://wiki.ubuntu.com/X/Fixes_to_Backport

Thanks

[Michel-tungstengraphics (michel-tungstengraphics)]

Don't see it there (outside of my changelog entries), but all the information should be here.

[Nicolò Chieffo (yelo3)]

reporting from upstream:

"(In reply to comment #10)
> xserver-1.3.0-newglx-offscreen-pixmaps.patch
> xserver-1.3.0-exaupgrade.patch

These look unrelated, just xserver-1.3.0-mesa7.patch seems to contain all the
needed xserver bits. Then you also need to make sure you have xf86-video-ati
commit 975da595f032c145ad74079ff8edeaead779dc7b and build it against the
patched xserver. Mesa 7.0.1 already contains all the needed Mesa bits."

[Nicolò Chieffo (yelo3)]

linus, if I want to install this package, I need to download tons of
other packages from debian, about X.org. I will not do it

[Nicolò Chieffo (yelo3)]

I'm sorry to tell you that this isn't fix released yet.
I'm now using fedora 8. I have these package versions:
xorg-x11-drv-ati-6.6.193-2.fc8
xorg-x11-server-Xorg-1.3.0.0-20.fc8
mesa-libGL-7.0.1-3.fc8

EXA is still not usable, because the CPU goes immediately to 100%

[Bryce Harrington (bryce)]

Thanks for the research into this. I'll work on getting these changes in for Gutsy; it will require a UVF exception though. If that doesn't work, we can put them in through the backports process.

What I understand is needed, is the following:

     - Add patch xserver-1.3.0-mesa7.patch to xserver
     - Add commit 975da595f032c145ad74079ff8edeaead779dc7b to xserver-xorg-video-ati
     - Rebuild -ati 6.6.193 against the patched xserver

Let me know if this is incorrect.

[Michel-tungstengraphics (michel-tungstengraphics)]

(In reply to comment #19)
> - Add commit 975da595f032c145ad74079ff8edeaead779dc7b to
> xserver-xorg-video-ati
> - Rebuild -ati 6.6.193 against the patched xserver

Again, the above commit already is in 6.6.193, but otherwise sounds like a plan.

(In reply to comment #18)
> EXA is still not usable, because the CPU goes immediately to 100%

Doing what? Can you verify that the Mesa r300 driver's r300SetTexOffset function gets called, either by attaching gdb to the X server and setting a breakpoint or by adding some debugging output to it?

You probably also want to make sure Option "AccelDFS" is enabled, but I don't think that's critical.

[Nicolò Chieffo (yelo3)]

> Doing what?

Doing anything, just like opening firefox, or moving windows. Only when the screen is *still* (no moving images) the cpu is not used.

> Can you verify that the Mesa r300 driver's r300SetTexOffset
> function gets called, either by attaching gdb to the X server and setting a
> breakpoint or by adding some debugging output to it?

Could you guide me in this steps? I don't know how to do these things
Should I attach Xorg.0.log ?

[Michel-tungstengraphics (michel-tungstengraphics)]

(In reply to comment #21)
> Should I attach Xorg.0.log ?

That won't confirm with certainty it's being used, but it's a start. Hopefully someone else can guide you on one of the methods I mentioned.

[Nicolò Chieffo (yelo3)]

tell me if this is correct:

gdb startx
(gdb) break r300SetTexOffset
(gdb) start

[Michel-tungstengraphics (michel-tungstengraphics)]

(In reply to comment #23)
> gdb startx

No, I usually use something like

sudo gdb -p $(pidof X)

to attach to the running X server. You may need to use Xorg instead of X or just provide the X server's PID manually.

[Bugzi09-fdo-tormod (bugzi09-fdo-tormod)]

Nicolo, see also https://wiki.ubuntu.com/DebuggingXorg for more on Xorg and gdb.

[Nicolò Chieffo (yelo3)]

gdb was stopping at
Attaching to <pid>

I removed fedora and installed debian since in debian experimental there is the package xserver-xorg-core 1.3.99. unfortunately the dependencies are not satisfied yet. I will have to wait

[Airlied-freedesktop (airlied-freedesktop)]

you could have just pulled the rawhide X server + driver + mesa..

[Nicolò Chieffo (yelo3)]

I installed debian to test this package, but there doesn't seem to be
a way to upgrade to "experimental". changing sources.list does not
show any updates and Packages.gz is only 300k...

any suggestion?

[Nicolò Chieffo (yelo3)]

I think that the problem is that xserver-xorg-core 1.3.99 in debian
experimental does not have satisfacted dependancies yet. I will wait

[Michel-tungstengraphics (michel-tungstengraphics)]

(In reply to comment #26)
> gdb was stopping at
> Attaching to <pid>

Note that you can't attach gdb to the X server from its display, as gdb will stop execution of the X server, so you can't interact with gdb... you need to do it from a remote login, e.g. via ssh.

[Nicolò Chieffo (yelo3)]

I did it from the first virtual terminal, and I waited a couple of minutes, pressing some keys, but gdb was not accepting input.
If I went back to the X display everything was blocked, as you told me.

[Tormod Volden (tormodvolden)]

Nicolo, please see https://wiki.ubuntu.com/XorgOnTheEdge for links to new test packages.

https://wiki.ubuntu.com/DebuggingXorg and https://wiki.ubuntu.com/DebuggingProgramCrash explain how to do remote debugging of Xorg.

[Nicolò Chieffo (yelo3)]

I wonder if some ubuntu developer could build xserver-xorg-core and xserver-xorg-video-ati with those patches applied, so I can test them really easier

[Nicolò Chieffo (yelo3)]

Tormod, I have installed xserver-xorg-video-ati 6.7.191 but the
situation is the same.
As upstream says, we need what I reported ad comment # 4
I hope that someone who knows what to do will build it, and add the
package to some webpage so I can test it

[Nicolò Chieffo (yelo3)]

with the option migration heuristic = greedy this is fixed

[Julien Cristau (jcristau)]

(In reply to comment #51)
> with the option migration heuristic = greedy this is fixed
>
no it's not.

[agd5f (agd5f)]

Things may be improved now that r3xx has composite support in EXA. Can those of you having the problems try again with xf86-video-ati from git master?

[Nicolò Chieffo (yelo3)]

In my case it's really fixed with EXA and migrationheuristic=greedy.
But I don't think I have GIT master. I'm running ubuntu hardy

[agd5f (agd5f)]

(In reply to comment #54)
> In my case it's really fixed with EXA and migrationheuristic=greedy.
> But I don't think I have GIT master. I'm running ubuntu hardy
>

migrationheuristic=greedy isn't a fix per se, it just attempts just works around the lack of driver support for EXA composite. You shouldn't need it when the driver provides EXA composite support.

[Nicolò Chieffo (yelo3)]

Let's mark as fix released so.

[Rocko (rockorequin)]

Is it fixed, though? Does the ati driver default to these options now?

[Timo Aaltonen (tjaalton)]

It clearly isn't fixed yet.

[Nicolò Chieffo (yelo3)]

I don't know. can you try?

[Rocko (rockorequin)]

I tried it, and I need to have those lines in my xorg.conf, or the image rendering is slow under compiz.

So the ati driver is not defaulting to these options - it's not fixed, but the workaround works.

[Nicolò Chieffo (yelo3)]

I'm really sorry.

[Peng Deng (d6g)]

I also had performance problem when firefox rendering any GIF animation (even including the loading animation on the tab and upper-right corner of the window).

After enabling EXA, animation doesn't increase CPU load anymore but the compiz's performance slows down a lot, then by adding Option "MigrationHeuristic" "greedy", everything seems much faster :)

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

[Jouni Mettala (jouni-mettala)]

Performance with ati RV350 AP [Radeon 9600] is much better than it was when hardy was released. It was tested with intrepid alpha 4.

[Tormod Volden (tormodvolden)]

EXA is still not default, and is likely to improve performance. Is the Option "MigrationHeuristic" "greedy" still needed?

[Bryce Harrington (bryce)]

Nicolo, we'd also like to hear if you're seeing compiz performance improved with alpha-4

[Martin Emrich (emme)]

I just added the EXA and MigrationHeuristic options on my laptop (T41p with FireGLT2, running current intrepid i386), and the desktop effects are now way faster! Without them, the effects, or e.g. scrolling in firefox, produced quite some CPU load and were slow.

[Tormod Volden (tormodvolden)]

Martin, is MigrationHeuristic still needed?

[Martin Emrich (emme)]

I'll try it out later. Just out of curiosity: What does MigrationHeuristic mean? The man-page does not mention it.

[Tormod Volden (tormodvolden)]

See the upstream bug for Alex' explanation.

[Martin Emrich (emme)]

Back again... I tried it without the MigrationHeuristic=greedy option. I have the impression that it is slower without it, and there's much more CPU load. Then I turned it on again, and e.g. scrolling in firefox is more responsive with it.

I also found this explaination for it:

http://nouveau.freedesktop.org/wiki/MigrationHeuristic

Ciao

Martin

[Tormod Volden (tormodvolden)]

Alex said it should not be needed when EXA has composite support. According to my logs, it has already. Try: grep EXA /var/log/Xorg.0.log

[Martin Emrich (emme)]

I definitely "feel" a difference, especially with firefox, but also in the overall compiz performance. Now for the first time, my desktop not only looks good with compiz, but is also still usable (after all, the laptop has more juice than the first iBooks with MacOS X accelerated GUI *g*)

I get this from my Xorg log:

$ grep EXA /var/log/Xorg.0.log
(**) RADEON(0): Option "AccelMethod" "EXA"
(**) RADEON(0): Using EXA acceleration architecture
(==) RADEON(0): Not using accelerated EXA DownloadFromScreen hook
(II) RADEON(0): Setting EXA maxPitchBytes
(II) EXA(0): Offscreen pixmap area of 56188928 bytes
(II) EXA(0): Driver registered support for the following operations:

[Tormod Volden (tormodvolden)]

Sorry, that grep was not so useful, try this: grep -A6 EXA.*support /media/hardy/var/log/Xorg.0.log

[Bryce Harrington (bryce)]

Tormod, any reason not to include MigrationHeuristic=greedy by default? We found it benefitted -intel during Hardy and caused relatively few problems.

[Tormod Volden (tormodvolden)]

I don't know if it has any negative effect. But why is it not default in the driver? Maybe it would just cover up some bug - from what I understand it should not be needed any longer.

[Bryce Harrington (bryce)]

I don't know, but I had to patch it myself on -intel because it was considered a workaround for the true issue (and thus in that case it would cover up a bug - but at the distro level covering up a bug is a good thing). Just wondering if it's the same situation here.

[Nicolò Chieffo (yelo3)]

My laptop will brake down soon, so I'm not sure if I will be able to
report again on this bug, sorry

[Oibaf (oibaf)]

Hi, just some notes to add:
When using the latest radeon drm module (1.29, included since linux 2.6.26) and a recent version of the -ati driver “MigrationHeuristic” should not be used. See also this post of ati developer Alex Deucher:
http://www.botchco.com/agd5f/?p=28

There is a nice program that could be used to test 2D performance (either with or without compiz):
http://gtkperf.sourceforge.net/index.php?page=download

In hardy with backported mesa, ati and drm I get about 3x performance with EXA rather than XAA with my RV530.

With intrepid alpha 4 I get really bad performance, both with EXA and XAA (I suspect that it was due to a missing patch that fixes a problem with PAT, fixed in 2.6.27). Since intrepid got 2.6.27 this kernel no longer boots on my machine (this is another bug) and can't do testing.

It could be nice to report tests of gtkperf on intrepid alpha5, with or without EXA (and eventually “MigrationHeuristic”) and with or without compiz on different cards to see what is the fastest combination that could be used for intrepid.

[Sergio Zanchetta (primes2h)]

In an updated Intrepid alpha 5, XAA (default) is better than EXA.

I did some tests with/without compiz using XAA/EXA using gtkperf.

I have ATI IGP340M.

Here are the results.

[Sergio Zanchetta (primes2h)]

In addition, 2d performance is better without compiz.

[Oibaf (oibaf)]

Current LiveCD boots again. However EXA/XAA are still slower than in Ubuntu 8.04 with backported drm/ati driver/mesa. EXA is about 2x slower, XAA is 20% slower than 8.04. Part of the problem may be this:
http://lists.freedesktop.org/archives/xorg/2008-September/038540.html (see full thread)
http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=commitdiff;h=b4762c0245ed2966606171cf27f40aa745fdc76e (xorg patch)

[Oibaf (oibaf)]

xserver 1.5.1 with the aforementioned EXA fix was released, so the EXA vs XAA comparisons should be redone with the latest updates (I can't do it ATM).

[Peng Deng (d6g)]

After today's upgrade of the package xserver-xorg-driver-ati to 1:6.9.0+git20081003.f9826a56-0ubuntu2, the compiz performance in EXA mode increases a lot. And the "MigrationHeuristic" option is no longer needed.

[Oibaf (oibaf)]

(In reply to comment #53)
> Things may be improved now that r3xx has composite support in EXA. Can those
> of you having the problems try again with xf86-video-ati from git master?
>

Can EXA be made the default in the driver (when the right DRM module is present) if it is faster than XAA?

[Bryce Harrington (bryce)]

This bug was fixed in the package xserver-xorg-video-ati -
1:6.9.0+git20081003.f9826a56-0ubuntu6

---------------
xserver-xorg-video-ati (1:6.9.0+git20081003.f9826a56-0ubuntu6) jaunty; urgency=low

  * Add 104_use_exa.patch: Switches to EXA acceleration by default.
    + See https://wiki.ubuntu.com/X/Blueprints/RadeonXaaToExa
    + Should close the following bugs (please reopen if not):
      LP: #227936, #269357, 68224 110384 132707

 -- Bryce Harrington <email address hidden> Fri, 19 Dec 2008 19:46:27
-0800

[Oibaf (oibaf)]

Closing, as EXA support should be complete now.