Implement Explicit Sync

[amshafer]

This implements the explicit sync linux-drm-syncobj-v1 protocol for EGL.

This pull request exists to publicize our EGL implementation of explicit sync that we have been using to test the Mutter and Xwayland implementations. Erik and I have done a good amount of testing with this so it's in a fairly polished state and isn't just a first prototype.

Currently the code as proposed here will not build or run on existing drivers. To build it would need an updated wayland-protocols that contains linux-drm-syncobj, and to run it would require a newer (next upcoming release) NVIDIA driver that has the necessary prerequisites. Whenever this lands the minimum required NVIDIA driver version will also be bumped.

This change finally does away with the background threads which have given us issues in the past. Both the damage and the buffer release threads are disabled when explicit sync is supported.

---

Most of this change involves wayland-protocol handling boilerplate. The protocol works by allowing the creation of timelines (i.e. DRM syncobjs) and per-surface states. We can then specify acquire and release points during our surface state configuration which will tell the compositor when it can access the buffer or notify us when it is finished accessing the buffer.

Sync point signaling takes place during acquire_surface_image. We choose our two release point values and send them to the compositor. In the acquire case, the EGLSync will be created first and will be populated with a fence representing the GPU work. We can extract its syncfd and import it at the acquire point. We choose the release point during image acquisition, but don't actually create an EGLSync for it until later when the compositor has added a fence to the release point. We check if this has taken place after every surface commit.

Separate timelines are used for the acquire and release points. Each stream image will have its own timeline, otherwise our signaling of acquire points would implicitly signal the still-pending release points.

[ptr1337]

Hi,

Thanks for this PR! Looking forward for the driver release. It seems to not build currently, even if wayland-protocols is patched with https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/90 .

Log:

[18/29] Compiling C object src/libnvidia-egl-wayland.so.1.1.13.p/wayland-eglsurface.c.o
FAILED: src/libnvidia-egl-wayland.so.1.1.13.p/wayland-eglsurface.c.o 
cc -Isrc/libnvidia-egl-wayland.so.1.1.13.p -Isrc -I../egl-wayland/src -I../egl-wayland/include -I../egl-wayland/wayland-egl -Iwayland-eglstream -Iwayland-drm -I/usr/include/EGL -I/usr/include/libdrm -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -std=gnu99 -Wall -Werror -fvisibility=hidden -DWL_HIDE_DEPRECATED -Wno-pedantic -march=x86-64 -O3 -pipe -fno-plt -fexceptions -pthread -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection -flto=auto -fPIC -MD -MQ src/libnvidia-egl-wayland.so.1.1.13.p/wayland-eglsurface.c.o -MF src/libnvidia-egl-wayland.so.1.1.13.p/wayland-eglsurface.c.o.d -o src/libnvidia-egl-wayland.so.1.1.13.p/wayland-eglsurface.c.o -c ../egl-wayland/src/wayland-eglsurface.c
../egl-wayland/src/wayland-eglsurface.c:27:10: fatal error: linux-drm-syncobj-v1-client-protocol.h: No such file or directory
   27 | #include "linux-drm-syncobj-v1-client-protocol.h"
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
[19/29] Compiling C object src/libnvidia-egl-wayland.so.1.1.13.p/wayland-egldisplay.c.o
FAILED: src/libnvidia-egl-wayland.so.1.1.13.p/wayland-egldisplay.c.o 
cc -Isrc/libnvidia-egl-wayland.so.1.1.13.p -Isrc -I../egl-wayland/src -I../egl-wayland/include -I../egl-wayland/wayland-egl -Iwayland-eglstream -Iwayland-drm -I/usr/include/EGL -I/usr/include/libdrm -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -std=gnu99 -Wall -Werror -fvisibility=hidden -DWL_HIDE_DEPRECATED -Wno-pedantic -march=x86-64 -O3 -pipe -fno-plt -fexceptions -pthread -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection -flto=auto -fPIC -MD -MQ src/libnvidia-egl-wayland.so.1.1.13.p/wayland-egldisplay.c.o -MF src/libnvidia-egl-wayland.so.1.1.13.p/wayland-egldisplay.c.o.d -o src/libnvidia-egl-wayland.so.1.1.13.p/wayland-egldisplay.c.o -c ../egl-wayland/src/wayland-egldisplay.c
../egl-wayland/src/wayland-egldisplay.c:35:10: fatal error: linux-drm-syncobj-v1-client-protocol.h: No such file or directory
   35 | #include "linux-drm-syncobj-v1-client-protocol.h"
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
[28/29] Compiling C object src/libnvidia-egl-wayland.so.1.1.13.p/wayland-eglstream-server.c.o
ninja: build stopped: subcommand failed.
==> ERROR: A failure occurred in build().
    Aborting...

Used wayland-protocols PKGBUILD: https://github.com/CachyOS/CachyOS-PKGBUILDS/blob/master/nvidia-explicit-sync/wayland-protocols/PKGBUILD

Edit: Im currently also using the explicit sync patches for xorg-xwayland, and they are compiling fine. So I think its something wrong iwth the detection of the header.

[amshafer]

Thanks, sorry I had missed the meson bits for this. With the updated version it should build again.

Note that it still isn't guaranteed to work on currently released drivers, so your mileage may vary.

[ptr1337]

Thanks, sorry I had missed the meson bits for this. With the updated version it should build again.

Note that it still isn't guaranteed to work on currently released drivers, so your mileage may vary.

Thanks for your fast response. It is working now. :)

We just want to have everything ready for the upcoming driver release.

[JPLeBreton]

a newer (next upcoming release) NVIDIA driver that has the necessary prerequisites.

Can we expect this in the first non-beta 550 release, or the major version # bump after that?

[TsunamiMommy]

a newer (next upcoming release) NVIDIA driver that has the necessary prerequisites.

Can we expect this in the first non-beta 550 release, or the major version # bump after that?

Based on what I'm seeing here, it is the EGL_ANDROID_native_fence_sync extension that is missing from the current stable 535 drivers and the 545.23.06/08 drivers. 545.29.02/06 and 550.40.07 have it available if you set nvidia-drm.modeset=1. Somebody here could corroborate it, but that is what I'm seeing looking at all related mr's.

[notpentadactyl]

[...] and to run it would require a newer (next upcoming release) NVIDIA driver that has the necessary prerequisites.

is this 550.54.14 (just released)?

[erik-kz]

Thanks Austin, the updated code looks good to me. We'll wait until https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/90 is merged before we merge this, though, just to be safe.

[MachineMuse]

Thanks Austin, the updated code looks good to me. We'll wait until https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/90 is merged before we merge this, though, just to be safe.

It's done! 🎉

[ptr1337]

Very nice, finally things are going forward.

@erik-kz Is there any ETA on the 555 driver? Will this be delayed until the xorg-xwayland / wayland-protocols release is available?

[erik-kz]

Is there any ETA on the 555 driver?

Beta release is currently targeted for May 15. It will include support for both the Wayland explicit sync protocol for EGL applications and the counterpart X11 explicit sync protocol for GLX and Vulkan X11 applications.

Will this be delayed until the xorg-xwayland / wayland-protocols release is available?

Both protocols will only be used if the server advertises support for them, otherwise it will just be dead code. So there's no need for a delay. Older compositor or Xwayland versions will continue to work as they currently do.

[dylanmtaylor]

Is there any ETA on the 555 driver?

Beta release is currently targeted for May 15. It will include support for both the Wayland explicit sync protocol for EGL applications and the counterpart X11 explicit sync protocol for GLX and Vulkan X11 applications.

Is there any chance the explicit sync protocol fixes will be backported to 550?

[Fxzzi]

Is there any chance the explicit sync protocol fixes will be backported to 550?

We can only hope. It seems possible but only if Nvidia is willing to. Backporting to 550 would help out so many people it's not even funny.

I have friends building PCs who went with AMD instead after seeing the troubles I was going through with this stuff lol.

Other stuff like multimonitor gsync can wait tbh, for 555 or maybe later if Nvidia hasn't implemented it yet. But we need WORKING DRIVERS at the least.

p.s. by multimonitor gsync I am talking about having one monitor not gsync and the main one gsync and it still not working

Overall, I have hope that Nvidia will backport to 550. They themselves have seen the lengthy wait time required for all this stuff to merge, and now that it's finally going through we can only hope they can empathize with their users who've been stuck for months either on older drivers or on objectively inferior drivers.

[AndrejsK]

For this driver support to do anything useful, XWayland support for the protocol has to be included in 24.1 and that has to make it to distros. This might take longer than the 555 driver anyway, even on bleeding edge distros.

Here's the XWayland MR: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/967

[Fxzzi]

For this driver support to do anything useful, XWayland support for the protocol has to be included in 24.1 and that has to make it to distros. This might take longer than the 555 driver anyway...

Completely agree here. But these changes can already be used by installing a patched version of XWayland. I think most if not all people experiencing this issue will be willing to compile from source for a bit until a release. Some distros provide patched versions, AUR packages exist.

For those not willing to install from source, it's exactly like you said. It will have ZERO effect. Nvidia backporting the explicit sync patches will only bring good.

[oscarbg]

Is there any ETA on the 555 driver?

Beta release is currently targeted for May 15. It will include support for both the Wayland explicit sync protocol for EGL applications and the counterpart X11 explicit sync protocol for GLX and Vulkan X11 applications.

@erik-kz first, sorry.. I know this is not the place to ask.. but want to ask to NV (VK) devs if NV plans on supporting extension VK_KHR_incremental_present.. was testing Zink Vulkan profile in NV 550.67 driver and I found:

Testing profile VP_ZINK_gl21_baseline.
Unsupported extension: VK_KHR_incremental_present
Unsupported feature condition: VkPhysicalDeviceBorderColorSwizzleFeaturesEXT::borderColorSwizzleFromImage == VK_TRUE
[RESULT] GPU: NVIDIA GeForce RTX 4070, Profile: VP_ZINK_gl21_baseline, supported: no

for full findings, see: https://gitlab.freedesktop.org/mesa/mesa/-/issues/10879#note_2337928

seems Zink "requires" since very recently (https://www.phoronix.com/news/Zink-Partial-Updates-Damage) and RADV and ANV Mesa drivers support since 2017 https://www.phoronix.com/news/Vulkan-Mesa-Incr-Present

EDIT: Phoronix: "The Zink driver in turn is relying on Vulkan's VK_KHR_incremental_present extension that allows an application to specify a list of rectangular modified regions of each image to present."

EDIT2: forgot to ask about borderColorSwizzleFromImage but that may be a HW limitation to expose on NV GPUs? Unsupported feature condition: VkPhysicalDeviceBorderColorSwizzleFeaturesEXT::borderColorSwizzleFromImage == VK_TRUE

[erik-kz]

As far as I can tell, VK_KHR_incremental_present is not a strict requirement for zink. It will use it if it's available for the potential performance improvement but it also should work without it.

We don't have any plans at the moment to add support for it, but that could change. For the Wayland WSI in particular, it looks like the effort wouldn't be all that large so maybe it's worth doing.

VkPhysicalDeviceBorderColorSwizzleFeaturesEXT::borderColorSwizzleFromImage is indeed unsupported do to hardware limitations. I'm don't think I'm allowed to disclose any details beyond that.

[oscarbg]

thanks for the information Erik!

On Mon, Mar 25, 2024 at 7:51 PM Erik Kurzinger @.***> wrote:

As far as I can tell, VK_KHR_incremental_present is not a strict requirement for zink. It will use it if it's available for the potential performance improvement but it also should work without it.

We don't have any plans at the moment to add support for it, but that could change. For the Wayland WSI in particular, it looks like the effort wouldn't be all that large so maybe it's worth doing.

VkPhysicalDeviceBorderColorSwizzleFeaturesEXT::borderColorSwizzleFromImage is indeed unsupported do to hardware limitations. I'm don't think I'm allowed to disclose any details beyond that.

— Reply to this email directly, view it on GitHub https://github.com/NVIDIA/egl-wayland/pull/104#issuecomment-2018681608, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFDM6PHHU6V63QQ7IV3RETY2BWZ7AVCNFSM6AAAAABDTKIEQOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMJYGY4DCNRQHA . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[jrelvas-ipc]

Beta release is currently targeted for May 15. It will include support for both the Wayland explicit sync protocol for EGL applications and the counterpart X11 explicit sync protocol for GLX and Vulkan X11 applications.

@erik-kz I'm assuming this means explicit sync for Wayland vulkan programs will only be coming with a later driver release? That's something that needs to be handled on Nvidia's Vulkan Wayland WSI implementation, right?

(Sorry for replying to a 2 week old comment on a merged PR)

[erik-kz]

Correct. Explicit sync for the Vulkan Wayland WSI is implemented but I haven't back-ported it to the 555 branch (which is currently undergoing QA testing). At this point I think it would be a bit too late to do that given the size of the change. So it will not be available until the following release, 560.

[Fxzzi]

Thank you for being open about these changes to end users. You have no idea how much it helps. Good luck to you and your team for the QA testing!

[jthoward64]

For this driver support to do anything useful, XWayland support for the protocol has to be included in 24.1 and that has to make it to distros. This might take longer than the 555 driver anyway, even on bleeding edge distros.

Here's the XWayland MR: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/967

Merged

[gilvbp]

Correct. Explicit sync for the Vulkan Wayland WSI is implemented but I haven't back-ported it to the 555 branch (which is currently undergoing QA testing). At this point I think it would be a bit too late to do that given the size of the change. So it will not be available until the following release, 560.

Hi Erik, thank you very much for your delivery and commitment. Could Nvidia devs now focus their work on this feature? https://github.com/NVIDIA/egl-wayland/issues/91 (multi-mosaic on Wayland) Many people will remain on x11 because they use more than 4 monitors.

[jthoward64]

Correct. Explicit sync for the Vulkan Wayland WSI is implemented but I haven't back-ported it to the 555 branch (which is currently undergoing QA testing). At this point I think it would be a bit too late to do that given the size of the change. So it will not be available until the following release, 560.

Hi Erik, thank you very much for your delivery and commitment. Could Nvidia devs now focus their work on this feature? #91 (multi-mosaic on Wayland) Many people will remain on x11 because they use more than 4 monitors.

I think the forums are probably a better venue for this kind of discussion

[mrdev023]

@erik-kz I have a problem with kwin, i think is a bug NVIDIA side but i don't know where make an issue. I write a post in developer forum but i think is not appropriate because is for developer.

[jthoward64]

@erik-kz I have a problem with kwin, i think is a bug NVIDIA side but i don't know where make an issue. I write a post in developer forum but i think is not appropriate because is for developer.

The forum, KWin issue tracker, another issue on this GitHub...really anywhere other than a completely unrelated pull request

[erik-kz]

I write a post in developer forum but i think is not appropriate because is for developer.

You don't need to be a developer to post on the forum. Anyone is allowed to do so,

[ryzendew]

Correct. Explicit sync for the Vulkan Wayland WSI is implemented but I haven't back-ported it to the 555 branch (which is currently undergoing QA testing). At this point I think it would be a bit too late to do that given the size of the change. So it will not be available until the following release, 560.

that is going to piss off alot of people and make nvidia look even worse .. i know you work your ass off already but people won't see it like that .. goodluck i hope it all works out some how.

[erik-kz]

that is going to piss off alot of people and make nvidia look even worse .. i know you work your ass off already but people won't see it like that .. goodluck i hope it all works out some how.

Are there really that many native Wayland Vulkan applications out there right now? I didn't think there were. Of course, that will definitely change in the future, especially when Wine switches to using Wayland.

And besides, current drivers already have a work-around in the Vulkan Wayland WSI to avoid corruption in the absence of explicit sync. Essentially doing a vkQueueWaitIdle before presenting. This does have a significant performance cost, but at least it ensures correctness.

[jrelvas-ipc]

Are there really that many native Wayland Vulkan applications out there right now? I didn't think there were. Of course, that will definitely change in the future, especially when Wine switches to using Wayland.

Outside of one or two outliers, no not really. (And even then, X11 Vulkan is also typically supported).

As far as the migration to Wayland Vulkan goes, SDL3 is only going to use its Wayland backend by default once the Wayland FIFO protocol is finalized: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/256

I think there might be some confusion here @ryzendew - Explicit sync for Vulkan programs will also work on Wayland sessions. They just need to be running with XWayland!

Edit: In fact, it's only applicable for Xwayland... a real X11 session still won't be using this protocol.

[gregorburger]

Are there really that many native Wayland Vulkan applications out there right now? I didn't think there were. Of course, that will definitely change in the future, especially when Wine switches to using Wayland.

At least gtk 4.15 unstable release switched to vulkan on wayland. https://gitlab.gnome.org/GNOME/gtk/-/raw/main/NEWS?ref_type=heads

[jrelvas-ipc]

GTK 4.15 is a development release. It does not ship on any production distributions (Ubuntu, Fedora, OpenSUSE, etc.)

They've switched to Vulkan explicitly to get some early testing in and determining if it's ready as a default for 4.16 (the next production release).

GTK 4.16 is planned to release in September. NVIDIA 560 will likely be available earlier.

[benjamin-otte]

Is there a generic way for apps who can switch between Vulkan and GL - like GTK - to detect if a driver would benefit from selecting GL over Vulkan?

Or do you think GTK should do driver detect and hardcode an OpenGL preference on pre-560 Wayland?

[jrelvas-ipc]

GTK's developers have said that they're not interested in a blacklist. The way things stand right now is - Vulkan will either be a default for gtk 4.16 (when running on a wayland compositor)... or it won't.

[matthiasclasen]

You are talking to GTK developers right now :)

[jjones0293]

Correct. Explicit sync for the Vulkan Wayland WSI is implemented but I haven't back-ported it to the 555 branch (which is currently undergoing QA testing). At this point I think it would be a bit too late to do that given the size of the change. So it will not be available until the following release, 560.

Apologies if this would more suited for the NVIDIA forum. I commented on a thread there also.

Do you think there's any chance it could be back-ported post release, or released as the only feature in 560, so it could be quicker perhaps?

I feel like Wayland is really close to being stable as daily driver with NVIDIA hardware, but the explicit sync issue seems like the main blocker. And great work by the way, seeing a lot of progress over the last several years.

[ptr1337]

@jjones0293 The Vulkan WSI Implentation is barely used by anything right now, besides if you have play games with the native wine wayland driver. Until the wine wayland driver will be really fully useable and as default for wine, until NVIDIA is already shipping the Vulkan WSI Implementation.

With the 555 driver explicit sync will ship everything youre looking for.

[mbwilding]

Is there any ETA on the 555 driver?

Beta release is currently targeted for May 15

Hey @erik-kz, is this ETA still accurate?

[ptr1337]

Its 9 AM in California, so please wait the day. And then people wonder, why normally NVIDIA does not give such informations out.

Edit: Also ETA, means they expect to be release there. If they found any issues in QA, which needed to be verified and tested again, it could delay.

[kakra]

I would like to add to that, if so what time because today is May 15th?

The E in ETA already says it: "estimated" - the time is irrelevant. And it could be tomorrow in your timezone. We are given ETAs (and I appreciate that), and then people start pinning that down to the minute precision and request arrival (not pointing at you, that's a general problem, your question was probably not badly intended).

Please don't stop giving such information - but maybe be a bit more vague like "by end of week/month" and add some buffer to your internal ETA. If it arrives early then, everyone will be happy. :-)

Thanks.

[Arcitec]

@erik-kz I know this isn't the appropriate place to say this, but thank you so freaking much for everything you do, you absolute monster of a genius! I saw you fighting Xwayland for 2+ years to get them to accept Explicit Sync. I saw you fighting years ago with your presentations at XDC to get X to accept Explicit Sync. You have been fighting non-stop for us, and I deeply appreciate everything you've been doing for Linux.

The thing is, NVIDIA was right. As usual (you were right about EGL vs GBM too, even if GBM has gotten better with time). Explicit Sync is objectively the best way to synchronize rendering. But people were so happy to lazily sit in the status quo, babbling about "we already have Implicit Sync, so who cares..." all these years. There's no doubt that explicit is better. Windows uses Explicit Sync since Windows 7 or Vista. macOS uses explicit sync. Google wrote their own renderer for Android to use Explicit Sync (since implicit/wayland/x11 was so awful). I've seen both AMD and Intel engineers on Linux mailing lists, expressing how they wished Linux used Explicit Sync since it simplifies drivers and improves performance.

And yet it always fell to NVIDIA to push this thing forwards. And to finally see the day arriving, when all your hard work pays off, is amazing. Your hard work and genius has not gone unnoticed. Thank you so much - to you and everyone involved in finally giving Linux the fast and sane Explicit Sync rendering that it has needed for so long!

[RetroGamerBobby]

Its 9 AM in California, so please wait the day. And then people wonder, why normally NVIDIA does not give such informations out.

Edit: Also ETA, means they expect to be release there. If they found any issues in QA, which needed to be verified and tested again, it could delay.

Thank You, that answers my question I had earlier.

[cubanismo]

Hey @erik-kz, is this ETA still accurate?

To save Erik from being the bad guy, no, this is no longer accurate. Sorry. We know you're all excited. We're excited too. We're on it, sit tight, it's coming very soon!

Release dates generally shift around over time (It looks like Erik shared that date 2 months ago) and the above comments are indeed why we don't generally share specific target dates. Note this is a closed/merged pull request, not a driver release announcement/discussion forum.

[jthoward64]

While I really hate it when communication gets stifled, perhaps it's time to lock to collaborators so that people who are subscribed here only get a notification when there's real news from NVIDIA?

[nodgear]

While I really hate it when communication gets stifled, perhaps it's time to lock to collaborators so that people who are subscribed here only get a notification when there's real news from NVIDIA?

This is a merged request, if it's going to be closed then it should be closed to everyone Other than that, this is not the official channel through which nvidia announces releases but rather their forum If anyone is seeking to get a notificaiton, just sub to the nvidia forum section.

I do agree that discussions not related to the explicit sync stuff should be avoided.

Edit: the nvidia forum does not have a post for beta releases, only stable. I'm sorry everyone

[basdp]

Hey @erik-kz, is this ETA still accurate?

To save Erik from being the bad guy, no, this is no longer accurate. Sorry. We know you're all excited. We're excited too. We're on it, sit tight, it's coming very soon!

Release dates generally shift around over time (It looks like Erik shared that date 2 months ago) and the above comments are indeed why we don't generally share specific target dates. Note this is a closed/merged pull request, not a driver release announcement/discussion forum.

It's not that shifting a release date makes someone a bad guy, but the lack of communication and transparency is a bit disappointing. It's not only here that people are anxiously waiting for this much needed fix, also on many subreddits (r/linux, r/linuxgaming, r/nvidia to name a few) people were talking about yesterday being "the day".

We know you do good work and there is a lot going on. We respect that 100%. It's not a problem that it's going to be a little bit more. Please keep us up to date here, or somewhere else if that would be a more approriate place.

Please leave the link here where we can follow along, so we can keep this PR clean from release date discussions.

[hdgetban]

so when is it gonna come out?

[mricewolf0110]

so when is it gonna come out?

just be patient

[birgersp]

so when is it gonna come out?

just be patient

Some update(s) would be nice. Surely the devs/managers have some excpectation of when they will release it.

[hdgetban]

so when is it gonna come out?

just be patient

Some update(s) would be nice. Surely the devs/managers have some excpectation of when they will release it.

I will agree with you I need explicit sync so I can finally use Wayland peacefully with my Nvidia and if explicit sync turns out bad I am gonna hold them hostage in my basement

[jrelvas-ipc]

Some update(s) would be nice. Surely the devs/managers have some excpectation of when they will release it.

I will agree with you I need explicit sync so I can finally use Wayland peacefully with my Nvidia and if explicit sync turns out bad I am gonna hold them hostage in my basement

Last time they gave one, a pull request on Github was flooded because the prediction turned out wrong.

The sheer amount of spam in this PR validates Nvidia's decision of not giving concrete dates.

We've waited several years for explicit sync. A few days or weeks make no difference whatsoever.

Now please - stop sending replies asking for a timeline. It's worthless noise. There are people with notifications enabled for this PR who would like to receive relevant, on-topic information.

Jeez.