Bug 248729 - enabling desktop effects results in high CPU usage with ati catalyst drivers
Summary: enabling desktop effects results in high CPU usage with ati catalyst drivers
Status: RESOLVED WORKSFORME
Alias: None
Product: kwin
Classification: Plasma
Component: general (show other bugs)
Version: unspecified
Platform: openSUSE Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords: investigated, triaged
Depends on:
Blocks:
 
Reported: 2010-08-22 21:58 UTC by Vadym Krevs
Modified: 2018-10-21 05:05 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Vadym Krevs 2010-08-22 21:58:33 UTC
Version:           unspecified (using KDE 4.4.4) 
OS:                Linux

openSUSE 11.3 for x86_64 on Dell Inspiron 1737 with ATI Radeon HD 3650, and ATI Catalyst 10.7 drivers, latest KDE 4.4.4 from openSUSE build service.

With disabled "Desktop Effects", Xorg consumes 3-5% of CPU when the system is idle. 

If I enable "Desktop Effects" in Desktop->Desktop Effects (having previously checked "Disable functionality checks", then the Xorg process constantly consumes ~20-25% of CPU when the system is idle. Also, if a video is played in one window, then dragging any other window causes video playback to freeze.




Reproducible: Always



Expected Results:  
Idle system with desktop effects enabled consumes significantly less CPU.
Comment 1 Martin Flöser 2010-08-22 22:07:09 UTC
Is there a specific reason why you use the proprietary Ati drivers? In general 
the free radeon driver renders much better results.

Your description sounds like a driver bug. KWin cannot be responsible for high 
CPU usage of X server. Such issues have to be reported to X developers. We are 
not responsible for the bugs we find in other components ;-)
Comment 2 Thomas Lübking 2010-08-22 22:29:23 UTC
see if som effect causes this. in case SuSE backported it, start by disabling blurring.
Next should be stupid things like "snow" and with some settigns wobbly windows can go forever :-)

Also use the "show paint" plugin to check whether large areas of the desktop constantly repaint (high X11 load ca defer from texture_from_pixmap conversion - no: shared memory or failsafe will unlikely be an improvement :-)

Notice that ths fps counter causes high CPU load by design in either X11 or kwin (what's actually depending on the driver implementation and whether you're using XRender or OpenGL as backend)
Comment 3 Martin Flöser 2010-08-22 22:40:44 UTC
> in case SuSE backported it,
> start by disabling blurring.
No they didn't. They ship a default set of effects in 11.3. That's why there 
should not be any performance problems ;-)
Comment 4 Vadym Krevs 2010-08-22 23:42:54 UTC
(In reply to comment #1)
> Is there a specific reason why you use the proprietary Ati drivers? In general 
> the free radeon driver renders much better results.
> 
> Your description sounds like a driver bug. KWin cannot be responsible for high 
> CPU usage of X server. Such issues have to be reported to X developers. We are 
> not responsible for the bugs we find in other components ;-)

Prior to the upgrade to 11.3, my notebook had 11.2 with the proprietary ATI driver. The upgrade to 11.3 did enable the open source radeon driver with KMS, and I tried it for several days. Desktop effects were enabled, and operated without any noticeable glitches. 

Unfortunately, the notebook's fan would stay on all the time (which was never the case with the ATI driver and 11.2), and installing the ATI driver on 11.3 fixed the fan problem immediately. That was one reason for switching to the binary driver.

The other problem was that the X11 + the radeon driver incorrectly auto-detected the DPI setting of the notebook's screen, and I had failed to force Xorg/KDM/etc to use the right DPI setting. The proprietary ATI driver had no such issue under 11.2 nor under 11.3.
Comment 5 Vadym Krevs 2010-08-24 12:54:11 UTC
Interesting - if I login into Gnome with Compiz enabled, then all desktop effects work just fine and Xorg's CPU usage is very low. So if compiz can achieve what it does using existing binary drivers, why cannot Kwin do the same?
Comment 6 Thomas Lübking 2010-08-24 15:18:00 UTC
-> comment #2
Just that the Desktop might _appear_ idle (in your opinion...) does not mean it is

To figure out what causes cpu load for you, you'll have to bisect things (but just the fact that Xorg takes 3-5% of the CPU w/o compositing is a great hint that the system is certainly NOT idle, XOrg is usually ~0.0 (yes: zip) w/o major interaction / screen updates, playing a FS movie on the desktop layer causes ~5% on even an AthlonXP 1800 - and i guess you use sth. stronger than this...)

Sysload in an entirely different environment with pot. other applications up unfortunately add no intel to this issue at all, sorry.
Comment 7 Vadym Krevs 2010-08-24 15:51:27 UTC
Ok, let's not nitpick. "idle" for me means a KDE session, konsole with 10 tabs, chrome with 15 tabs, kontact minimized to systray, all forms of indexing turned off, and no keyboard/mouse input from me. According to top, the 3 processes consuming most CPU are Xorg (3-5%), plasma-desktop (2-4%) and npviewer.bin (0-1%). This is my definition of an "idle" system and personally I find that CPU usage acceptable. The notebooks' fan is quiet, etc.

A similar (granted not an identical) set of applications under Gnome (with compiz!) results in comparable CPU usage in "idle" mode.

However, enabling desktop effects under KDE dramatically increases Xorg's CPU load in "idle" mode, and that's what this issue is about.

I see you've changed the status to NEEDSINFO. Can you explain what information are you expecting me to provide. If you've already mentioned it above, please let me know the comment # and I'll re-read it again, and will provide you with the relevant information.
Comment 8 Thomas Lübking 2010-08-24 18:27:06 UTC
constant cpu load in plasma & xorg (w/o compositing) sounds like it's constantly updating, try "kquitapp plasma-desktop" and recheck composited GPU load, also invoke the show paint plugin to identify high frequent update regions (the pixmap -> texture conversion is expensive and w/o direct rendering this load applies to X11)

the required info is mentione in comment #2 and is
a) whether a particular plugin causes this
b) whether constant screen updates (an animated wallpaper would eg. be an obvious one) might cause this
Comment 9 Martin Flöser 2010-08-26 21:00:44 UTC
most likely constant repainting is causing this problem. Which would also explain the bad performance for free drivers (fan on). Waiting for info....
Comment 10 Kirk Baucom 2010-10-26 16:04:21 UTC
I also experienced this problem. In my case, show paint indicated that a small rectangular area that was not related to anything on the screen was constantly being redrawn. It turned out that this was a progress bar in a krdc session on another desktop (specifically, a Perforce p4v screen in Windows). It only produced high CPU usage on desktops that had a lot application windows open. Once I got rid of the progress bar, usage dropped back to 1-2%, even on the busy desktops that were showing 40-60% usage previously.

Linux darwin 2.6.35-22-generic #34-Ubuntu SMP Sun Oct 10 09:26:05 UTC 2010 x86_64 GNU/Linux

01:00.0 VGA compatible controller: ATI Technologies Inc RV610 [Radeon HD 2400 XT]
Comment 11 Thomas Lübking 2010-10-26 16:30:08 UTC
@kirk
setting "keep window thumbnails" to "never" in the advanced tab of "kcmshell4 kwincompositing" would prevent windows on other desktops to update.

@OP vadym
answer to comment #9 is still pending
Comment 12 Andrew Crouthamel 2018-09-20 22:10:18 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information.

For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 13 Andrew Crouthamel 2018-10-21 05:05:29 UTC
This bug has been in NEEDSINFO status with no change for at least
30 days. The bug is now closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!