Godot: Vulkan: disabling V-Sync not reimplemented yet

[Calinou]

Godot version: Git https://github.com/godotengine/godot/commit/bf7d6de55662d7f4f9e82e69920582cf8ec55375

OS/device including version: Fedora 31, NVIDIA 440.44, GeForce GTX 1080

Issue description: V-Sync is always enabled, even if you disable it in the Project Settings then restart the editor.

Steps to reproduce: Try disabling Display > Window > Vsync > Use Vsync in the Project Settings.

[kuruk-mm]

I'm not a rendering expert. But with a bit of investigation i found Vulkan has different Presentation Modes. So maybe is not like "V-Sync enabled/disabled" is more like "What Presentation Mode do you want?"

Do you have:

• FIFO: is like VSync On (similar to OpenGL's buffer swapping with swap interval of 1)
• IMMEDIATE: is like VSync Off
• MAILBOX
• FIFO RELAXED

Detailed explanation: https://software.intel.com/en-us/articles/api-without-secrets-introduction-to-vulkan-part-2?language=en#_Toc445674479

[giarve]

Following @kuruk-mm comment:

On master we already have VK_PRESENT_MODE_FIFO_KHR as set by default, so that's why V-SYNC is on, and, citing the comments on the code already present in the engine, which were probably taken from Vulkan examples:

// The FIFO present mode is guaranteed by the spec to be supported
// and to have no tearing.  It's a great default present mode to use.

// VK_PRESENT_MODE_IMMEDIATE_KHR is for applications that don't care about
// tearing, or have some way of synchronizing their rendering with the
// display.
// VK_PRESENT_MODE_MAILBOX_KHR may be useful for applications that
// generally render a new presentable image every refresh cycle, but are
// occasionally early.  In this case, the application wants the new image
// to be displayed instead of the previously-queued-for-presentation image
// that has not yet been displayed.
// VK_PRESENT_MODE_FIFO_RELAXED_KHR is for applications that generally
// render a new presentable image every refresh cycle, but are occasionally
// late.  In this case (perhaps because of stuttering/latency concerns),
// the application wants the late image to be immediately displayed, even
// though that may mean some tearing.

My integrated graphics card from intel supports these:

        Present Modes: count = 3
                PRESENT_MODE_IMMEDIATE_KHR
                PRESENT_MODE_MAILBOX_KHR
                PRESENT_MODE_FIFO_KHR

As you can see, a GPU may not support all of them, so a method of fallback should be present (although from the research I've done it was most an issue in the past when video drivers were not updated to follow the specs). Anyways, its possible for a GPU not to get some mode support in its entire life.

Perhaps VSYNC off should be _PRESENT_MODE_IMMEDIATE_KHR_ and if not present, _VK_PRESENT_MODE_FIFO_RELAXED_KHR_ and if not present, _PRESENT_MODE_MAILBOX_KHR_, which in case of not being present any the three, it would fallback to the default guaranteed to exist FIFO. All of this speaking about a disabled VSYNC mode.

I could try to implement it if you confirm this could be a valid idea. We may have to try all of them before jumping to conclusions.

[clayjohn]

@giarve Take a look at the GPUinfo database results for present modes https://vulkan.gpuinfo.org/listsurfacepresentmodes.php

It looks like only FIFO_KHR is guaranteed to be present on a given implementation.