GNOME's Mutter Variable Rate Refresh Support Closer To Being Merged

[piotrj3]

How would you like to get proper feedback and tests for something that wasn't even released?

Releasing thing as is and dealing with issues and limiations reported by users is good way to create something that should fit as many users as possible. Wayland wouldn't get good feedback it if would be developed behind the closed doors. What shouldn't happen is removing way to go back to previous solution and force users to deal with new and incomplete. But we have that - X11 is still available and maintained and no popular desktop developer even propose removal of it and going full Wayland. The fact that Wayland is default on some distributions is also good thing. If some user would be satisfied with its current state then it can use it. If another user would get many issues under Wayland then they can be reported and user can easily go back to X11.

Think from perspective of Rust - Rust literally had tons of compiler versions before 1.0 at which point features could be added/removed/deprecated etc. In nutshell for very long time Rust didn't have backwards compability for exactly that reason - reveal issues. We also have rust nightly for new features that might but doesn't have to come.

Or think about Vulkan raytracing, Nvidia made experimental extensions, added support to it in driver, quickly Quake 2 RTX etc. was released, and then gave a lot of time for AMD or Intel do contribute on it, and in fact they did.

I can take a look at recent vulkan extension https://www.khronos.org/registry/vul..._pipeline.html

See contributors. Yea I see variety. Let's see maybe Wayland:

https://wayland.freedesktop.org/docs/html/pr02.html

Oh todo after 10 years.. nice. After I look at definitions etc. I cannot find contibutors list. Fuck Nvidia, I haven't seen even "AMD" being mentioned there. Did Wayland had some experimental period with potential invalidating wrong stuff? No. Was there 5 years period like Rust to remove wrong stuff? Heck Vulkan had Mantle before, Vulkan had 2 year period for just raytracing extension etc.

Oh also when Nvidia did complain about GBM did anyone took that into account? No. Wayland honestly by itself is not that big issue (somehow, but I would consider it very lucky), but buffer managment is.

[mcqigo]

If they only were developing - no changes for a year:
wayland-protocols gitlab issue 69
1 year old merge request, discussion just died 3 months ago:
wayland-protocols gitlab MR 44

There seems to be a lack of interest, manpower or both in order to get VRR established as an official protocol -.-

O yeah, open source is made mostly by volunteers, if not by skeleton crew. It's hard to keep interest on hard topics if you're doing it casually, hence the time factor.

[mcqigo]

The biggest issue is not that its a protocol but more that there was never a proper implementation of that protocol to actually verify whether the protocol is actually enough/practical/usable.

And no weston doesn't count since its just a reference implementation, I am talking about something like KDE/Gnome, in other words Wayland shouldn't even been released until KDE/Gnome had an implementation of the Wayland protocol that actually covered all use cases. This would have also revealed a lot of core issues with Wayland/Linux graphics stack (such as implicit vs explicit sync).

There is no 'proper' implementation of WIP concept. Implementing half baked, unproven implementation is a dread and would steer volunteers away from work even more.

[mppix]

Think from perspective of Rust - Rust literally had tons of compiler versions before 1.0 at which point features could be added/removed/deprecated etc. In nutshell for very long time Rust didn't have backwards compability for exactly that reason - reveal issues. We also have rust nightly for new features that might but doesn't have to come.

Or think about Vulkan raytracing, Nvidia made experimental extensions, added support to it in driver, quickly Quake 2 RTX etc. was released, and then gave a lot of time for AMD or Intel do contribute on it, and in fact they did.

I can take a look at recent vulkan extension https://www.khronos.org/registry/vul..._pipeline.html

See contributors. Yea I see variety. Let's see maybe Wayland:

https://wayland.freedesktop.org/docs/html/pr02.html

Oh todo after 10 years.. nice. After I look at definitions etc. I cannot find contibutors list. Fuck Nvidia, I haven't seen even "AMD" being mentioned there. Did Wayland had some experimental period with potential invalidating wrong stuff? No. Was there 5 years period like Rust to remove wrong stuff? Heck Vulkan had Mantle before, Vulkan had 2 year period for just raytracing extension etc.

Oh also when Nvidia did complain about GBM did anyone took that into account? No. Wayland honestly by itself is not that big issue (somehow, but I would consider it very lucky), but buffer managment is.

Yikes.

Wayland is done by the X devs. It was not called X12 because of backwards compatibility..
Oh and Nvidia was invited to the Wayland meetings, did not show up, blocked the outcome after the fact, proposed the non-viable EGLstreams solution (that resulted in flawed implementations in both Gnome and KDE), and finally had to give up (and concede).

Problem is they are not even good at giving in. The 510 stable driver (and mesa backend) is a complete mess to the point that I would not bet the it ever lands in Debian (and the approach is also depreciated with R515)

The new R515 open source driver has more promise but it is at best a beta for any Wayland DE and only supports a handful of cards.

I follow this closely because I use their cards for work.
However, even a drunken idiot could come up with a better strategy

[oiaohm]

DWM is not what matters here. Heck some window operations kind of force synchronization so it is obvious why some operations (even in Vulkan WSI) is implicit.

What matters is WDDM and Windows miniport driver. And that one is sending commands to drivers and that one is explicit and that one has GPU scheduler sending multiple diffrent command buffers. This is why Nvidia rewrote in windows vista times entire driver to explicit, because all the work of knowing what to synchronize with what is sent. There are some parts of WDDM like multiple synchronization levels which sort of are interrupt like, but at core everything from perspective of driver is explicit and once driver finishes it has to send DirectX kernel driver information via DXGKCB_NOTIFY_INTERRUPT that operation is completed. Actually entire synchronization is done on directX side.

mdedetrich need to read what piotrj3 wrote.

This is misleading, WDDM which is the core part of the Windows graphics display driver that the DWM compositor/desktop uses is almost entirely explicit sync. This is why all of the graphics drivers had to be rewritten in Vista era and it was also the same time that NVidia recoded their entire driver to be explicit sync.

Just look at the WDDM misses a bit of the stack. There is a DirectX kernel mode driver made by Microsoft. This shared Microsoft kernel mode driver that is doing implicit sync. DX10 and DX11 that Vista and 7 have is pure implicit sync. DWM in Vista and 7 are written in DX10/DX11 so implicit sync. So vista timeframe the DWM compositor is not explicit sync neither is the Windows 7 time frame.

Microsoft wanted all the drivers explicit sync in the Vista time frame because they were forwards looking and they wanted to remove the differences in implementation of the implicit sync so that the implicit sync was correctly integrated with the kernel scheduler.

And in case its not clear, all of the equivalent and relevant parts of the Windows graphics stack are explicit sync otherwise the NVidia driver (which is cross platform driver that only supports completely explicit sync) wouldn't even work on Windows.

This is just you ignoring what Windows does. The Linux world is missing a generic explicit sync to implicit sync in kernel space. This also would require a generic interface from all kernel drivers of explicit sync. This is what you keep on Missing. Windows has kernel mode implicit sync done by Microsoft. Remember what you wrote that you can implement implicit sync on explicit sync this is true. The problem is to implement implicit sync correctly so that CPU usage is correct you need it done kernel side. Microsoft does it kernel side. Nvidia driver lacking it kernel side. There need to be a solution for kernel side implicit sync with Linux.

mdedetrich there is a miss alignment in Windows between when drivers have to provide explicit sync and when the stack of windows really is running in explicit sync. DX10, DX11 demanded by the WDDM driver that it be explicit sync when they are implicit sync but this is so Microsoft can implement there own version of implicit sync in kernel space and make the implicit sync identical between implementations. This was so Intel, AMD and Nvidia implicit sync did not behave differently yes this was a cause of dx9 game performance issues in Windows XP.

Microsoft with vista was not after to turn the complete stack explicit sync they were after to get a dependable implicit sync. It DX12 or Windows 10 when Microsoft really goes explicit outside kernel space in a big way.

OpenGL obviously need to be implicit but that isn't what is talked about here.

This is where you need to think. implicit sync to work exactly right need kernel mode code. If Nvidia is not going to implement explicit sync in their driver there need to be another driver that stacks on top of the Nvidia driver and implements implicit sync in kernel space like Microsoft has done.

The problem here is that implicit sync due to need scheduler integration to work right has to be implemented by someone kernel side. AMD and Intel developers at different times have talked about having the possibility of a generic implicit sync on explicit sync in kernel space of Linux like Microsoft has of course this would not have helped nvidia while their driver was closed source.

[agd5f]

is there any short term solutions though? pardon my bluntness, but if we are relying on wayland related things. it's anyone guess as to how long it may take. and even then, who knows if DEs will even play nice with it.

There is no generic way to add support to all wayland compositors. You'll need to add support for a specific feature to each one.

[oiaohm]

Oh todo after 10 years.. nice. After I look at definitions etc. I cannot find contibutors list. Fuck Nvidia, I haven't seen even "AMD" being mentioned there. Did Wayland had some experimental period with potential invalidating wrong stuff? No. Was there 5 years period like Rust to remove wrong stuff? Heck Vulkan had Mantle before, Vulkan had 2 year period for just raytracing extension etc.

Because for the core Wayland there really was not a contributors list. Individual extensions to wayland added after you find contributor list. The reality here is early Wayland Nvidia and AMD... fairly much leave it all to a intel funded developer. Core opengl is written by one developer from SGI as well. Core Vulkan is written by one developer from LunarG fund by Valve using Intel open hardware specifications to make first version this is Vulkan 1.0. Nvidia and AMD involvement with Vulkan does not really start until Vulkan 1.1 extensions.

There is a repeating trend here piotrj3. Yes the first X11 protocol standard is also written by 1 developer from 1 company at the time. Cooperating between companies on this stuff only really start in extensions in 90%+ of cases.

Basically you did not compare apples with apples. You compared a apple and a orange was asking why is this different. Wayland core being 1 developer from 1 company is status normal that majority of stuff is made this way. Rust having diverse multi developer input is insanely rare.

Oh also when Nvidia did complain about GBM did anyone took that into account? No. Wayland honestly by itself is not that big issue (somehow, but I would consider it very lucky), but buffer managment is.

When Nvidia did complain about GBM they implement eglstreams that basically does not work right. KDE lead developer forces Nvidia to provide their own developer and Nvidia developer finds out eglstreams does not work right and then finally Nvidia decide to implement GBM support. Now as they implement dmabuf/GBM support they now start complaining about GBM sync requirements. This is a long time latter after GBM is already in heavy use that Nvidia starts complaining about GBM sync requirements.

eglstreams could have been good. Nvidia missed implicit sync in eglstreams. Nvidia missed how Microsoft implemented implicit sync and tried to make everything explicit sync eglstreams proceeds to fall apart. The Nvidia provided developer to KDE found over and over again the eglstreams backend would over consume CPU vs GBM, You had that the buffers are not per application with eglstreams as well. Both differences cause eglstreams to be failure. People saying the stack should support explicit sync misses what when wrong with Nvidia and eglstreams. Nvidia still has not learnt from their mistake here. Implicit sync support is not optional. You attempt not to have implicit sync support things go horrible wrong.

I am not saying that the Linux kernel explicit sync cannot be better.

When someone complains about something then proceeds to show you something that does not in fact work so you not ignore their point of view.

Buffer management is a big issue. So is making sure that you sync solution for buffers does not over consume CPU time. The catch here implicit sync saves you CPU time in particular use cases and explicit sync saves you cpu time in other use cases. The reality is we need a GPU sync equal on the CPU side to a futex that is halfway between both and yes this still requires kernel mode support for waiting.

piotrj3 is GBM a kernel mode feature the answer is no its in fact abstraction on top of linux kernel direct render manager and dmabuf from mesa3d. Historically Nvidia has not wanted to work with developers working on Mesa or the Direct rendering manager in the Linux kernel instead been implementing their own unique solution for a lot of hardware.

piotrj3 GBM not being want Nvidia wants makes sense when you see level of Nvidia cooperating with Mesa over the years.

Not sharing firmware so that open source developers could make their own drivers for Nvidia has limited the feedback into the core Linux stack on what Nvidia hardware needs as well.

https://blog.martin-graesslin.com/blog/2016/09/to-eglstream-or-not/

Nvidia not being part of the Linux core graphics stack development is another big problem. Yes been resulting in two complete split code paths.

Implicit sync need to be how are we going to implement it. Are we following Microsoft route of a generic version of implicit sync shared between all graphics drivers or do we stick to implicit sync being implemented per driver. Or do we do a mix of both.

Yes shared implementation between all graphics drivers with Linux kernel license that most likely mandates the kernel mode driver be open source.

[Quackdoc]

There is no generic way to add support to all wayland compositors. You'll need to add support for a specific feature to each one.

Understandable but depressing, thanks for the enlightenment, guess I will have to wait until wayfire gets a more fleshed out ecosystem

[oiaohm]

There is no generic way to add support to all wayland compositors. You'll need to add support for a specific feature to each one.

Not quite features that can be implement in wlroots covers all Wayland compositors based on wlroots. There are features that can be added to libwayland that also end up covering the majority.

This depends on the feature how many wayland compositors it need to be implemented for.

There is no generic way to add a feature to X11 covering all X11 servers either. But the was ways to cover the majority. The majority in the majority of cases with wayland is mostly implement 3 times
1) gnome
2) Kde
3) wlroots.

So not ideal but not absolutely horrible either.

[vtcpld]

This is misleading, WDDM which is the core part of the Windows graphics display driver that the DWM compositor/desktop uses is almost entirely explicit sync. This is why all of the graphics drivers had to be rewritten in Vista era and it was also the same time that NVidia recoded their entire driver to be explicit sync.

In Linux the equivalent of WDDM is largely implicit sync. DWM is just the compositor so obviously it makes sense for that to have implicit sync but the underlying driver of it (WDDM) is almost entirely explicit sync.

Specifically with Wayland it does apparently support explicit sync but no on can verify/use this because underlying Linux graphics stack doesn't even support proper explicit sync.

I don't know whether you are being daft or deliberately deceitful to try and convince Linux fanboys that its not really a problem but when people such as myself are saying that Linux is missing implicit sync, we don't mean that 100% of Linux's graphics stack needs to be implicit sync. We mean that all of the lower level components that basically pass around data between eachother needs to use explicit sync. Compositors that are actually the "final step" when it comes to drawing the interface or user facing implicit sync API's such as OpenGL obviously need to be implicit but that isn't what is talked about here. With Linux when we are talking about parts that need explicit sync we are talking things such as KMS/GBM/Wayland and the other relevant moving parts (such X/XWayland/Glamor etc etc).

And in case its not clear, all of the equivalent and relevant parts of the Windows graphics stack are explicit sync otherwise the NVidia driver (which is cross platform driver that only supports completely explicit sync) wouldn't even work on Windows. Thats the critical part. I have no idea why people are being so defensive about Linux here, just admit that there is a problem and work towards a solution instead of trying to just argue out of it and blame everything on NVidia because its convenient to do so. Linux isn't perfect and although it largely beat the other OS's when it comes to server/backend, with desktop in comparison its quite immature and hence it needs a lot of work for a variety of reasons (this being one of them). Just be honest about it.

The low level Linux graphics infrastructure (DRM, the equivalent layer to WDDM) does support explicit synchronization through DRM syncobjs/sync_files, otherwise Linux Vulkan drivers would run at a fraction of the performance they currently run at, since Vulkan requires explicit synchronization everywhere.

The real problem here is Mesa OpenGL basically enforcing implicit synchronization everwhere, combined with the lack of usable implicit sync/explicit sync interop. This means fully explicit synchronization requires Vulkan drivers implementing driver specific hacks to inject the explicit fence into the DMA-BUF to be sent to the compositor, because the compositor can't do proper explicit synchronization without Vulkan, but if the compositor is written in Vulkan there's no way to tell the Vulkan driver which fence to wait on.

The kernel DMA-BUF implicit sync interop patchset that just recently got merged into drm-misc-next (https://lore.kernel.org/all/20220608...lekstrand.net/) will provide a final solution to the implicit sync problem on the Linux desktop. With it, Wayland (and maybe X-Windows too, but I don't think anybody cares about X-Windows anymore) compositors and applications can get the benefit of full explicit synchronization without any change to the Wayland protocol, because the application can simply tell the kernel to insert the fence into the DMA-BUF object that is sent to the compositor, and the compositor can simply extract the sync_file object out of the DMA-BUF for explicit synchronization.