How Unity, Compiz, GNOME Shell & KWin Affect Performance

[sabriah]

My nVidia GeForce GTX260 is doing very very fine on KDE 4.6.x. If I would need to, I could switch to LXDE, and remain cool.

Nice test, BTW!!!

[gedgon]

These results just can't be right. Uncomposited Metacity is the slowest one? It's ridiculous.



Mutter and Metacity comes from GNOME 3.0.2, KWin form KDE SC 4.6.80.

Hardware: C2D E4500, GTX 275 / 270.41.19

[damg]

Why would you wish run Blender at more fps than your monitor can handle?

I don't. Your question assumes that Blender can always generate more FPS than the monitor can handle.

[damg]

currently, and if you want to output more frames than your display can actually render, then yes. there's nothing implicitly wrong in the architecture or the implementation, though - and using the refresh rate of the monitor is always the right choice to avoid burning through your GPU and battery life. so it's going to require some work, but it's going to get fixed.

You're right, it does make sense to sync to vblank if you can consistently generate more FPS than your monitor refresh rate; but at this point I was referring to most games which are struggling to produce those 60 FPS in the first place; the vblank waiting is causing an extra hit in FPS.

It sounds like this extension that Carmack talked about might be useful; anyone know what that is?

[rewind]

And referring to the tests that's why I'm stuck at gnome-shell in forced fallback mode and with compiz running. It's not only games, it's HD videos and flash also. Not always less frames per sec., but sluggish and choppy motion with mutter. That's with the latest catalyst.
I think the best way to avoid such problems /with display manager/ is to start every fullscreen application like games in new x-server display.

[BlackStar]

So essentially, gnome-shell in its current form is a step backwards for Linux gaming (and other fullscreen OpenGL apps like Blender)?

Why would you wish run Blender at more fps than your monitor can handle?

[ebassi]

So essentially, gnome-shell in its current form is a step backwards for Linux gaming (and other fullscreen OpenGL apps like Blender)?

currently, and if you want to output more frames than your display can actually render, then yes. there's nothing implicitly wrong in the architecture or the implementation, though - and using the refresh rate of the monitor is always the right choice to avoid burning through your GPU and battery life. so it's going to require some work, but it's going to get fixed.

[damg]

gnome-shell/mutter, unlike the other compositing window manager tested here, is vblank-locked to 60 fps.

also, gnome-shell/mutter does not unredirect fullscreen applications - meaning it'll still composite fullscreen apps like games.

these two issues combined explain a huge chunk of the drop in fps.

So essentially, gnome-shell in its current form is a step backwards for Linux gaming (and other fullscreen OpenGL apps like Blender)?

[ebassi]

wrong "benchmark"

gnome-shell/mutter, unlike the other compositing window manager tested here, is vblank-locked to 60 fps.

also, gnome-shell/mutter does not unredirect fullscreen applications - meaning it'll still composite fullscreen apps like games.

these two issues combined explain a huge chunk of the drop in fps.

[mirv]

I'm curious how E17 would go here as well, with massive disclaimers that while the EFL has just had another bugfix release, E17 itself is still "in the works". Going the whole hog with an E16 comparison too would be good.