The return of kwin_gles

Back in 4.x we provided two binaries for KWin: one compiled against OpenGL (kwin) and one compiled against OpenGL ES (kwin_gles). The reason for that is that one can only reasonably link either OpenGL or OpenGL ES and OpenGL ES is only a subset of OpenGL, so one needs to hide the OpenGL calls (especially the OpenGL 1 calls).

With 5.x we were no longer able to provide these two binaries. The reason for that is that OpenGL got “upgraded” in Qt and QtGui itself links either OpenGL or OpenGL ES. To keep the system’s sanity we decided to follow how Qt is compiled. If Qt is compiled with OpenGL support KWin gets compiled with OpenGL support, otherwise with OpenGL ES support.

That’s of course a reasonable design, but it means that it becomes difficult to test the OpenGL ES code paths. One needs a dedicated Qt and all other dependencies compiled against OpenGL ES. Or one needs a nice device like a Nexus 5 with Plasma mobile. This had resulted in breakage already as we were not able to test enough. Such times belong to the past as I have a nice Plasma mobile device to compile and test my KWin on.

But since we introduced OpenGL ES support through a compile time switch, many things have changed. KWin dropped the OpenGL 1 support which means that most of the code which wouldn’t compile with OpenGL ES is just gone. Furthermore we switched to use libepoxy, so we don’t link OpenGL or OpenGL ES at all, but libepoxy which does the right thing for us. With that we are able to remove all the compile time checks. Of course we need runtime checks to ensure that we don’t call functionality which isn’t available on OpenGL ES.

Now with the upcoming 5.5 release we are able to have one binary which serves both OpenGL and OpenGL ES. Note to distributions: the artifact kwinglesutils.so is no longer compiled, please adjust your packaging rules. KWin will use either OpenGL or OpenGL ES depending on what Qt uses.

Given that nowadays it’s also possible to create both an OpenGL and OpenGL ES context at runtime we can also make use of that and introduced a new value for our KWIN_COMPOSE environment variable: O2ES. If that’s specified KWin will use the EGL backend and create an OpenGL ES context. Although it in general is also possible to create an OpenGL ES context through glx we do not support that for simplification. As proof debug output (qdbus org.kde.KWin /KWin supportInformation) from my running KWin instance:

<code>Compositing
===========
Compositing is active
Compositing Type: OpenGL ES 2.0
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Ivybridge Desktop 
OpenGL version string: OpenGL ES 3.0 Mesa 10.6.8
OpenGL platform interface: EGL
OpenGL shading language version string: OpenGL ES GLSL ES 3.00
Driver: Intel
GPU class: IvyBridge
OpenGL version: 3.0
GLSL version: 3.0
Mesa version: 10.6.8
X server version: 1.17.3
Linux kernel version: 4.2
Direct rendering: Requires strict binding: no
GLSL shaders:  yes
Texture NPOT support:  yes
Virtual Machine:  no
OpenGL 2 Shaders are used
Painting blocks for vertical retrace:  yes
</code>

So in a way we have kwin_gles back, it’s different as it’s no longer a dedicated binary, but it’s runtime switchable. For the moment the only way will be the environment variable. I’m reluctant to add a config option as that sounds like quite some chance for breakage.

12 Replies to “The return of kwin_gles”

  1. Do you recommend OpenGL or OpenGL ES with Mesa 11 on a radeon card?
    As a gentoo user I never know what to take…

    1. @David

      As a fellow Gentoo user I would highly recommend against using OpenGL ES for the time being. I’ve tried both with Plasma 5.4 and GLES is just asking for trouble right now. For a much more stable Plasma experience compile without gles2: USE=”-gles2″ for mesa, kwin, qt*

  2. I have 1 issue with this. Is there a reason why it’s called just “O2ES” instead of, for example “OpenGL2ES”/”OpenGL2_ES”/”OpenGL_2_ES”, just a few letters but drastically reduces clarity… IDTTIIAGITSILT(cryptic?) = I don’t think that it is a good idea to shorten it like that.

    1. This is a post about OpenGL ES. Your question is completely offtopic. I understand that you miss it, but commenting on unrelated developer blog posts, doesn’t make it happen.

  3. Hey Martin, please help me out on this:
    KWin does not offer hardware-accelerated composition on graphics cards running with the Radeon r300 driver due to not entirely implementing OpenGL 2.1.
    Does this hardware limitation also apply to these cards’ OpenGL ES 2.0 capabilities or can we hope for acceleration after all?
    Thanks.

    1. Does this hardware limitation also apply to these cards’ OpenGL ES 2.0 capabilities or can we hope for acceleration after all?

      If I remember correctly the limitation did not matter in kwin_gles of 4.x. So yeah, might be that this will work. But I don’t know as I cannot test with r300 any more.

  4. Maybe I missed one of your posts, but it would be really interesting to know why generally OpenGL is considered better for KWIN on Desktop, and GLES for mobile? What’s the difference there – so why is this?

    Would be really interesting to get your view / description there. Maybe for another Blogpost some day? :-). Would probably be helpful for the mery-mortal like me to understand it a bit better why this differenciation is necessary.

    1. It is relatively simple: different hardware. Desktop hardware supports OpenGL, but mobile only es. With full OpenGL we can do more and also have more extensions available which can provide better performance

    1. Very unlikely. There is a proper driver being worked on and with that it will be easier to get something working.

Comments are closed.