Bug 9400

First of all, please attch (as opposed to paste) full X config and log files.

(In reply to comment #0)
> the xorg process uses very hi cpu percentage (checked through 'top') in this
cases:
> -) scrolling up and down (especially using the scroll bar)
> -) moving the cursor in vim

It would be interesting to know which application(s) the scrolling is slow with,
but my guess (based on experience) would be this is mostly due to the lack of
RENDER acceleration for the R300 family.

> -) running glxgears and maybe other 3d apps which does not require so much cpu
> cycles

Have you verified that these are using direct rendering?


> -) when using compiz/beryl this problem is empathized a lot and the system is
> very slow.

That's because several things involved with a GLX compositing manager are
implemented far from optimally yet:

* GLX_EXT_texture_from_pixmap basically uses XGetImage to read the pixmap
contents and glTexSubImage to update the texture contents. Ideally, the 3D
driver should texture from the pixmap data directly. There's some infrastructure
work to be done before that can be achieved.
* The r300 3D driver has to upload the whole texture after every glTex(Sub)Image
call, even if only a single pixel changed. This could be improved by using the
TTM for managing texture memory.

I don't know if it is the same issue, but I noticed that compiz/beryl
performances (glxgears results as well, for what it matters) are influenced by
the CPU usage (i.e. compiling software) when Page Flipping is disabled. With
Page Flipping enabled the difference is unnoticeable.

Scrolling instead is very slow with EXA and acceptable with XAA, probably
because EXA render acceleration is not supported with R3xx/R4xx cards.

Using an "ATI Technologies Inc RV370 [Sapphire X550 Silent]"

Created attachment 8182 [details]
xorg.conf

Created attachment 8183 [details]
Xorg.0.log

I'm using EXA with some tweaks such as PageFlip. But I've tested it using XAA
too! I will post the results soon. And I'm using 16 bit of color depth which
improves the performance a lot, so imagine how it could be normally at 24 bit...

I've tried to scroll in
-) gedit
-) vim
-) firefox
-) rhythmbox
-) gaim
-) tomboy
using the mouse wheel:the result is always Xorg at 60% of cpu usage.
When using PgUp/PgDown keys the usage is near 25%.

I don't know how to verify it bug I think that glxgears (which uses 55% of cpu,
and xorg is in normal cpu usage ~5%) is using direct rendering.

does the new mesa driver add some improvements? why is Render acceleration not
available for r300 chips? oh and by the way I have to add that this problem is
also present in radeon 9000 mobility, in my friend's laptop.

I didn't notice any difference in scrolling using EXA or XAA. they are both too
slow, even when not using compiz.

I've done ad additional test which makes me think that there is something
strange. I tested it using fglrx.
The scrolling result is the same! Instead glxgear uses near 2% of cpu.

I don't really know what's happening

(In reply to comment #5)
> I'm using EXA [...]

The patch from bug 6929 may help for EXA performance, as may tweaking Option
"MigrationHeuristic".

> I don't know how to verify it 

glxinfo | grep render

> bug I think that glxgears (which uses 55% of cpu,
> and xorg is in normal cpu usage ~5%) is using direct rendering.

I'm afraid you're putting too much emphasis on CPU usage. The CPU can't be idle
when there's work to do...

> does the new mesa driver add some improvements? 

I'm not aware of significant performance improvements recently.

> why is Render acceleration not available for r300 chips? 

Because nobody has implemented it.

> oh and by the way I have to add that this problem is
> also present in radeon 9000 mobility, in my friend's laptop.

Which aspect(s) of 'this problem' exactly? You've brought up a lot of more or
less unrelated issues. :)

> I didn't notice any difference in scrolling using EXA or XAA. they are both too
> slow, even when not using compiz.

Are you still using another compositing manager in that case, or none?

I am not using any compositing window manager.
When I wrot "that problem" I meant that when scrolling the cpu is totally
blocked. I've put much emphasis to the cpu because I don't think that it is not
normal that when I scroll the cpu is eating more than 50%. I might be wrong but
this creates lots of lag.

The only problem that I want to point out is the slowdown when I scroll (both
when using a compositing wm and not), caused by hi cpu usage. The slowdown as
told before, is present when using radeon (and also fglrx). NVIDIA and INTEL
users are reporting no cpu usage when scrolling. Michel, which video card have
you got?

Do you think I should open another bug report for glxgears? or the 100% of cpu
usage is definitely caused by the lack of RENDER acceleration? (fglrx uses near
0% so this is definitely not normal)

I forgot to answer that yes, I'm in direct rendering.

(In reply to comment #9)
> The only problem that I want to point out is the slowdown when I scroll (both
> when using a compositing wm and not), caused by hi cpu usage. The slowdown as
> told before, is present when using radeon (and also fglrx). NVIDIA and INTEL
> users are reporting no cpu usage when scrolling. Michel, which video card have
> you got?

(--) RADEON(0): Chipset: "ATI Radeon Mobility 9600/9700 (M10/M11) NP (AGP)"
(ChipID = 0x4e50)

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.


> Do you think I should open another bug report for glxgears? or the 100% of cpu
> usage is definitely caused by the lack of RENDER acceleration? 

(The lack of) RENDER acceleration only affects the X server, not 3D apps.

> (fglrx uses near 0% so this is definitely not normal)

fglrx uses intermittent sleeps; this has generated some complaints of its own
because glxgears no longer gives quite insane framerates on some machines... You
might be able to achieve a similar effect by setting the driconf setting
fthrottle_mode to 1 ('Performance' => 'Method to limit rendering latency' =>
'Sleep for brief intervals while waiting for the graphics hardware' in the
driconf GUI).

PS: glxgears is not a benchmark nor particularly useful otherwise, anyway. Are
you having the same issue with useful 3D apps?

PPS: You could try profiling with sysprof or oprofile to see where the cycles
are spent.

You seem to have my same radeon model! so for sure you can test that xorg eats
cpu even when using vim (vim /etc/X11/xorg.conf and maximize the window. keep
the down arrow pressed. you will see immediately that the cpu is used with
another window running "top" in front of the vim terminal)

Ok so if I'm not wrong since the lack of RENDER is the bottleneck, this must
imply that both fglrx and the radeon driver for r_200 cards does not support it,
while nvidia proprietary driver and intel driver support it. Am I wrong? 

Ok. I think I've understood that EXA is not so stable, so I will go back to
normal XAA.

You were right. the cpu usage is now very low, although the gears are sometime
choppy. Are you trying to tell me that the video card does not emit enough
interrupts, so the cpu is busy to wait for them?

the only app that I've been using is nexuiz, a quake-like game. but it's very
very heavy! Do I have to do some tests with it? Or could I do some tests using
compiz?

I am definitely not a "profiling" expert. could you give me some advice?

I've tested nexuiz. I'm stopped at the main menu->options, without doing nothing
at all. The cpu usage is near 80% (45 by Xorg and 35 by nexuiz) this using the
"sleep for brief intervals..." and the same using the normal "wait for
interrupts". Is this ok?

P.S. What options should I enable/disable? for now I have these:
Option "XAANoOffscreenPixmaps" "on" #to make compiz work
Option "AGPMode" "4"
Option "AGPFastWrite" "off" #the system hangs
Option "EnablePageFlip" "on"
Option "ColorTiling" "on"
Option "GARTSize" "64"

(In reply to comment #11)
> You seem to have my same radeon model! so for sure you can test that xorg eats
> cpu even when using vim [...]

Sure, I can't live without gkrellm. ;) I just know why CPU usage goes up in that
case and don't think it's unreasonable given the circumstances.

> Ok so if I'm not wrong since the lack of RENDER is the bottleneck, this must
> imply that both fglrx and the radeon driver for r_200 cards does not support it,
> while nvidia proprietary driver and intel driver support it.

Correct for fglrx and nvidia, but not the others. Intel chipsets tend to be
affected less by the lack of acceleration due to the shared memory architecture.
If there's really no difference with an R200 card, then maybe you're using
sub-pixel anti-aliasing, which XAA can't accelerate (although recent versions of
EXA can). Try disabling that or maybe even using a bitmap font.

> Are you trying to tell me that the video card does not emit enough
> interrupts, so the cpu is busy to wait for them?

It's possible that the r300 driver uses busy loops in some cases where it could
use interrupts or sleeps. Feel free to file another bug for that if there isn't
one yet.


(In reply to comment #12)
> Option "XAANoOffscreenPixmaps" "on" #to make compiz work

This disables most 2D acceleration with XAA, so you should not enable it when
you're not using compiz.

could you better explain why it is normal? I don't really understand the
circumstances! Thank you! Any suggestion about oprofile?

I don't know anything about sub-pixel acceleration. how do I disable it?

Ok, so I will file another bug as soon as I can!

(In reply to comment #14)
> could you better explain why it is normal? I don't really understand the
> circumstances!

Without acceleration, the CPU has to render every single pixel. With a discrete
graphics card, this involves moving data back and forth across AGP/PCI(e), which
is relatively slow.

Note that this may also be partly an application issue. E.g. the GNOME terminal
has traditionally been known not to be too efficient wrt screen updates.

> I don't know anything about sub-pixel acceleration. how do I disable it?

E.g. in the GNOME font preferences (it's called 'Subpixel smoothing' there), or
in the fontconfig configuration in /etc/fonts/.

Ok michel! I've understood that without this "RENDER" acceleration the situation
can't be different like it is now...

So let's hope it will be made available soon... is there any roadmap or
something similar? Can you obtain some more help from the ATI developers, now
after the transition to AMD?

regarding the use of compiz now, with this driver, I can say that it is quite
usable only in 16bit color mode (in 24 bit it is so slow!), except that
scrolling is very choppy as told before (the fan will always start!). The blur
effect instead (maybe available only in beryl) completely blocks the cpu when
you move a window( this is not true when using fglrx) and so it is unusable. Is
it possible to do any improvement? or again the situation will remain blocked
until the release of RENDER accel?

I tryed to use sysprof. With compiz enabled, FC6, r300 driver, and simple
scrolling up and down in firefox - cpu was on 100%. In sysprof most of time 58%
was spend in r300TexSubImage2D.
Inside r300TexSubImage2D
   _mesa_texstore_rgba8888 7.94
       _mesa_unpack_color_span_chan 10.96
           _mesa_apply_rgba_transfer_ops 23.73
           _extract_float_rgba 15.67

Michael what do you think it can be this high slowdown in some operations, when
using a composite window manager?

-) scroll
-) open/close windows
-) blur

Happy new Year!!

Peter could you tell me how to work with sysprof, that I'd like to do some more
tests?

Michael please, I want to ask you another thing. Since when using compiz the
performance is slow (even when there is an animated gif to render, the cpu is
hold at 10% of usage) I wanted to ask you if this debug message might hint
something useful:

libGL warning: 3D driver claims to not support visual 0x4b
compiz.real: GLX_EXT_texture_from_pixmap is not supported by direct rendering
context, trying indirect rendering context instead

in fact GLX_EXT_texture_from_pixmap is not present in glxinfo "GLX extensions"
while it is present in cliend and server side.