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)
(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.
I only miss -core 1.3.99, will it be released soon?
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
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.
Thanks for the information. Which fedora version? Can you guide me to these patches? or at least where all xserver-xorg-core patches are?
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
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.
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..
I will download fedora 8, and test it, thanks. Then I will post my results here!
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
you also need the mesa7 patch and Mesa 7.0.1 to build against..
ubuntu gutsy already includes mesa 7.0.1, so I think that this patch is included
(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.
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
(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.
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
Don't see it there (outside of my changelog entries), but all the information should be here.
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%
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.
(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.
> 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 ?
(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.
tell me if this is correct: gdb startx (gdb) break r300SetTexOffset (gdb) start
(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.
Nicolo, see also https://wiki.ubuntu.com/DebuggingXorg for more on Xorg and gdb.
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
you could have just pulled the rawhide X server + driver + mesa..
(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.
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.
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
> 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 They have! https://wiki.ubuntu.com/XorgOnTheEdge
There are some packages, but not the one mentioned here to fix this issue
I have some more informations Fedora 8 xorg-x11-drv-ati-6.7.192-1.fc8 xorg-x11-server-Xorg-1.3.0.0-22.fc8 mesa-libGL-7.0.1-4.fc8 mesa-libGLU-7.0.1-4.fc8 I ran the debugger through a remote host I was using EXA, but I wasn't running compiz. [lots of output about loading symbols for libraries] (gdb) break r300SetTexOffset break r300SetTexOffset (<- my input line) Function "r300SetTexOffset" not defined.
(In reply to comment #33) > > [lots of output about loading symbols for libraries] > (gdb) break r300SetTexOffset > break r300SetTexOffset (<- my input line) > Function "r300SetTexOffset" not defined. More context please. How did you start gdb? Does the X server log file show it loading r300_dri.so? ...
well, I launched the debugger as you told me... sudo gdb -p $(/sbin/pidof X) there is only this line (II) AIGLX: Loaded and initialized /usr/lib/dri/r300_dri.so is the function r300SetTexOffset introduced with the mesa 7.1 patch? or it is an old function? if it is the first case, the patch may not be applied... And this might explain why EXA is still slow
(In reply to comment #35) > well, I launched the debugger as you told me... > sudo gdb -p $(/sbin/pidof X) What does ps aux | grep X say? > there is only this line > (II) AIGLX: Loaded and initialized /usr/lib/dri/r300_dri.so Can you verify with objdump / strings / whatever that this file contains r300SetTexOffset? > is the function r300SetTexOffset introduced with the mesa 7.1 patch? As I said in comment #10: 'Mesa 7.0.1 already contains all the needed Mesa bits.'
> What does > ps aux | grep X > say? it identifies the X process correctly root 2433 7.5 3.8 27132 19404 tty7 Ss+ 22:33 0:10 /usr/bin/X :0 -br -auth /var/gdm/:0.Xauth -nolisten tcp vt7 > Can you verify with objdump / strings / whatever that this file contains > r300SetTexOffset? strings /usr/lib/dri/r300_dri.so| grep r300SetTexOffset gives no result the only SetTex* are: r300SetTexImages r300SetTexImages r300SetTexWrap > > is the function r300SetTexOffset introduced with the mesa 7.1 patch? > > As I said in comment #10: 'Mesa 7.0.1 already contains all the needed Mesa > bits.' In fact I was wondering if the hadn't been applied!
So it looks like either: * /usr/lib/dri/r300_dri.so is not from mesa-libGL-7.0.1-4.fc8 * The '7.0.1' part of mesa-libGL-7.0.1-4.fc8 is a lie * mesa-libGL-7.0.1-4.fc8 patched r300SetTexOffset out of upstream Mesa 7.0.1
... OK, so I think that Dave Airlie was wrong when told us that fedora rawhide has those patches
What does rpm -qf /usr/lib/dri/r300_dri.so say?
mesa-libGL-7.0.1-4.fc8 might it be that the rpm was corrupted? is there a way to force the re-download and re-installation of this package through yum?
I might try with debian sid. now it has xorg-xore 1.4.0-2, but only ati 6.6.193-3 the latest comment on changelog is: * Grab several upstream fixes from the ati-6.7-branch up to commit 84a37d0ed01a2eee80ee30b79ddfd7906decaff1. * Build against Xserver 2:1.4-1. should I try with it?
FWIW, Debian also has 1:6.7.194-1 in experimental. unstable contains the HEAD of ati-6.7-branch from a couple weeks ago.
I'm in ubuntu now, and I installed xserver-xorg-core-1.4-1 from debian unstable and xserver-xorg-video-ati-6.7.194-1 from experimental the issues are still here and the same: - performance depends from cpu usage - scrolling is really slow even without cpu usage (maybe because scrolling highers cpu usage)
(In reply to comment #44) > I'm in ubuntu now, and I installed xserver-xorg-core-1.4-1 from debian unstable > and xserver-xorg-video-ati-6.7.194-1 from experimental I assume you have libgl1-mesa-dri >= 7.0.1 as well. Please attach your current Xorg.0.log file.
Created attachment 11874 [details] Xorg.0.log 1.4 the performance with XAA is the same. with EXA instead, as I previously told you, opening/moving/scrolling a window will cause the cpu to go to 100% instantly, so the cpu is constantly stressed
(In reply to comment #46) > with EXA instead, as I previously told you, opening/moving/scrolling a window > will cause the cpu to go to 100% instantly, so the cpu is constantly stressed I'm not seeing that on a pretty similar setup, so please provide more detailed information about specific cases and profiles from sysprof or oprofile. BTW, does Option "AccelDFS" help at all?
how do I make these profiles? AccelDFS does not help.
This bug can be closed : As far as I can tell, on Debian Unstable, with experimental 6.7.193 ati driver, compiz works like a charm : 10% of CPU for compiz, the same for Xorg process when wobblying windows, on a AMD 3200+ @ 1000MHz (it doesn't even puts up cpu frequency). Packages from this source : deb http://download.tuxfamily.org/shames/debian-sid/desktopfx/unstable/ ./ Version: compiz-core 1:0.5.5+git20071019 ATI X300 PCI-e with 64 MB 1600x1200@24bpp Xorg interesting options : Option "AccelMethod" "EXA" Option "EnablePageFlip" "true" Option "ColorTiling" "1" Option "GARTsize" "64" Virtual 2048 1536
Bugzilla Upgrade Mass Bug Change NEEDSINFO state was removed in Bugzilla 3.x, reopening any bugs previously listed as NEEDSINFO. - benjsc fd.o Wrangler
with the option migration heuristic = greedy this is fixed
(In reply to comment #51) > with the option migration heuristic = greedy this is fixed > no it's not.
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?
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
(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.
(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?
Closing, as EXA support should be complete now.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.