Vulkan backend: on synchronization primitives

[ParticlePeter]

See details in the commits

[ParticlePeter]

Added mandatory semaphores between vkQueueSubmit and vkQueuePresentKHR. To maintain a high frame rate in this single threaded scenario and efficiently overlap CPU and GPU work (still single threaded) we draw into the last acquired swapchain image but display the last but one. All changes made so far are editable, so that we can draw and immediately present the latest acquired image for the cost of less work overlap and hence much lower frame rate. However, the semaphores are required to ensure correctness.

[ocornut]

@ParticlePeter I am trying to catch up with the various Vulkan related PR but your PR here and most others have multiple commits that seems unrelated to that specific PR. Is that intended?

[ocornut]

Pasting comment from #1039, same author (now closed)

So I managed to get a similar high performance with the mentioned semaphores (pr #1043). I guess the setup is now working as initially intend by the author. The cost for the high frame rate is a lag of one frame, we render into the last acquired image but display the last but one instead. The former setup had probably a lag as well but at least two frames and at most swapchain image count frames (depends how the driver delivers next swapchain index).
Reasoning: without a semaphore between vkQueueSubmit and vkQueuePresentKHR (using the same swapchain index as frambuffer index and present image index) the swapchain image would have been presented as soon as the command buffers SUBMITTED but not FINISHED. Assuming that an image presentation is (much) faster than a graphics pipeline render task, we would see the image drawn one complete acquiring cycle ago.

[ocornut]

This is now merged (had to cherry-pick individual commits). Please in the future try to make the PR saner to work with :) Thanks!

I also fixed an extra validation warning I got.

Message: vkCreateSampler(): The samplerAnisotropy feature is not enabled, so the maxAnisotropy member of the VkSamplerCreateInfo structure must be 1.0 but is 0.000000.

[ParticlePeter]

Hello and sorry for the generated work. I created in total three pull request. All the commits per pull request were meant to be accepted, I didn't mean you to cherry pick, what was the issue?

[ocornut]

With Git a PR is associated to a whole branch, so further commits in the branch gets added to the PR. So some of the commits here were duplicated 3 times. It's a classic confusing things with GIT, everyone makes the mistake once.

I could probably have done without cherry-picking but it's also an easy way for me to "process" the changes one by one as I review them in situations where I am utterly confused by the sum of the whole.

All good now (I think!).

[ParticlePeter]

I am aware of the fact with the commits, but I have not found a good working procedure so far. Lets say PR2 branched from PR1, after that PR1 got some more commits which should be available in PR2 as well. So how to do that without hassle for you the origin maintainer?

[MrSapps]

Make a branch for both (and to create the PRs from), and then have a "staging" branch that you merge both into for testing. Thats my usual flow.

[ParticlePeter]

Sounds reasonable, thanks, I'll try that.