[r300] Very high CPU usage when refreshing a window

Open and maximeze a firefox window. Then use the scrolling bar. You will see the CPU usage goes to 100% soon.
The same thing happens in the console, when using vim and going up or down with arrows keys.
I'm using the radeon driver with an r300 chip.

To tell the truth even without compiz the cpu usage is very high, but the slowdown is not so visible. So this problem might be related to some other package!

Thank you for your bug report. As generic compiz as now been uploaded to Feisty (compiz-quinn is now known as beryl), we need to see if you are using that or compiz from another source. If you can test the version of compiz in feisty (1:0.3.3-0ubuntu2~git2006112 or later) and tell us if you bug still exists, please do. Please make certain you are using Ubuntu's Xorg as well. We also require the make of your video card, to help debug driver issues. If you are using a newer ATI card (x1000 series or newer), please indicate so. To get this information, please attach /var/log/Xorg.0.log

the bug is affecting compiz 0.3.3-0ubuntu2~git2006112 from the
universe repository. I've also tried compiz-freedesktop 0.3.5 from
other repositories, which have the same problems!
I have everything from ubuntu feisty repository. And I have a radeon
mobility 9700. Of course I'm using the opensource driver.

It is possible that the bug is only caused by the driver, since these
hi cpu usages are detected also without compiz enabled

Hmm, interesting. Can you lock with top to see what exactly is using all the cpu cycles?

I've tries using other programs such as gedit and the cpu goes to max
too! when inserting text and when scrolling fast.

radeon, 24bit color depth tests, compiz:
Xorg ~ 90%
firefox-bin ~ 20%

radeon, 24bit color depth tests, metacity:
Xorg ~ 70 %
firefox-bin ~ 20%

radeon, 16 bit color depth tests, compiz:
Xorg ~ 60%
firefox-bin~ 20%

radeon, 16 bit color depth tests,normal metacity:
Xorg ~ 53%
firefox-bin ~ 20%

vesa, 16 bit, metacity:
Xorg ~ (as smooth as 32bit with compiz enabled)
firefox-bin ~ 1%

This doesn't seem a compiz bug, even if using compiz the slowness gets
higher and higher!
How can I disable direct rendering in radeon driver to test if the
problem is caused by it?

even disabling AIGLX the problem remains... Is this a driver issue? Or
is this the normal behavior of X when it has to refresh the image on
the screen very fast? I will try to use drivers from ati and let you
know the result.

I can confirm this bug: using compiz from the official repositories and either the radeon open source driver or the fglrx driver (each with direct rendering enabled).

Scrolling in Firefox or gnome-terminal uses up waaay too much CPU, and seems to freeze all graphical output on the system. If you have the System Monitor applet enabled while you scroll, you will see that it freezes until you stop scrolling, and then shows very high cpu usage.

Also, there is a new version of compiz released that ought to be in the repos for testing: see http://lists.freedesktop.org/archives/compiz/2006-November/000903.html

Stu: it is strange that this si happening using the fglrx drivers too!
I thought it was a driver issue...

Confirmed that this happens with fglrx and XGL. this is not a compiz issue. Users are reporting that intel cards does not have this problem.
I have to reject this bug in compiz.
I'll leave add it to xorg.

I have the same issue with firefox without compiz (AiGLX enable + radeon driver). The CPU goes to 80-90% but no slow refresh with the internet pages.
With compiz (freedesktop) from repository or build by me i see slow scrolling of pages with firefox, nautilus, gedit and acrobat.

I think is a driver issue or a xorg problem...

Bye,
Luca

It happens even when launching glxgears

Guys, this bug has to be fixed because faisty will be shipped with compiz enabled! This is a hi performance problem! at least we should try to see what happens, after having upgraded mesa and xorg to the latest version!

I think that the problem is caused by the GLX_EXT_texture_from_pixmap extension used by compiz, which is run in indirect mode.

There is no decision made about "feisty will be shipped with compiz enabled", if it's not good enough it'll not be used by default. The bug is not fixed because we don't want to get the bug fixed, there is just lot of bugs and few people working on them, the best you can do to get that fixed is trying to figure what goes wrong and try to figure a patch, or talk to upstream about it

removing NeedInfo, CPU usage questions were answered. I already read recommendations of enabling EXA in xorg.conf but for me it didn't seem to help (but I tested it quickly).

Maybe you could try that option to xorg.conf:
Option "XAANoOffscreenPixmaps" "true"

Unfortunately it does not help. It is still so slow.
Sebastian: I thought it was enabled by default because of the spec
composite-by-default. Sorry.
Upstream answered for a small period but now seems not interested
anymore: they are sure that the poor performance is caused by the lack
of RENDER ACCEL for this driver.

"The lack of RENDER acceleration is quite clearly the bottleneck for scrolling
performance with most apps here. Again though, for EXA you'll definitely need
the xserver exa-damagetrack branch, as otherwise EXA itself is incapable of
accelerating a lot of things properly."

We could try to open a new upstream bug, more specific than the one I opened.

It might be a mesa bug, more than a Xorg bug

new upstream but url

https://bugs.freedesktop.org/show_bug.cgi?id=9676

couldn't be able to set it in launchpad, sorry

About render acceleration, it seems it's already done for ATI R100/R200, and enabled by default.
see
http://xorg.freedesktop.org/archive/X11R6.8.0/doc/RELNOTES2.html

"Render acceleration for ATI's R100 and R200-series cards"

and
http://www.die.net/doc/linux/man/man4/radeon.4.html

Option "RenderAccel" "boolean"
    Enables or disables hardware Render acceleration. This driver does not support component alpha (subpixel) rendering. It is only supported on Radeon series up to and including 9200 (9500/9700 and newer unsupported). The default is to enable Render acceleration.

So it wouldn't be the problem, except for r300 and newer.

Personally I have a r100 (7000/VE). But then again, i'm not really sure my card is fast enough for compiz, even if the drivers were perfect. I think the 9500 should be fast enough though (?).

> I think the 9500 should be fast enough though (?).

ah, misread what i pasted. it's only supported up to and including 9200.

I have a 9700 in my laptop, which is out of subbixel rendering.
Instad my friend has a 9000 (which has 64MB of ram and can run
smoothly neverwhinter nights 1 so it is surely compiz capable!)
The problem is that we both have the same performance issues!

Could it be possible to have a mesa upgrade, to see what happens with the performance?

http://www.redhat.com/archives/fedora-devel-list/2006-September/msg00392.html
An interesting read

About mesa, I am sure we'll have new mesa after Xorg 7.2 is released...

on my radeon 9700 i also suffer from this problem.
scrolling with metacity causes high cpu usage, but speed is still acceptable. however, in compiz or beryl scrolling is incredible slow and laggy which makes them unsuitable for everyday usage.

some days ago i built the latest mesa from git for edgy and scrolling indeed seemed a little bit faster. but as it caused a lot(!) of graphics errors i don't think that this is reliable "information".

maybe mesa git should be tried with xorg git too... Anyway, apart
scolling, I have also problems with
-) scale plugin
-) blur plugin
-) resize

Do you have them too?

Now I've updated to xorg 7.2 using this repository
deb http://users.tkk.fi/~tjaalton/xorg72 feisty xorg-test

the situation is slightly improved now! Im happy! I hope xorg 7.2 can be included in feisty!
Anyway sometimes I have small slowdowns

Nicolo: how is this with current Feisty?

Current feisty updated, no additional video options, only
XaaNoOffscreenPixmaps, compiz from main repository.

the performance is now improved a lot reguarding scrolling, but
definitely it is not metacity-like.
I tried to scroll fastly up/down 5 times, this generates 10 seconds of
lag, 0 in metacity.

Anyway it is still too slow, generally:
scale plugin
maximize/restore
minimize/deminimize

but better than xorg 7.1!

reassigning to compiz, since metacity is ok.

Not a compiz problem.

According to http://www.redhat.com/archives/fedora-devel-list/2006-September/msg00392.html this is in fact a bug in xorg, reopening.

The problem is present also with Nvidia card. I have a 6800GS with 256M of DD3. The scrolling in Firefox use a lot of CPU even without Beryl. I am running KDE. With Beryl the use of CPU almost double and the scrolling slowness becomes visible.

For nvidia you can add the following to xorg.conf and still use beryl, should help a lot:

Section "ServerFlags"
    Option "AIGLX" "off"
EndSection

Note that only nvidia users can do that unless you don't want to use compiz or beryl anymore.

Thanks, I tried but I got only a very modest improvement, almost not perceivable.

Thanks Nicolò Chieffo for suggesting an upgrade to xorg 7.2, I did that I added in all the respositories in the wiki page and did a full update. I also changed EXA to XAA too, now the problem of hi CPU usage is solved, thanks.

is it really gone? in my case definitely not... (mobility 9700)
scrolling and scaling is again very slow in compiz (though better that xorg 7.1)
resizing has been fixed and does no more use CPU

3d apps (including compiz) still use lots of CPU (for example google
earth is not usable at all. 70% of cpu when doing nothing, and very
very slow rendering)

ppracer has surprised me because it works using 50% of cpu but it is
not so sluggish

and I also get errors like this when launching ppracer or google earth
(I have a stock xorg.conf reconfigured with -phigh)

*********************************WARN_ONCE*********************************
File r300_vertexprog.c function valid_dst line 333
Output 3 not used by fragment program
***************************************************************************
*********************************WARN_ONCE*********************************
File radeon_mm.c function radeon_mm_alloc line 216
Ran out of GART memory (for 1048576)!
Please consider adjusting GARTSize option.
***************************************************************************

Sorry, I meant only for 2D apps and with compiz disable (mobility 9000). Are you using the ATI driver or fglrx, I am thinking of using fglrx but couldn't get it to work yet. At least the 2D apps are working fine whereas before it was unusable! Will post again if I get any 3D apps (google earth) working fine.

I'm not using fglrx since it has too much bugs

Thanks, after reading a few article, I don't think I will install fglrx either. I just installed google earth and got it up and running. I guess I'm quite lucky, cpu usage is around 40% - 60% while running. Not sure what is the differences between mine and yours, except I don't have compiz on.

I don't have compiz either! I just did some tests...

could you use it? in my case the fps is around 1 or 2 /second...
which radeon have you got? have you enabled any additional info?
does the program give you the same warning + error that I have?

now I can't even start it (maybe it's because compiz is on?)
*********************************WARN_ONCE*********************************
File r300_render.c function r300Fallback line 428
Software fallback:ctx->Line.SmoothFlag
***************************************************************************
Try R300_SPAN_DISABLE_LOCKING env var if this hangs.
*********************************WARN_ONCE*********************************
File r300_state.c function r300Enable line 512
TODO - double side stencil !
***************************************************************************
*********************************WARN_ONCE*********************************
File radeon_mm.c function radeon_mm_alloc line 216
Ran out of GART memory (for 1048576)!
Please consider adjusting GARTSize option.
***************************************************************************
Error: Could not get dma buffer... exiting

It's running quite smoothly for me without the errors, I'm not sure how I can help but here is my xorg.conf for my ATI Mobility Radeon 9000:

Section "Device"
 Identifier "ATI 9000"
 Driver "ati"
 Option "DRI" "true"
 Option "RenderAccel" "true"
 Option "EnablePageFlip" "true"
 Option "XAANoOffscreenPixmaps"
 Option "AGPMode" "4"
 Option "AccelMethod" "XAA"
 Option "ColorTiling" "on"
 Option "AGPFastWrite" "on"
 BusID "PCI:1:0:0"
EndSection

simple comment: dri, color tiling and xaa are enabled by default. the
nooffscreenpixmaps is no more needed for compiz. fastwrite should be
disabled even if it has been enabled.

Now I will try using these.

also please do a grep -i gart /var/log/Xorg.0.log and paste here

my card (mobility 9700) is not render accel capable. maybe this is the
problem, because even with that options google earth is really too
slow

(**) RADEON(0): Setting up final surfaces
(**) RADEON(0): Initializing Acceleration
(II) RADEON(0): Render acceleration unsupported on Radeon 9500/9700 and newer.
(II) RADEON(0): Render acceleration disabled

this is my Xorg.0.log

(II) RADEON(0): [agp] GART texture map handle = 0xb0302000
(II) RADEON(0): [agp] GART Texture map mapped at 0xb51da000
(II) RADEON(0): Using 8 MB GART aperture
(II) RADEON(0): Using 5 MB for GART textures
(II) RADEON(0): [drm] Initialized kernel GART heap manager, 5111808

all right. I also have 8MB of aperture, but I think that it is too
low... anyone does know if I'm right?
What exactly is "agp aperture"?

i know it's off topic, but the google earth slowdown with r300/r400 and radeon driver is caused by the software fallback for smooth lines.
just run driconf and activate "disable low-impact fallback" and google earth will be fine.

to remain off topic, what is this "disable low-impact"?
effectively it makes google earth more smooth? (not enough smooth
because compiz is enabled I think)

That driconf tweak makes my cpu crash frequently (it is a complete
hang, with no debugging messages) so I disabled it

Since no-one has asked it before, could you attach your xorg.conf and the resulting Xorg.0.log?

my files

I have a dell laptop with an ati rage mobiliry with edgy instaled. Each time I open a window (100% CPU) the mouse pointer freeze a few seconds. It happened with 5.10 too.

Ok, now it should be time to build the git branch of xorg drivers, to test if it is really fixed... How to do it?

Nicolo, here's an explanation of AGP aperture: http://www.techpowerup.com/articles/overclocking/vidcard/43

For building from git, see the link on the bottom of https://wiki.ubuntu.com/XorgOnTheEdge. This wiki page also has links to Ubuntu packages, but I don't think the upstream bug fix is included in the ati 6.6.192 package.

If you still have problems, please file a new bug upstream with logs and details from using latest git.

as I could understand the site you gave me, the AGP aperture size for
my mard, which has 64MB, is 128MB (And not 8, the default xorg uses)
So I added the option
"Option" "GartSize" "128"

shouldn't the amount of gart be detected automatically

I didn't understand if git has the patch applied or not.

What does "dmesg | grep apggart" give?

The upstream patches are applied in git (since 1st of June), but not in the 6.6.192 (=6.7 RC2).

[ 21.640000] Linux agpgart interface v0.102 (c) Dave Jones
[ 21.676000] agpgart: Detected an Intel 855PM Chipset.
[ 21.688000] agpgart: AGP aperture is 256M @ 0xe0000000
[ 33.732000] agpgart: Found an AGP 2.0 compliant device at 0000:00:00.0.
[ 33.732000] agpgart: Putting AGP V2 device at 0000:00:00.0 into 1x mode
[ 33.732000] agpgart: Putting AGP V2 device at 0000:01:00.0 into 1x mode

Xorg.0.log instead says (without the option to have 128MB)
(II) RADEON(0): Using 8 MB GART aperture

I don't really know if this bug could be merged with [Bug 56692] ATI
radeon: poor 3D performance

maybe they are very related, though the hi use of cpu is even when not
using 3d apps. for instance flash animations

Now I enabled the driconf option "disable low impact fallback" and the
performance is acceptable.
What exactly does this option? Why is it not enabled by default?

Can you please try the testgart program? Download testgart.c from http://gitweb.freedesktop.org/?p=mesa/linux-agp-compat.git;a=tree and compile and run it with:
 gcc -o testgart testgart.c
 sudo ./testgart

I looked at the source code and it seems like 8 MB GART aperture is the default on radeon.
See also the discussion here: http://dri.egore911.de/index.php?page=dri-devel-2007-04-03.log

I had to run testgart without X running. this is the result

Using AGPIOC_ACQUIRE
Using AGPIOC_INFO
version: 0.102
bridge id: 0x33408086
agp_mode: 0x1f000217
aper_base: 0xe0000000
aper_size: 256
pg_total: 112384
pg_system: 112384
pg_used: 0
Using AGPIOC_SETUP

Ok, I don't think there's any problem with the aperture size or gart.

The upstream patches involved the xserver and mesa as well as the ati driver, so I guess you need git versions from all of these.

About merging with the other bug, I suggest you keep the 2D issues in this bug report.

all right, so to better clear my ideas what applications can be marked as "2d"?

not google earth, not compiz, not nexuiz
what about smc and gnash, flashplugin-nonfree? can they be considered 2d or 3d?
definitely metacity is 2d.

any others?

Basically those applications for which disabling DRI should not have an impact, I think. Or those which do not load the libGL libraries (use "ldd" to see).

ok, so the only apps that don't depend to libGL are metacity firefox
and flashplugin-nonfree!

I can see slowdows and lots of cpu usage in firefox, when scrolling in
some sites (I will paste the site as soon as I remember which is!),
and in flash when viewing animations [2]

[2] www.asus.com (Stay still in the main page and watch the cpu-meter!)

the bug might be against firefox and flashplugin-nonfree... if it is
please let me know!

http://www.linuxpowertop.org/known.php

in this site scrolling is really slow and huggy.

Again might this be a firefox bug rather than a driver bug? I think it
is a driver bug because normally scrolling in firefox has no issue

Tormod please read this bug report
https://bugs.freedesktop.org/show_bug.cgi?id=4320
Might this bug related to this?

Nicolo, I looked at the upstream bug. Apparently that bug is fixed, except "for the FillTiled case". It would still be interesting if you could try the test program there, big-fill.c. Did you try different accelerations, EXA, XAA, NoAccel?

I pointed at this bug because I have a problem with evince, which is
terribly slow. And the bug assigner told me that the upstream bug that
causes the slowdown is that one!

EXA and NoAccel causes very hi cpu usage even when moving windows.

The following may or may not be related.

I had/have excessive CPU @90% and a hot CPU (65C) when
running an office desktop X-server and use
nxserver to run a home desktop X-session. When I log out of the
office session before going home, this problem does not arise and the temperature stays
down (about 46C)
I have googled a lot and not found an answer (yet) to why X cranks up on CPU.

Anthony

OS is Ubuntu Feisty Fawn 7.04
hardware is:
ASRock Incorporation K7VT6 motherboard
Intel(R) Celeron(R) CPU 2.13GHz
512M DDRAM
Maxtor 2F030L0, ATA DISK drive

This bug is really too messy... I think we should open two separate bugs, one about compiz, and the other about 2D performance...
I will open them

https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/132700
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/132707