KDE KWin's Move Away From GBM Surfaces

[mirmirmir]

In regards to CPU usage I (and others) are seeing the kglobalaccel user service going rogue since mid last year which can only be resolved with manually restarting the user service whenever that happens, which is always after every new login and appearing again based on certain different cicumstances like VNC usage or Steam Link streaming among others https://bugs.kde.org/show_bug.cgi?id=306352 I really wish someone could look into that as it's highly annoying.

Wow thanks for pointing that out. I found my CPU usage lower by restarting the service. That said, the random spike is still there, now that I looked closely, my disk is busy even in idle, and after some cleaning up, my disk still high, I mean i already swapped my system with two new nvme SSD, It sucks that I have to buy new SSD because my system eats up my storage lifespan prematurely

That said, I just moved away from kde, and I no longer find that CPU spike. And I found disk usage more sane now too. I should've looked this problem sooner when found something was up. But I never had time for it, or rather I was lazy to diagnose the problem.I guess it's a part of kde experience to play detective, it's the same experience when I was playing with arch, like follow guide, question wether something goes wrong, refer to wiki, solve the problem, and then find the next problem to solve, I'm not saying it's, bad, I was actually having fun solving computer problem. But nowadays I feel like I don't want to spend more time on PC, and gradually stop tinkering and ended up just to use the default. I guess it's part of getting old.

Although, I was a bit at fault for being stubborn, I mean that same friend has been telling me to just change de and I said no everytime. I guess I have to take an L next time he checks my system. Like man, Ive been defending kde so hard. And I can cope with occasional stutter, but I can't keep defending it when money is on the line. Sorry.

But yeah, I still hope people keep maintaining kde, I appreciate those devs working to make kde usable Linux desktop. Good luck on kde 6

[kiffmet]

dfyt Have you by chance tried to disable baloo? I don't even have it installed, so maybe that's what makes the difference. I don't use activities either.

As for IO blocking stuff - I've only ever seen that with Dolphin (and it was only Dolphin that was being blocked, not the rest of the DE) when trying to access my NAS and the disks have to spin up first. AFAIK the KDE devs are working to make IO more asynchronous/non-blocking in the future. There have already been some changes in that direction in one of the previous Plasma releases.

As for the rest of my setup: 5900X, 32GiB RAM, 32GiB swap - 20 swappiness - zswap/zstd,

• main nvme drive for / and /home as btrfs subvolumes incl. zstd:3 compression and async discard, aswell as swap
• btrfs fs-level raid0 on two SATA SSDs for the Steam Library (noCOW) - no compression
• another SATA SSD as "junk" drive for downloads zstd:3

Aside from that, I am using BORE, and some kernel patches that influence readahead, IO and memory management:

• lower non-hugetlb pageblock size
• VM_READAHEAD_PAGES set to 2MiB
• block: set rq_affinity to force full multithreading I/O requests
• MGLRU, vma_has_recency()

on Gentoo, so my system is heavily optimized which could also be the reason as to why my system behaves differently in this regard…

[Vistaus]

For kwin? I highly doubt that.

Not for KWin, but for Plasma itself, yes. Been using it for months and my dad too, and several Phoronix members also, and it makes a noticeable difference.

[Berniyh]

Maybe, but we're talking about kwin here.
Vulkan rendering for Qt elements is a Qt feature, it has nothing to do with KDE/Plasma specifically.

Also, it's not necessary to set env variables in /etc/environment, unless you want to use that across multiple users.
systemd loads env variables from ~/.config/environment.d
So just drop a .conf file in there containing the VAR=value.

[mdedetrich]

Nvidia's driver is based on the same code as the Windows driver, plus Linux specific parts. But it never implemented gbm because that is a mesa implementation detail. Instead they suggested EGLStreams (after everyone started using gbm), which they also pushed as Khronos standard. Implementing gbm was hard for them due to their shared driver and they said their GPU arch is not performing optimally with how gbm works. For them, gbm (Generic buffer management) is *too* generic and flexible. EGLStreams is much more limited. But yeah, eventually Nvidia gave in and implemented gbm in their driver, too.

This is oversimplified and hence is missing the underlying broader issue which is implicit versus explicit sync. While the EGLStreams wasn't the best way way to approach this, the fundamental problem is that NVidia's driver is entirely based on explicit sync (because its far superior, even AMD agrees), something that NVidia did when Windows Vista rebuilt their WDDM architecture. The current problem with Linux graphics stack is it doesn't entirely properly support explicit sync.

Understandable NVidia does not want to entirely rebuild their driver just because of Linux, especially if they are putting in what is considered an outdated way of handling synchronization on the driver level (implicit sync).

Nvidia made a mistake with no implied sync. Yes Microsoft asked for no implied sync in Windows graphics drivers because they did their own kernel space implied sync for graphics on top of the explicated sync interfaces Microsoft asked for. Also make mistake with EGLStreams memory model that if you closed EGLStreams application all buffers that application allocated even if they had been shared with another application would cease to exist. So no compositor restart with EGLStreams is possible.

Thats not a mistake, implicit sync is objectively bad and Linux is the only desktop OS that still relies on it

You should be thanking NVidia for forcing Linux to modernize, something that it desperately needs in the desktop space.

[geearf]

Not for KWin, but for Plasma itself, yes. Been using it for months and my dad too, and several Phoronix members also, and it makes a noticeable difference.

What's the var to set please? A quick search yields no help on this.

[piotrj3]

Do not mix up EGL with EGLStreams. EGLStreams has something as equally stupid as GBM surface. There was a change in mesa submitted to standard body to allow EGL to directly create GBM buffers without using GBM surface middle structure.

Weasel do remember Nvidia funded a developer to make KDE work with EGLStreams and was forced to admit defect this is why Nvidia drivers worked out how to get GBM support. I would say in this case both Nvidia and Mesa were wrong with their first solution. Mesa solution was closer to right.

Nvidia made a mistake with no implied sync. Yes Microsoft asked for no implied sync in Windows graphics drivers because they did their own kernel space implied sync for graphics on top of the explicated sync interfaces Microsoft asked for. Also make mistake with EGLStreams memory model that if you closed EGLStreams application all buffers that application allocated even if they had been shared with another application would cease to exist. So no compositor restart with EGLStreams is possible.

Then another mistake no turtles all the way down by design. So eglstream buffer shared from wayland compostor that was then shared to xwayland by eglstreams design would not want to share to X11 application.

Nvidia pushed eglstreams hard but it was a total not functional for Wayland compositor or X11 server.

There is no mistake. Actually AMD is in same pitfall as Nvidia in this case, because RadeonSI relies on hacks to make same implicit sync working. Just when RadeonSI hacks kinda work, Nvidia sometimes falls into rare issue with glamor.

Thing is to make implicit sync working, you need totally ordered API calls. If 1 thread draws in own context, it is ok. If there is some scheduler that orders opengl calls from diffrent opengl threads properly, that is also ok. Moment that scheduling responsibility is moved onto driver is when things get broken because driver has issue guessing when happens what, and is forced to do basicly full flush until userspace is idle. Strongly inefficient.

Quoting AMD engineer:
The synchronization works because the Mesa driver waits for idle (drains the GFX pipeline) at the end of command buffers and there is only graphics queue, so everything is ordered.

And that wait for idle sucks. Implicit wasn't that bad in old APIs and older X server. Moment however we started to do multithreading, multiple command queues etc... started sucking.

[oiaohm]

That depends how far you want to go with Vulkan. Technically speaking you can do everything opengl can do in Vulkan, but you cannot do everything Vulkan can do in OpenGL. If people start manipulating/passing around buffers with Vulkan I don't think people can do that with just opengl.

Except that was not true for the complete time of Vulkan existence that you could do everything opengl could do under Vulkan. Issue with Zink needing vulkan extensions was because Vulkan and Opengl at the start did not 100 percent overlap with each other.

Yes there was a lot of EGL feature that could not be done under early Vulkan either. Its vulkan 1.1 before you could possible write a Wayland compositor/bare metal solution with Vulkan.

https://www.phoronix.com/news/Vulkan-1.1-Wayland-Compositor

Basically there is a reasons why early Wayland composers are all EGL
1) Vulkan did not exist.
2) Vulkan was not able to do manipulation/passing around buffers on bare mental setup before Vulkan 1.1.

It taken a while for Vulkan to catch up on all the opengl/egl functionality.

[shmerl]

What about moving away from EGL completely and using Vulkan / WSI instead?

[shmerl]

Move to Vulkan is kill the support for all pre-2012 GPUs, which don't have Vulkan and depends of OpenGL.

Supporting ancient GPUs is not worth keeping everything else back. Having some legacy branch for them is good enough for those who need it for some reason.