Are Compositing Window Managers Lightweight?
Phoronix: Are Compositing Window Managers Lightweight?
With the recent talk about developing a lightweight KDE desktop, the KWin maintainer, Martin Gräßlin, is talking out to try to clarify whether the compositing window manager is lightweight...
You should make some benchmarks to compare with his claims. (Like kwin being the most efficient and lightweight WM ?)
Until someone actually shows me a compositing window manager that uses less CPU than conventional, I call B.S.
Originally Posted by phoronix
Sure.. in *theory*, if you offload everything to the GPU, that means less CPU. In *practice*, it takes more CPU just to send everything over to the GPU than to just process it.
I read through Martin's previous post a bit and it seems to me that the problem is more that some distributions of the KDE desktop don't work well on some hardware, and a certain problem agreeing on what exactly "KDE" is (other than a community).
Bullshit. The simply action of moving windows takes up next to zero CPU time with GL compositing. Without compositing it can be very CPU consuming, esp. when the window is big.
Originally Posted by droidhacker
Anybody can just open a CPU monitor and check for himself.
Everybody seems to forget that when people look for something "lightweight", their true goal is rarely to "minimize CPU usage" or to "minimize memory usage". CPU and mem usage are just indirect indicators of qualities that are much harder to measure objectively/accurately but are in correlation with CPU and mem: response time and battery time. Responsiveness and longer battery times are the what users really want. The linked article makes a single but fatal flaw, in that it argues that compositing is just a memory/cpu tradeoff, but it forgets that users actually want a more responsive and more power-efficient system and that these do not only depend on the CPU and memory.
I have a long experience in 3D game programming, and here is a fact that I can tell you about. Data transfers between CPU and GPU are bad, coz they are inherently slow. This is the sole reason that in the early days of 3D, screen-space effects (like blurs), environmental mapping (used for reflections and mirrors) and many other effects were used rarely: they were extremely slow because data had to be downloaded from the GPU to CPU and then back to the GPU, which used to be slow.
What does this mean for compositing? Sure, with OpenGL compositing the CPU can sleep more and the GPU can work more power-efficiently on the pixels than the CPU could. But bus transfer times can seriously limit responsiveness on old hardware or crappy drivers, for the same reason that on old hardware such effects killed your FPS from 40 to 5 in games. Coz (and correct me if I'm wrong, I'm not an expert on x11 and internals of GUI toolkits), I'm reasonably sure that GTK and classic Qt render most of their stuff on the CPU. So any time an application changes its window contents, data has to be sent over to the GPU from the CPU, possibly killing your compositing framerate.
I know, I've been talking about older hardware, so does this have any relevance today? It could. For games, said issues have been solved to some extent: data exchange between CPU and GPU is still bad, but games can use such effects more freely now, because 1) graphics buses have gotten faster, 2) GPU hardware and drivers implemented support of making textures out of GPU-rendered frames without having to download them to the CPU first, and 3) games started to use these driver features. For desktop compositing, since most rendering is done on the CPU, such "advanced" driver features cannot be used, which leaves us on the slow side. Not to mention, if your GPU driver falls back to CPU rendering for many things, then compositing is more likely than not a large and negative hit on performance. Otherwise, the effect on responsiveness will depend on the hardware, the quality of the drivers and the rendering mechanisms used by the GUI toolkit. Compositing is likely a win for the battery if your HW/driver is good enough though.
What to take home, IMHO? This long post was merely intended to point out that the "lightweigthedness" of compositing is a much more complex issue than just CPU/memory trade-off, so the original article is very shallow, pointless and I could say even misleading. Compositing could equally slow down or speed up your system based on many factors, and it might not even have anything to do with CPU or memory. So here is what you should do if you are concerned about the question of compositing efficiency on *your* system: Try it out, and if by experience you feel it slows down your system, turn it off. Otherwise, leave it on.
Last edited by ultimA; 05-01-2013 at 05:41 PM.
Assuming that your system is "balanced" between cpu and gpu, compositing is a must; at least this is what i see on a poor atom n270+gma945
/+1 For a very informative post.
Originally Posted by ultimA
People tend to underestimate the price, both in CPU time and (especially) latency attached to bus transfers.
Sure, any modern GPU can run circles around CPU when it comes to shuffling pixels around, however, getting the information to the GPU isn't cheap.
*However*, composite vs. non-composing WM debate is far more complex than what the posts here seem to suggests.
*Alot* is dependent on the GPU HW, bus speed, memory, driver type (binary vs. open) and the screen resolution.
E.g. icewm is noticeably faster than kwin + effects on a QC-AMD+GF212+nVidia-binary+24"HD. However, on my other workstation (2xXeon+GF470+nVidia-binary+27"QHD) the situation is reversed with kwin beating the crap out of icewm.
Now, please notice that I'm not comparing CPU usage but actual (user-perceived) performance / responsiveness.
Last edited by gilboa; 05-02-2013 at 11:08 AM.
Tags for this Thread