(Vulkan) Add adaptive vsync support

[sonninnos]

Description

Added the ability to use VK_PRESENT_MODE_FIFO_RELAXED_KHR presentation mode, which is basically adaptive vsync like in gl. So when available it sets the same existing flag (only for Windows & X) which shows the same option.

Also made sure that vsync off rather uses VK_PRESENT_MODE_IMMEDIATE_KHR which causes similar tearing as other drivers, and not VK_PRESENT_MODE_MAILBOX_KHR which causes stutter.

Also enabled some useful logging to debug level without having VULKAN_DEBUG defined, such as which presentation modes are available and in use, and in readable text form rather than magic number.

[DEBUG] [Vulkan]: Swapchain supports present mode: FIFO_KHR.
[DEBUG] [Vulkan]: Swapchain supports present mode: FIFO_RELAXED_KHR.
[DEBUG] [Vulkan]: Swapchain supports present mode: MAILBOX_KHR.
[DEBUG] [Vulkan]: Swapchain supports present mode: IMMEDIATE_KHR.
[DEBUG] [Vulkan]: Creating swapchain with present mode: FIFO_KHR.

Unfortunately with FIFO_RELAXED_KHR the screen flashes when fast-forward is toggled, and IMMEDIATE_KHR flashes when menu is toggled, but hopefully those can be sorted later.

I was able to test it a little also under Linux VM, but the results weren't too good since FIFO_RELAXED_KHR was not available, and neither was IMMEDIATE_KHR, and the present modes were presented in reverse order compared to Windows, so we might have to insert some finer logic than the current one to decide which mode should be preferred.

I at least added the requirement of Max Swapchains set to more than 2 (even if it does not come to fruition) for allowing MAILBOX_KHR when it comes before FIFO_KHR. The above log snippet is from Windows, and the order is 2-3-1-0, and in Linux it was 1-2. So perhaps we should process them always in sorted order instead of offered order.

No idea why 16 was/is the maximum count for presentation modes even if there won't be that many..

Please test with proper Linux and debug log level enabled!

[sonninnos]

Changed the MAILBOX case to be a special default fallthrough instead so that it rather gets set than FIFO when vsync is disabled and IMMEDIATE is not available.

[hizzlekizzle]

IMMEDIATE_KHR flashes when menu is toggled, but hopefully those can be sorted later.

I think this might have been why we were using mailbox to being with..?

[sonninnos]

Likely yes.

[hizzlekizzle]

Would that be something that could be set at runtime? Like via an option? I know we need more options like we need additional holes in our heads but this seems like a choice of least-bad results, which some may prefer one over the other.

[sonninnos]

It appears the flashing happens because menu toggle is always setting vsync on and swap interval 1 while menu is alive. We have menu_throttle_framerate which is not actually doing much at the moment, since menu runs unthrottled regardless of that option if menu is not forcing vsync.

So I think we could and should simply harness that throttle option more and only force menu vsync when it is enabled.

Also we still could use at least some kind of limiting when menu_pause_libretro is enabled without throttling and without vsync, since it will draw the menu at maximum rate otherwise, which is very much pointless.

[sonninnos]

That should cover it.

[sonninnos]

Minor addition to also limit menu drawing when running without a core.

Edit: Menu throttling stuff removed.