KDE KWin's Move Away From GBM Surfaces

[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.

[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.

[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…

[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

[dfyt]

I've been using this configuration for years now and it's not stuttering for me? Having that said I'm also using the BORE scheduler instead of CFS, so that may be the reason.

I'm running BORE with a zfs stripe on dual nvmes and experience big ui slow downs with kde, ironically with gnome butter smooth - however and hence the irony nautilus can be way way slower than dolphin sometimes around 50-80x slower for the same operations. So yes I know immediately a response is oh thats why gnome doesn't stutter as it's so darn slow - but I verified by running some cps and rms via cli with both DE's.

Try having an autofs share with Dolphin and it can hang the entire DE, Gnome no such issues. KDE is too closely coupled to the IO. Lastly KDE is my DD.

[Mitch]

I doubt that they will remove Xorg support within the time frame of Plasma 6. So not within the next 5-10 years.
The way I understand that blog post is that they want to untangle it a bit, which makes it easier to build without Xorg support (if you'd want that) and at some point in the far future, remove it.

Well, if Wayland plus XWayland can achieve full or good enough feature parity, no matter how soon, KDE could still just remove the XOrg option. This would allow them to just support the Wayland side and rip out XOrg stuff at their own pace rather than all at once. Seems more reasonable I think because the sooner they desupport X, the sooner they can greatly simplify maintenance and bug testing. It also seems like it would help them move away from old stuff and build new stuff faster.

If anything would be holding them them up outside the above, it's all the things that could break on Wayland, like unsupported hardware, if there is any

[piotrj3]

Introducing Vulkan rendering does not mean that OpenGL will be dropped. Why does it have to be one or the other?
afaik, Vulkan support is planned with Plasma 6, but I doubt it's high priority. OpenGL works, after all.

Also, isn't it always that users with older GPUs complain that Plasma/kwin is too resource-heavy anyway.
So supporting those is just so that they can start up the thing to complain? :P

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.

[oiaohm]

Of course Nvidia was right, they even always detailed why EGL was superior. It's just retards who ignore it because their precious "Mesa" was doing it differently. Who the fuck cares about Mesa's decisions. It's like Betamax vs VHS.

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.

[cl333r]

Impressions matters right? If I remember right, Nvidia came in later for the EGL comments, after for months saying "No support for Wayland", after a while finding a solution. The impression a person got from that (if I remember it correctly) was that Nvidia having a strong rejection to Wayland support and then comes in saying their solution is the absolute right one. EGLstreams I think the thing for Nvidia Wayland support. Correct me if I am wrong.

In any case, right or wrong, there are ways to work with people.

Oh I didn't imply Nvidia isn't an asshole as a whole. As a closed source corporation they're inherently hostile to open source and behave the way they think they can get away with, as is the case with any such corporation.

[cl333r]

EGLStreams was an Nvidia extension of EGL that tried to bridge EGL and DRM differently after everyone had already written their buffer management code (so nobody wanted to redo everything to use Nvdia's stuff or maintain two codepaths) and I recall there being unresolved issues with EGLStreams that made it very unattractive as the universal option (according to Drew Devault, at the time).

IIRC the Mesa devs eventually acknowledged that EGLStreams was superior but they didn't want to move to EGLStreams or just as another option because "everything already worked" and they didn't want to bother (which is understandable, nobody likes new work).