I’m very excited about a change I have been working on for KWin since yesterday and which has entered the review process today. The result of it can be seen in this debug output of KWin:
kwin(17876) KWin::Compositor::slotCompositingOptionsInitialized: Initializing OpenGL compositing kwin(17876) KWin::SceneOpenGL::createScene: Forcing EGL Windowing System through environment variable kwin(17876) KWin::EglOnXBackend::initRenderingContext: EGL version: 1 . 4 OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD TURKS OpenGL version string: 2.1 Mesa 8.0.4 OpenGL shading language version string: 1.20 Driver: R600G GPU class: NI OpenGL version: 2.1 GLSL version: 1.20 Mesa version: 8.0.4 X server version: 1.12.3 Linux kernel version: 3.2 Direct rendering: yes Requires strict binding: no GLSL shaders: yes Texture NPOT support: yes kwin(17876) KWin::ShaderManager::initShaders: Ortho Shader is valid kwin(17876) KWin::ShaderManager::initShaders: Generic Shader is valid kwin(17876) KWin::ShaderManager::initShaders: Color Shader is valid kwin(17876) KWin::SceneOpenGL2::SceneOpenGL2: OpenGL 2 compositing successfully initialized
Everything looks quite normal. OpenGL 2 based compositing, everything works fine, all effects load. But still there is something very exciting going on. Instead of GLX, the EGL backend is used, which has been written for the OpenGL ES 2.0 compositor. But this is the normal KWin, not the kwin_gles. We run OpenGL over EGL. To do so the current patch uses an environment variable KWIN_OPENGL_WS which can be set to egl. By default we still use GLX as that’s the safest what we can get at the moment with the available driver collection (and our egl backend needs some more love to be honest). It shows how important the refactoring which I have blogged about last week has been: without it this change would not have been possible.
This is a very exciting change as it means we have one backend to serve both OpenGL and OpenGL ES 2.0, it is also very exciting as it means that KWin is already prepared for the proposed new OpenGL ABI, which will deprecate GLX. The current OpenGL ABI pulls in GLX even if you don’t want GLX at all. I’m very happy that we have this EGL backend as this can turn out to be very important for the adoption of the new OpenGL ABI. It has been noted during the discussion at XDC that there is a chicken and the egg problem by distributions not providing EGL and software therefore not using EGL which means distros do not provide EGL. We can help here as we are a component which most distributions ship and which now requires (currently still optionally) EGL.
As a free software user I’m also excited that this is a change fully built on top of the free OpenGL stack. For a long time quite some functionality of KWin had only been available with proprietary drivers. Now not only the free OpenGL stack provides all we need, it also allows us to move into areas where the proprietary drivers are not yet. With my KWin developer hat on, I of course hope that the proprietary drivers will start to provide EGL, too.
Last but not least I am excited about this change as it is another small step on our long road through the country. It means that changes which will need to happen in the future can also be provided to the OpenGL version of KWin even if we do no longer use GLX as the primary backend.
So, this is another step towards becoming non-dependent on X?
Hail to the king!
Great work!!
And it really is an exciting time for openGl on linux, it was becoming unbearable but this ABI change and all the work going into the drivers… great!!
Also seing the Waffle project on XDC and combined with Dante… can’t wait for great opengl support on linux:)
Yes, I agree it will be great when we can move to EGL. The implementation of EGL_KHR_image_pixmap is far better than texture_from_pixmap because there is no need to worry about server grabs and the like (this has caused great pain …). Of course, right now there’s not too much difference because EGL is implemented in the same was a GLX is.The problem of course is that figuring out where EGL is supported at runtime is quite difficult – if you actually want to use EGL you need to link to libEGL.so, which means that right now we’d have to ship two different versions of the compositing backend for drivers that do ship libEGL and drivers that do not ship libEGL. Waffle could be a solution to that, but I haven’t been able to do much reading on it. I did hear that nvidia was planning on backporting the EGL support in Tegra to their GeForce drivers.
my patch btw always links against libEGL (if present at compile time), no matter whether the driver supports it or not. In practice that would mean it picks the mesa implementation, so if a user selects egl through the environment variable without having a driver which provides egl it will just not work. No big deal for KWin as it can fallback to XRender or no compositing. But I have not yet tested whether that actually works given that I currently don’t have a system which uses a blob 😉
Great, keep up the good work!
Sounds great! I love seeing KWin progress. My only remaining peeves are the effects configuration interface and the name itself. ‘kthis’ and ‘gthat’ all sound very legacy to my ears.
How does GLES stand up against GLX in terms of performance?
KWin is not a user visible name and how we call it internally should really not matter. Whether it’s foobar or KWin is for the user the same.
Sorry that question does not make any sense. Either compare OpenGL with OpenGL ES or GLX with EGL, but comparing GLES with GLX is like comparing apples with pears.
According to this source: http://www.phoronix.com/scan.php?page=news_item&px=MTE4ODM
GLX seems to be faster than EGL
but it’s Phoronix and it’s about Dante, whether that matters for KWin is not clear
Then I’m looking forward to a comparison/benchmark between EGL and GLX in matters of performance.
Nice work Martin and congratulations.
Kindest Regards,
Dietrich
Did I get that right: I might soon be able to use all of the effects KWin provides with e.g. the nouveau driver? Last time I used nouveau, some effects very important for me could not be activated but required the proprietary nvidia drivers (similar thing with the free vs proprietar ATI drivers).
Oh that depends on the nouveau driver. I have been using nouveau for quite some time and in fact the OpenGL ES 2.0 port was performed on nouveau.