| Summary: | Prefer EGL to GLX for GL support also on X11 | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | C. Leu <kle> |
| Component: | glx | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED NOT A BUG | ||
| Severity: | normal | CC: | guido.iodice, kde, nate, serg, uwu |
| Priority: | NOR | ||
| Version: | 5.18.7 | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
C. Leu
2021-09-13 15:33:27 UTC
Currently, all our focus is on Wayland. We would prefer to avoid touching X11 code if possible. As for making EGL default, on X11, kwin has no any way to determine when a buffer swap completes. For some people, it may be an issue because it can result in stuttering. Thanks Vlad Zahorodnii for your replay. I have now switched in kwin the compositing of all my Kubuntu 20.04 LTS installations to OpenGL ES / EGL and noticed so far no issues regarding any sort of stuttering. Maybe I will see a "buffer swap" problem sometimes in the future... ;-) How can I provoke it? Furthermore I enabled the X11 EGL option even in Firefox, - also here no issues so far just a benefit in the overall behavior. However, it could be possible that this problem described here is not only a "GLX" problem but also one of the "notification system". As mentioned, the message "kworker blocked for more than 120 seconds" has not occurred so far with EGL backend enabled. But when the RAM memory is quite full, then I have sometimes still some "hangers" for example in Dolphin. So I decided to disable the notifications completely, only the critical ones are allowed. After this setting there were no more hangers present, - strange but interesting. Whatever, it should be noted that this problem may be primary relevant for systems with low RAM memory. My iMac 5,2 has just 4GB physical RAM installed, but Apple enables in legacy CSM Bios mode only around 3GB which is effectively too less for Kubuntu 20.04 LTS. Apple furthermore also screws down the speed of the SATA controller to UDMA133, which is just ridiculous because it limits totally my Crucial MX200 SSD. These points can be only resolved thorough a installation of Kubuntu in native (mixed-mode) EFI. Whatever, back to the original matter. As for now I have switched to the EGL backend at the following Apple computer models. I noticed an improvement in the KDE GUI behavior at all of them. iMac5,1 (4GB RAM, only 3GB usable, R300 Mesa 21.0.3) iMac8.1 (6GB RAM, native EFI, R600 Mesa 21.0.3) iMac9,1 (8GB RAM, native EFI, R600 Mesa 21.0.3) Here follows a short status update. Just for reference, - until now I was NOT able to reproduce any sort of a "stuttering effect" with the EGL backend. In the meantime I switched at a further iMac computer running Kubuntu 20.04 LTS (and containing a Radeon 6770M GPU) to the OpenGL ES / EGL backend. Also here, no negative side-effect, just a benefit in the KDE Plasma GUI behavior: iMac12,2 (16GB RAM, native EFI, R600 Mesa 21.0.3) I searched at the web regarding this EGL/GLXÂ matter and found the information that Firefox 94 will make EGL to its default: https://www.itsfoss.net/firefox-94-will-change-the-output-for-x11-to-use-egl-by-default/ However, this is true only if Mesa 21.x driver version (or higher) is present. Fortunately that's the case for an up-to-date Kubuntu 20.04 LTS installation. ;-) I also found some information which indicates that the mentioned EGL "stuttering effect" may be more an issue of the proprietary Nvidia Linux driver. Regarding the Radeon side I can confirm for Mesa 21.0.3 that the OpenGL ES / EGL backend runs great on several quite different older Radeon GPUs. The most impressive benefit I noticed at my oldest and weakest iMac5,1 computer. The usability jumped from "not really usable" to almost "perfectly usable" in near any office-work related scenario. So out of my perspective as a Linux user I simply don't understand why there exist no "user-friendly way" to enable the OpenGL ES / EGL option in the compositor. It doesn't have to be the default setting. Just an option to play with it. ;-) Whatever, I know this will all change with Wayland but I assume that this bigger "switchover" will then probably also exclude some older hardware. My conclusion is therefore, it's time to change to EGL also on X11! Well, - at least for systems with the awesome Mesa drivers... ;-) Again a short update. During the last few weeks it has been shown that the best way to enforce EGL in kwin is through the "KWIN_OPENGL_INTERFACE=EGL" and not the "KWIN_COMPOSE=O2ES" variable. This will effectively keep the OpenGL 2.0 or OpenGL 3.1 "function feature set" and just force EGL over GLX. sudo nano /etc/profile.d/kwin.sh export KWIN_OPENGL_INTERFACE=EGL The first mentioned "KWIN_COMPOSE=O2ES" environment variable is also applicable but it will additionally switch the compositing to OpenGL ES 2.0. Just to be clear, this is perfect for weaker hardware like single core Netbooks, AIO computers, or older systems with limited GPU functionality. Such lower-end systems may benefit significantly from the OpenGL ES 2.0 mode, like the previously mentioned Apple iMac5,1 from 2006. However, the OpenGL ES 2.0 compositing may limit in certain situations some enhanced graphical effects of a theme. I can confirm this now for the "Se7en Aero" global design which shows partially missing elements. For example, all frames in dolphin are becoming "transparent". This is not the case regarding the regular OpenGL backend in conjunction with EGL. It should also be noted that this is not the case for the standard (more basic) KDE designs "Breeze" and "Breeze-Dark", - they work fine even with only OpenGL ES 2.0 feature set. Whatever, maybe there will be in the future beside a Vulkan additionally also an OpenGL ES 3.0 rendering backend, - it would allow more effects on weaker hardware. ;-) JFYI, I have to add export QT_XCB_GL_INTEGRATION=xcb_egl to kwin.sh to make composing work (arch, intel with modesetting, x11, plasma 5.26.5 ) (In reply to Vlad Zahorodnii from comment #1) > Currently, all our focus is on Wayland. We would prefer to avoid touching > X11 code if possible. > > As for making EGL default, on X11, kwin has no any way to determine when a > buffer swap completes. For some people, it may be an issue because it can > result in stuttering. Is this still true? I have been using kwin with EGL (but with OpenGL not GLES) for some time and have not noticed any problems. In fact, my tests show that kwin occupies less CPU in some cases (Intel TigerLake). For example, if I watch a video and overlay a terminal window (semi-transparent), with GLX kwin takes up about 7% of my CPU, while with EGL it takes up 5%. |