Vulkan: Game freezes if window vsync mode is set to/from mailbox during runtime

[BluesM18A1]

Godot version

4.0 RC3 (update: tested on 4.0.2 stable, still persists)

System information

EndeavourOS Linux, AMD Radeon 5700XT, Vulkan

Issue description

This may be considered a duplicate of #70837 or #65391 since they occur under similar circumstances, so feel free to close this if it's deemed too similar, but at any rate here is my experience:
Mailbox vsync appears to work just fine if set with the project settings and left alone.
However if you have vsync options available in-game, I find that all of them are able to be changed at runtime without a hitch, except if your project settings change from something else to mailbox, or if your project settings are set to mailbox and you change to something else.

The issue does not seem to occur when using the OpenGL (compatibility) renderer.

Steps to reproduce

-New scene (any type seems to work)
-Attach script to root node, GDscript or C# works (I am using GDscript for this example, C# script is available in the minimal reproduction project)

if you put the line DisplayServer.window_set_vsync_mode(DisplayServer.VSYNC_ENABLED)
in the _ready function, the game freezes at the splash screen.

If you do something like the following to get it to happen during _process...

var changed = false;

func _process(delta):
	if (!changed):
		DisplayServer.window_set_vsync_mode(DisplayServer.VSYNC_ENABLED)
		changed = true
	pass

Then you have a rapidly flickering and garbled screen like the following screenshot, and the following error message

E 0:00:00:0332   main.gd:7 @ _process(): Condition "swapchainImageCount != sp_image_count" is true. Returning: ERR_BUG
  <C++ Source>   drivers/vulkan/vulkan_context.cpp:1975 @ _update_swap_chain()
  <Stack Trace>  main.gd:7 @ _process()

Minimal reproduction project

BugTester.zip

[Calinou]

I can't reproduce this on 4.0.rc adbabfb (Linux, GeForce RTX 4090 with NVIDIA 525.89.02), but I also get this warning anyway:

I'm surprised the NVIDIA driver doesn't support mailbox V-Sync on Linux. I'm fairly sure it did at some point…

The issue does not seem to occur when using the OpenGL (compatibility) renderer.

The OpenGL driver probably won't be able to support Adaptive and Mailbox modes (as these are not exposed in a standard fashion with that API), but it should support Enabled and Disabled already from my testing.

[BluesM18A1]

I can't reproduce this on 4.0.rc adbabfb (Linux, GeForce RTX 4090 with NVIDIA 525.89.02), but I also get this warning anyway:

I'm surprised the NVIDIA driver doesn't support mailbox V-Sync on Linux. I'm fairly sure it did at some point…

The issue does not seem to occur when using the OpenGL (compatibility) renderer.

The OpenGL driver probably won't be able to support Adaptive and Mailbox modes (as these are not exposed in a standard fashion with that API), but it should support Enabled and Disabled already from my testing.

I took some time to test swapping vsync modes on another computer I had running Windows 10 and an Nvidia GTX 765M, now that you brought nvidia cards to mind.
Swapping to and from mailbox seems to work without a hitch, but for some reason cannot simply disable vsync (falls back to "enabled" upon loading). Looks like anything is possible with different driver and hardware configurations.

[LyonSyonII]

Happens to me as well, also with an AMD GPU (6700 XT) on Linux.

Changing to OpenGL (compatibility) fixes the problem.

[BluesM18A1]

UPDATE:

Out of curiosity I tried using Wayland instead of X11 to see if that affects the issue since wayland has gotten big updates recently.

Instead of having garbage artifacts on screen like my screenshot, I got this exact warning message you received earlier.
Looks like it could be either driver issues, poor handling on the window manager's end, or a mixture of both.

[Riteo]

@BluesM18A1

Looks like it could be either driver issues, poor handling on the window manager's end, or a mixture of both.

Wayland currently only supports vsync for... many reasons. IMMEDIATE support is coming though: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18268

This is intended behaviour and (perhaps surprisingly :P) not NVIDIA's fault.

[BluesM18A1]

@BluesM18A1

Looks like it could be either driver issues, poor handling on the window manager's end, or a mixture of both.

Wayland currently only supports vsync for... many reasons. IMMEDIATE support is coming though: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18268

This is intended behaviour and (perhaps surprisingly :P) not NVIDIA's fault.

Ok, so this could be partially a driver and X11 issue since everything works more or less as intended on Wayland (by that of course I mean currently, V-Sync is always forced-on, which is incredibly stupid )
Now that I've seen the arguing in here over the changes being made (pretty sure one of those guys is a valve dev working on gamescope), I shouldn't be surprised that any V-Sync related developments are going to be slow.

I don't expect this issue to be fixed for X11 since the project has hardly seen any maintenance these days and is probably gonna be abandoned soon.

Whatever the case, I'll close this issue if upstream changes from either window manager fixes it, moderators might want to close this anyways if we can confirm for absolute sure the issue isn't one with the engine itself.

EDIT: After updating some of the software on my system (Not any Godot update specifically, as far as I can tell), the freezing/garbled screen happens even in a wayland environment. Is it now using xwayland? was it supposed to use xwayland from the start? if so, how was I able to get different behavior out of it before? much to figure out

[BluesM18A1]

Mailbox vsync appears to work just fine if set with the project settings and left alone.

Upon closer inspection, this no longer seems to be the case (probably never was, going back and checking version 4 RC3 from my original tests again). You either get the freeze+garbled screen or a crash shortly after launching the game. Should the title of this issue be edited accordingly to make it simpler?

[Riteo]

@BluesM18A1 for some reason I noticed your other message just now.

since everything works more or less as intended on Wayland (by that of course I mean currently, V-Sync is always forced-on, which is incredibly stupid )

It's not incredibly stupid, it has its reasons, but once https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18268 is merged, Vulkan will report other modes as available transparently. AFAIK the protocol is meant primarily for drivers like mesa, not for clients.

Now that I've seen the arguing in here over the changes being made (pretty sure one of those guys is a valve dev working on gamescope), I shouldn't be surprised that any V-Sync related developments are going to be slow.

The protocol got already accepted, the thing isn't at risk: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/65

Whatever the case, I'll close this issue if upstream changes from either window manager fixes it, moderators might want to close this anyways if we can confirm for absolute sure the issue isn't one with the engine itself.

Generally, we keep problems that might not be entirely the engine's fault but that still happen so that confused people still have a place in which to converge.

Is it now using xwayland? was it supposed to use xwayland from the start?

AFAIK, yes. Especially if you could set anything other than V-Sync, since I recall that proper XWayland support required the Xorg drivers.

Should the title of this issue be edited accordingly to make it simpler?

No idea, if other people can replicate the original one but not the "new" one I think that it should stay like this.