KDE On The Importance Of Wayland Explicit Sync

[mSparks]

the issue is because of nvidia

why is it nvidias fault that wayland doesnt support explicit sync?

[oiaohm]

No. Even blog specifically mentions problems with it. Vulkan buffer managment is explicit. And is good, defines really well what can be shared between what different command queues. Yes it works.

This is where you are very wrong.

implicit memory guarantees

https://www.khronos.org/blog/understanding-vulkan-synchronization

Every part of Vulkan that people call immutable when you dig deeper this is under implicit control.

https://www.collabora.com/news-and-blog/blog/2022/06/09/bridging-the-synchronization-gap-on-linux/

Most Vulkan objects such as images are immutable: while the underlying image contents may change, the fundamental properties of the image such as its dimensions, color format, and number of miplevels do not. This is different from OpenGL where the application can change any property of anything at any time.

Yes when you dig into the Vulkan specifications themselves everything that Collabora developer lists here as immutable in vulkan are immutable because that part is implicit sync protected and need to be implicit sync protected so you don't shoot self in foot.

Vulkan buffer management when it comes to allocating and freeing a buffer as in bringing a buffer into existence and making a buffer cease to exist is not explicit sync operation but a implicit sync operation. When you share a buffer with another process that buffer has to be brought into existance for that process when you stop sharing a buffer it has to be taken out of existence all this is implicit sync operations.

Here is the next fun bit there is a list of operations Vulkan does not allow that GBM and DMABUF allows. GBM and DMABUF have a more complete implicit sync support.

The reason why some thing need to be implicit sync is fairly clear. Why does not explicit sync work correct for memory management. It simple there need to be some management party that in fact makes the choice to release the storage so it can be reused and allocate that storage so it can be used.

We have protected memory OS for a reason. Items like MS DOS are explicit sync memory management where protect memory OS is implicit sync memory management. Yes single party being the OS kernel is put in charge of resources with protected memory OS.

Yes this problem appears in the real world with the "too many cooks in the kitchen" saying covering it. Allocation of resources like it not is not a job that can be massively shared. This does not matter if you are in the real world or in software the rule is the same.

This same repeat as why parts of program have to be single threaded when you would love to have the program to be completely multi threaded.

Yes the same argument was made early on with multi threading like what has been made with explicit sync that everything could be only for us to have to wake up in the end that most things would be mix of single and multi threaded with the objective to have as much multi thread as possible. We have to wake up that explicit sync is the same where like it or not everything is going to be a mix of implicit and explicit sync to work stable with us wanting as much explicit sync as what is safe to get the highest performance.

piotrj3 reality here is most of the issues with eglstreams trace back to using explicit sync for operations that need to be implicit sync for memory security/stability.

Please note I am not anti using explicit sync. Explicit sync has to be view the same as multi threading a process you can do lot but there are items you cannot do by Explicit sync. Implicit sync has it place like it or not.

[oiaohm]

With the explicit sync protocol being implemented in compositors and very soon in Xwayland and the proprietary NVidia driver, all those problems will finally be a thing of the past, and the biggest remaining blocker for NVidia users to switch to Wayland will be gone.

This is not the case for everyone with Nvidia cards. If your GPU is support by Nvidia provided open source driver you will get GBM/DMABUF parts that the Wayland explicit sync extension needs. If you your card is old enough to use the open source nouveau with firmware that allows reclocking you will be in for some gains and you have the GBM/DMABUF parts required.

https://nouveau.freedesktop.org/

Little hope of reclocking becoming available for GM20x, GP10x and GV100 as firmware now needs to be signed by NVIDIA to have the necessary access.

If you Nvidia GPU happens to own to any of those 3 series you crap out of luck and need to buy a new GPU if you wish to fix the problems.

Basically this helps majority of Nvidia users not all Nvidia users. We need to be more clear that 3 series of Nvidia is not support.

The parties out of luck are owners of the following.

NV120 (GM200)	GeForce GTX Titan X
NV124 (GM204)	GeForce GTX (970, 980)
NV126 (GM206)	GeForce GTX (950, 960)
NV12B (GM20B)	Tegra X1

NV132 (GP102)	NVIDIA Titan (X, Xp), GeForce GTX 1080 Ti
NV134 (GP104)	GeForce GTX (1070, 1080)
NV136 (GP106)	GeForce GTX 1060
NV137 (GP107)	GeForce GTX (1050, 1050 Ti)
NV138 (GP108)	GeForce GT 1030

NV140 (GV100)

NVIDIA Titan V, NVIDIA Quadro GV100

Yes Wayland explicit sync that just been added is no help to the owners of these cards as the closed source Nvidia drivers for those cards don't provide the required functionality to support the Wayland extension for explicit sync and you cannot use the open source drivers reversed engineered drivers with the GPU correctly clocked either.

I think the newest of those cards is 2018. Yes Nvidia has declared these drivers legacy so they are not getting any more major updates from Nvidia as well.

[wertigon]

In before the flame wars really starts, just want to say, thank you oiaohm for your often insightful posts that help me understand the lower workings of the graphics stack. And thank you piotrj3 for bringing concerns from your side as well, you might not always see the broader picture but that is fine and does not necessarily make your concerns invalid, just... Not as bad as you feared?

Dialogue and debate is what helps us move forward, and once in a blue moon we do get truly remarkable debates which is focused on the technical details with a minimum to no name calling where a ton of nuance is revealed that is usually lost to plebs like me.

For me that is Phoronix Forums at it's best.

[NeoMorpheus]

the issue is because of nvidia

No, its AMD fault!

/if you know, you know.

[Rovano]

to be honest i havent been hitting any crashes last 2 3 weeks.

Firefox 124.0.2 (64-bit)
Linux 6.8.4
Kde plasma 6.0.3
Qt 6.6.3
Nvidia 550.67
Cpu : i7 7700hq
Gpu : Nvidia 1050ti ( Mobile )
Manjaro Linux [ unstable repo ]

... KDE + Wayland + AMD opensource drivers has been fully usable (including 3-monitors) since 5.26/5.27

As a 1660 super owner I am so happy to read of these developments.
Nouveau is running well on Plasma 6 - but it would be nice to get the full features of the card that the proprietary driver offers.
Thanks to all devs working to get Wayland fully performant.
Finally it is happening.

But on Nvidia it also works from the 5.x series as you state with AMD. You just need a newer series driver. 550 is best.

It works including Firefox video acceleration in Wayland (not XWayland).
There is still a problem with Wayland with more CPU load when decoding video in the browser via GPU. With X11 there is no such problem.

The only problem I had was that when I switch to the Nouveau driver, it crashes in combination with the browser.
I'm not sure if the Nouveau driver crashed or something from XWayland.

It's also nice that both KDe 5.x and 6.x run smoothly with the new Nvidia driver. Both Wayland and X11.

Unfortunately Nouveau is unusable for my card and probably never will be.
Can't overclock the card.
Still, I'm curious if there's anything that can be done with video via Vulkan.
I am waiting for Nouveau Vulkan 1.3 support for my card in Mesa 24.1.

The solution is to get a newer 2000 series GPU or later.
Or something from another manufacturer.

High resolution for TTY already works on the Nvidia driver.

I'm also curious about the new Nvidia power management. When will they put it on?

[Blademasterz]

What's the advantage of using Nvidia on Linux 😂

[jeisom]

Obviously you mentioned NVIDIA in your post, together with plasma 6 and x11 -- maybe you can't write

I use 2 different AMD GPU (Polaris and RDNA2) with wayland on 2 different systems since KDE plasma 5.26, no crashes -- maybe I am lucky

"Many are blaming Nvidia for wayland's slow adoption, but even on AMD hardware Plasma was unstable until Plasma 6"

My first post mentions my experience with AMD. Obviously you either can't read or didn't read and saw NVIDIA.

[skeevy420]

What's the advantage of using Nvidia on Linux 😂

You don't have to write a suicide note. The cops will see your NVIDIA+Linux rolling release setup stuck on yet another bad module update and they'll know what happened.

[skeevy420]

"Many are blaming Nvidia for wayland's slow adoption, but even on AMD hardware Plasma was unstable until Plasma 6"

My first post mentions my experience with AMD. Obviously you either can't read or didn't read and saw NVIDIA.

IMHO, that was because Plasma 5 sucked at Wayland and not because of Intel, AMD, or NVIDIA. I say that as an AMD user that has ran KDE Wayland since 2022. Between 2022 to now, maybe earlier even, if a person had a limited workflow they might have never realized how limited and bad Plasma 5 Wayland really was. Like if they stuck to KDE software, terminals, text editors, didn't play Steam games, stuck to PSX/SNES emulation, etc everything would just work, but if they would have stepped out of their workflow they'd have ran into Wayland limitations.

That's not meant to be taken too negatively. Practically every desktop environment goes through the Wayland Sucks Transition Period when they're getting everything wired up.