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 -) running glxgears and maybe other 3d apps which does not require so much cpu cycles My configuration is -) ubuntu -) Xorg 7.1.1 tweaked through some options, using the "radeon" driver (I've also tested without any options but the problem persists) -) aiglx enabled -) mobility radeon 9700 (maybe r300 chip?) -) mesa 6.5.1~20060817 -) when using compiz/beryl this problem is empathized a lot and the system is very slow. compiz/beryl tells that the problem is not caused by them and it is true because it happens (lower problems as I told) without enabling them.
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.
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.