KDE KWin's Move Away From GBM Surfaces

[curfew]

Suddenly it looks like Kwin is making more progress than the odd fork named "Kwin Fast Track"...

[oiaohm]

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.

Legacy support is not the most efficiency thing. What AMD engineer says they do so mesa works you find Microsoft doing so directX 11 and before implicit sync works in the Microsoft kernel mode direct X overlay driver.

The X11 2d rendering that glamor. is a implementation of is most used by really old applications from the time that multi-threading the UI was a pipe dream and where implicit sync is normal.

Strongly inefficient is not grounds to not support a feature. Spinlocks in userspace is strongly inefficient as well. Yes the Linux kernel developers at one point looked at banning user-space spinlocks with the same kind of arguments you are making. Linux kernel developers had to back track on this plan as well. Yes the Linux kernel developers did consider making spinlocks perform badly as well.

[mos87]

KDE never gonna become stable and thus never become dominant and truly usable. And I absolutely can't stand the ergonomics (or rather lack thereof) of Gnome Shell and its apps.

Free desktop is a mess.

[shmerl]

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.

What about whole explicit synchronization approach that compositors need to switch to with Vulkan? Will KWin tackle that? Classic Wayland compositors were using implicit synchronization and it wasn't easy to change the paradigm.

There was a post about it here: https://www.collabora.com/news-and-b...-gap-on-linux/

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

[shmerl]

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

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

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

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

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