In the KDE Plasma Workspaces 4.7 we introduce new Compositing backends/modes in our Compositor. Lately I noticed that there is some misunderstanding on what are the differences between the modes, why we wrote new code and what is the best mode for whom (at least one distribution did it wrong in their first packaging approach). With this blog post I hope to shed light on the various modes.
OpenGL 2.x/GLX
This is our default compositing backend. It uses only the so-called programmable pipeline or also known as the “core” profile. For rendering we use only shaders written in the OpenGL Shading Language (GLSL) without making use of any fixed-functionality emulation code. For the interaction with the underlying graphics system we use GLX and the extensions for compositing. Namely the texture from pixmap extension to get an OpenGL texture from an XPixmap (the window content). As the code matches the core profile it would be easy to add “support” for OpenGL 3 or 4, just in case someone is wondering. But as we do not make use of anything provided by OpenGL 3, there is no need for this.
OpenGL 1.x/GLX
This is our legacy backend and the code we only had in 4.6 and before. The code uses only fixed functionality. Up to 4.6 it was possible to also use Shaders written in GLSL. This is no longer possible. Effects requering shaders may provide a shader using the ARB Shader extension which can be used only in this mode. The code to access the underlying graphics system is shared with the OpenGL 2.x backend.
The legacy backend is used automatically for all drivers not supporting at least OpenGL 2.0 and the fglrx driver. Furthermore there is an option to enforce this mode in the Advanced Desktop Effect settings: uncheck option “Use OpenGL 2 Shaders”.
OpenGL ES 2.0/EGL
This is the backend for the future. It’s primary target are mobile devices (Plasma Active), but also on the desktop it is very important as it is the requirement for supporting Wayland. Like OpenGL 2.x it uses the programmable pipeline and shaders written in GLSL. In fact the OpenGL ES 2.0 and OpenGL 2.x backend are identical to more than ~ 95 %. The difference is in the way how to access the underlying graphics system. Instead of GLX we use EGL and the EGL_KHR_image_pixmap to bind an XPixmap (window content) to an OpenGL texture.
In opposite to the other two OpenGL backends this one is not a runtime option, but a compile time option. OpenGL ES 2.0 is (mostly) a subset of OpenGL 2.0 without the legacy code. So the old code would simply not compile against the libraries and that’s why it is a compile time option. To enable use the CMake flag “KWIN_BUILD_WITH_OPENGLES”. Be aware that EGL is not supported by all drivers. To my knowledge only the Gallium radeon and nouveau drivers support it at the moment. This means especially for distributions: don’t use the build flag for the default package, but provide an additional one. For the next release cycle I hope to make it a runtime option.
XRender
XRender is a completely different backend. It can be selected in the advanced Desktop Effect settings in the dropdown “Compositing type”. Furthermore it is used as a fallback when the OpenGL backend fails in an expected way (e.g. Software Rasterizer). The XRender backend can only provide 2D animations, so e.g. no Cube effect. Performance on the backend depends on the driver, but can be rather fair (I once did not notice that the XRender backend was used in a virtual machine).
No Compositing
Not really a backend, but also a mode which has to be mentioned. KWin also supports no compositing at all. This mode can be entered at all time by the Shortcut Alt+Shift+F12 and in the General Desktop Effects settings through option “Enable desktop effects at startup”. Also at runtime self checks may disable compositing and also applications can block compositing bringing KWin into this mode. The Composited mode can be re-enabled through the same shortcut.
How To Notice which one is Used?
This can be quite tricky, because KWin automatically falls back to a different backend if one fails. E.g. if OpenGL 2 is not available OpenGL 1 is used. Or if OpenGL fails, KWin might fall back to XRender. KWin does nowhere log which backend is really used, but there are some messages printed to stdout which can help recognizing the version. KWin always prints out the used OpenGL version information. This looks for OpenGL like this:
OpenGL vendor string: Advanced Micro Devices, Inc. OpenGL renderer string: Mesa DRI R600 (RV710 954F) 20090101 TCL DRI2 OpenGL version string: 2.1 Mesa 7.10.2 OpenGL shading language version string: 1.20 Driver: R600C GPU class: R700 OpenGL version: 2.1 GLSL version: 1.20 Mesa version: 7.10.2 X server version: 1.10.1 Linux kernel version: 2.6.38 Direct rendering: yes Requires strict binding: no GLSL shaders: yes Texture NPOT support: yes
And for OpenGL ES:
OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD RV710 OpenGL version string: OpenGL ES 2.0 Mesa 7.10.2 OpenGL shading language version string: OpenGL ES GLSL ES 1.0.16 Driver: R600G GPU class: R700 OpenGL version: 2.0 GLSL version: 1.0.16 Mesa version: 7.10.2 X server version: 1.10.1 Linux kernel version: 2.6.38 Direct rendering: yes Requires strict binding: yes GLSL shaders: yes Texture NPOT support: yesTo distinguish OpenGL 1 from OpenGL 2 backend there is one debug message related to "KWin::ShaderManager::initShaders". There should be three messages for valid - then OpenGL 2 is used or at least one message on failure, then OpenGL 1 is used. Recognizing XRender is even more difficult. In case that we face issues for debugging we will add more precise debug messages. Personally I test which backend is used by using functionality tests: the Cube Effect requires at least OpenGL and the Sphere and Cylinder effects require at least OpenGL 2.
Why a new Backend?
There are several reasons why I started to work on the OpenGL 2/OpenGL ES 2.0 backend. First of all we wanted to have support for everything which is nowadays known as Plasma Active, but also Wayland is very important on the longer term. Currently Wayland requires an EGL backend, so having support for EGL is a prerequisite. Last but not least to give our users the best possible performance and user experience. The programmable pipeline is a way nicer API to write GL code and especially the ES code can benefit users as it throws out all the legacy code and state tracking, which is rather complex in OpenGL and should ensure better drivers.=-=-=-=-=
Powered by Blogilo
I was a little bit depressed after see my composite performance descend because of the OpenGL 2.0 backend, and reading that I could enable the old 1.X based made my day :)!
Let’s hope that 2.X support/performance will improve in the incoming intel drivers.
Cheers!
I tried kwin 4.7 (beta 1) yesterday on my laptop, with a nvidia Quadro FX770 (same as a GeForce 9600M GT) and the closed source drivers (275.09). For me some effects are not as fast as with 4.6, even when I disable the usage of OpenGL 2 Shaders. Especially the “minimize animation” is noticeably sluggish, when I unminimize a window.
Sliding down Yakuake is also stuttering. Especially when another window is openend. When I minimize all the other apps, the sliding down animation is a bit smoother.
The other effects are fine. I will try it again on the final release.
FYI, Fedora ships (only) r600g, not r600 Classic, so the debugging output even in GLX mode will look very similar, if not identical, to your OpenGL ES one.
the debug output I showed is wih r600g. There are minor details like an “ES” in the OpenGL ES case.
Thanks for the write-up, and I agree that it is rather nice to see how far the XRender backend has come.
When you try a new distro it’s hard to distinguish between “it has virtualbox/vmware/whatever extensions already built-in” and “it’s using Xrender.
What about an OpenGL 3.x backend?
Read the section to OpenGL 2 and think again.
Martin, is it possible to run fglrx with OpenGL 2 backend? Or it would ruin the performance?
run kwin with KWIN_DIRECT_GL=1, but it’s no joy doing so.
Well…
https://bugs.kde.org/show_bug.cgi?id=273697
Anyway , if i turn on Opengl 2 shaders , KWin reports OpenGL 2.1 is used
But , no sphere , so i guess OpenGL 1.x is used…
Nice post!
Would it be possible with a follow-up post listing which drivers support which backends? Perhaps also which backend is recommended for each driver.
Something like:
Driver | opengl1.x opengl2.x opengl ES
intel (mesa 7.10 )|
intel (mesa 7.11 )|
—————————————————————-
fglrx |
radeon |
—————————————————————-
nouveau |
nvidia |
no as we don’t know that. There are two many hardware/driver/Xorg/kernel combinations to say anything about it.
As far as I know from your previous posts you are testing the OpenGL 2 ES mode on a nvidia based machine. Could you at least tell us a bit more about your configuration and experiences with GLES, nouveau and 3D performance?
Thank you.
I am back to the blob on my nvidia system. And I think my experience is not of interest to anyone as it is not representative.
Hi Martin,
my notebook uses a Nvidia Quadro NVS135M gpu and for quite some time (years?) I have massive slow downs in KDE4 (a lot of different nvidia binary drivers tested – and always using the latest KDE). Even disabling the KDE desktop effects doesn’t help, but telling the nvidia driver to clean it’s cache helps.
As you seem to be an KDE expert: Do you know about this problem? Will it be fixed with the new modes in KDE4.7?
Is it nvidias fault? The nvnews.net forum has some error reports like mine – but they (nvidia) never admit that the problem is real 🙁
(using opensuse 11.3 64bit, Dell D630 notebook with intel dual core, 4GB ram, ocz vertex2 ssd)
of course we know about it and what might help is using graphicssystem raster with 4.7. Overall it seems to be the blob’s fault as we neither can investigate it (it’s a blob so no debugging) and it’s not present with any other driver.
Thank you very much for the clarification.
Looking forward for 4.7 🙂
Dell E6400 with Nvidia 160m here. I have been also feeling your pain too :-). I’m now running nouveau with KDE 4.6.3 (Arch) and performance has gotten better compared to the 4.5 cycle with Nvidia blob although most of the time I still disable Desktop effects since e.G dragging a window causes a delay
>but telling the nvidia driver to clean it’s cache helps.
how do you do that? When I was running blob I noticed that sometimes I had to switch off the computer and switch it on again to gain back performance so this might be related. I noticed the driver always reported the RAM with 512MB instead of the 256MB for my gfx.
I frequently run the following script to clean up the caches:
#!/bin/sh
nvidia-settings -a PixmapCache=0
sleep 2s
nvidia-settings -a PixmapCache=1
Without that, my system becomes unusable within half a day. With it I have to reboot once every 2-3 days.
Still depressing, on a quadcore 4 gb ram SSD system 🙁
Benchmark with kde
http://www.phoronix.com/scan.php?page=article&item=linux_desktop_managers1&num=1
…which has most likely a systematic error as can be seen in the discussion thread to the benchmark.
Well i don know, i posted it in a comment beacuse it has kde+kwin in the comparation, the results seem good to KDE.
I hope in 4.7 KDE/Kwin will be even better. :))))
No not likely, for what the benchmark tested, I expect that KWin 4.7 would do worse. But that’s exactly why I say that the benchmark has a systematic error. The performance depends on settings which are different between KWin and Compiz and in 4.7 we changed the default, so we behave like Compiz.
Anyway, thanks for your great job.
*work
For informations with a Dell Precision M4600, openSUSE Factory, KDE 4.7
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: Quadro 2000M/PCI/SSE2
OpenGL version string: 4.1.0 NVIDIA 280.13
OpenGL shading language version string: 4.10 NVIDIA via Cg compiler
Driver: NVIDIA
Driver version: 280.13
GPU class: Unknown
OpenGL version: 4.1
GLSL version: 4.10
X server version: 1.9.3
Linux kernel version: 3.0
Direct rendering: yes
Requires strict binding: no
GLSL shaders: yes
Texture NPOT support: yes