VideoBackends:Vulkan: Synchronize presentation

[K0bin]

Synchronize with the submission thread if the last present is not done yet.

Right now we could potentially run vkAcquireNextImageKHR before the previous image is presented
and even run out of buffers. This is an easy fix.

Vulkan spec for vkAcquireNextImageKHR:

If the number of currently acquired images is greater than the difference between the number of images in swapchain and the value of VkSurfaceCapabilitiesKHR::minImageCount as returned by a call to vkGetPhysicalDeviceSurfaceCapabilities2KHR with the surface used to create swapchain, timeout must not be UINT64_MAX

[iwubcode]

This seems ok. I think I recall there being a validation error about swap chain images that were continuously increasing. Is that what this is attempting to resolve or was there another issue raised? (or maybe you just saw this?)

[K0bin]

Is that what this is attempting to resolve or was there another issue raised?

Yup.

Please don't ask me to put the validation error into the commit message :P
I don't have a reliable way to reproduce it and don't remember the exact wording.

[iwubcode]

Thanks @K0bin . That's great to hear. I'm assuming you mean this:

VideoBackends\Vulkan\VulkanContext.cpp:745 E[Host GPU]: Vulkan debug report: (Validation) Validation Error: [ VUID-vkAcquireNextImageKHR-swapchain-01802 ] Object 0: handle = 0x2e2,cd0,000,000,02b, type = VK_OBJECT_TYPE_SWAPCHAIN_KHR; | MessageID = 0x3e,97a,888 | vkAcquireNextImageKHR: Application has already previously acquired 1656 images from swapchain. Only 2 are available to be acquired using a timeout of UINT64_MAX (given the swapchain has 2, and VkSurfaceCapabilitiesKHR::minImageCount is 1). The Vulkan spec states: If the number of currently acquired images is greater than the difference between the number of images in swapchain and the value of VkSurfaceCapabilitiesKHR::minImageCount as returned by a call to vkGetPhysicalDeviceSurfaceCapabilities2KHR with the surface used to create swapchain, timeout must not be UINT64_MAX (https://vulkan.lunarg.com/doc/view/1.2.198.1/windows/1.2-extensions/vkspec.html#VUID-vkAcquireNextImageKHR-swapchain-01802)

[K0bin]

Pretty sure that's the one.

[iwubcode]

Hmm, in my testing, that doesn't seem to fix the issue. Tested with Xenoblade opening screen in a portable build. Used hybrid Ubershaders and safe texture cache. No other setting changes.

[K0bin]

Wait a second. I didn't notice that it said 1656 images O_O.

There must be something else going wrong besides this race condition.

How do you reproduce this?

[iwubcode]

@K0bin - I just ran Xenoblade with the settings I mentioned and turned on validation layer/the host-gpu log category (verbosity info).

EDIT: game doesn't seem to matter

[K0bin]

What do you mean by the opening screen? I cannot reproduce this.

[iwubcode]

@K0bin - open any game and I start to see a spam in validation error about the swap chain (as posted above).

Updated my driver/sdk just in case but still seeing the same issue.

[K0bin]

@iwubcode Any other validation errors besides that one? I'm not getting any validation errors and I simply don't understand, how it can call 1600x vkAcquireNextImage without presenting once.

What GPU & OS are you using?
Also make sure you're not running any broken Vulkan layers such as ingame overlays.

[JMC47]

Those games present an ungodly number of frames on boot, maybe you have Immediately Present XFB copies enabled?

[iwubcode]

@K0bin - no ingame overlay or anything like that.

I do see another validation error at startup:

Vulkan debug report: (Validation) Validation Warning: [ UNASSIGNED-CoreValidation-Shader-OutputNotConsumed ] Object 0: handle = 0xa,7cc,1e0,000,000,0d6, type = VK_OBJECT_TYPE_SHADER_MODULE; | MessageID = 0x6,09a,13b | fragment shader writes to output location 1 with no matching attachment

.

how it can call 1600x vkAcquireNextImage without presenting once.

The game is presenting and moving along. Just that the number continues to increases. I went past Xenoblade Wii screen all the way to the intro and now at around 3500 for that error.

I am on Windows 10, AMD rx480 GPU with driver 22.5.1.

Those games present an ungodly number of frames on boot, maybe you have Immediately Present XFB copies enabled?

@JMC47 - thanks for your advice. Other than Hybrid ubershaders turned on and the validation errors, I am using a portable build so immediately present XFB is not on.

[iwubcode]

@K0bin - I think this is an AMD bug: https://github.com/dolphin-emu/dolphin/blob/master/Source/Core/VideoBackends/Vulkan/VKRenderer.cpp#L286

Maybe we could somehow clear things so the validation layer doesn't spam. (EDIT: we can but then it's suboptimal. Helps for my own testing though)

Anyway, I don't think that's a blocker to this review.

[iwubcode]

Code LGTM. Can't test with my GPU unfortunately.

[K0bin]

I cant reproduce it with Immediately present XFB either.
So it most likely indeed comes down to that AMD driver bug.