Bug 239963 - Significant CPU penalty for using Kwin effects.
Summary: Significant CPU penalty for using Kwin effects.
Status: RESOLVED NOT A BUG
Alias: None
Product: kwin
Classification: Plasma
Component: compositing (show other bugs)
Version: unspecified
Platform: Arch Linux Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-05-29 12:58 UTC by Alexander
Modified: 2010-06-13 22:15 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander 2010-05-29 12:58:06 UTC
Version:           unspecified (using KDE 4.4.3) 
OS:                Linux

When watching a movie through VLC, it uses CPU on 5%. But Kwin in this time uses CPU on 7% and X on 5%. Even if I watching 1080p videos Kwin still using CPU on 7%, but X already on 20%. Or when I watching youtube, again Kwin using CPU, but at this time it is 9%. I understand, this may seem ridiculous for some, but I do not think so. When compositing is halted Kwin does not use CPU at all, and X using it at 2-3%.

Vertical syncing is disabled, opengl mode: textures from pixmaps.

Reproducible: Always




Qt 4.6.2
KDE 4.4.3
Arch Linux (x86-64), AMD 3500+ (2.3), nvidia 9500gt (proprietary driver)
Comment 1 Martin Flöser 2010-05-29 13:29:37 UTC
Please see the following blog post by a Compiz developer for an explanation for the CPU penalty: http://smspillaz.wordpress.com/2010/05/21/beware-the-benchmarks/
Comment 2 Alexander 2010-05-29 17:39:06 UTC
All this is very interesting and in theory all sound good. Everyone always trying to find easy ways, but in practice we have a lot of lags and errors, and I do not think Kwin has already reached perfection there. But almost everywhere, where I had posted a bug report, devs are trying to convince me that it seemed to me :)

When Kwin and X load CPU at least twice as much more than VLC, this does not looks like a "semi-significant overhead". And, for some unknown reason, the author of the article forgot to mention bugs, which were made during the writing.

> Our recommendation: Use nouveau.
Haha :) Too early for that, in my opinion.
Comment 3 Thomas Lübking 2010-05-29 19:09:30 UTC
a) An overhead on the current OpenGL compositing renderstack is unavoidable. period. try using xrender.
(the trick is to pass it to the gpu)

b) arbitrary measures using top make bad benchmarks as it's not possible to say what causes your issues... use sysprof to profile the offending processes (x11 & kwin)

c) tried compiz? if it's not significantly faster (it's not for me) that would be a hint that you're running into system restrictions.

d) personal experience (nvidia 7600gt, 195.36.15, arch)
-> i do not suffer from similar X11 cpu load at all.
extrapolating to your system it'd be ~4% for 1050p, xrender or opengl doesn't matter. kwin ~3% on opengl, "nothing" on render (just playing, nothing else)

but:
- i use the 32bit variant and
- i don't use the glib event dispatcher (put "export QT_NO_GLIB=1" into your ~/.xprofile) - haven't tried glib for ages. and
- to gain these values, you must NOT use any indirect rendering. whether by setting or the use of a shader plugin (sharpen, inversion, blurring)
otherwise the driver -as smart as possible- can not bypass the expensive theoretical stuff mentioned in the blog ;-)
using indirect rendering, my performance drops significantly (but is still not as bad as your experience)
Comment 4 Alexander 2010-05-29 21:44:41 UTC
It's amazing, dude! I've just put this string "export QT_NO_GLIB=1" into my /etc/profile, and Kwin really does not use CPU so hard any more. 5% — It is maximum on how much I was able to load it, I just can't believe it :) Thanks.
Comment 5 Martin Flöser 2010-06-10 21:11:25 UTC
Given comment #4 I think we can set this bug to invalid. I really have to try this option ;-)
Comment 6 Alexander 2010-06-11 06:39:40 UTC
I do not know what is the glib event dispatcher and how important is its role, but think, you should be use "export QT_NO_GLIB=1" (and/or perhaps another tricks you know) by default. I am certainly happy now, but others could still have this CPU penalty. Simply put, not all pay attention to some miserable 5-10%.

Regards and good luck.
Comment 7 Fredrik Höglund 2010-06-13 22:15:35 UTC
SVN commit 1137645 by fredrik:

Disable the glib event loop integration, since it seems to be responsible
for several bug reports about high CPU usage.

CCBUG: 239963


 M  +4 -0      main.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1137645