Use VK_EXT_swapchain_maintenance1 in the Swapchain Recreation sample

[ShabbyX]

Description

This change builds on #613 which adds a sample demonstrating safe recycling of present semaphores and efficient swapchain recreation. This change takes advantage of VK_EXT_swapchain_maintenance1 to perform the same job with less complication / more efficiently.

This sample has been tested on Nvidia/Linux/X11, as well as SwiftShader/Linux/X11.

General Checklist:

Please ensure the following points are checked:

• My code follows the coding style
• I have reviewed file licenses
• I have updated the header Copyright to reflect the current year (CI build will fail if Copyright is out of date)
• I have commented any added functions (in line with Doxygen)
• I have commented any code that could be hard to understand
• My changes do not add any new compiler warnings
• My changes do not add any new validation layer errors or warnings
• I have used existing framework/helper functions where possible
• My changes build on Windows, Linux, macOS and Android. Otherwise I have documented any exceptions
• My changes do not add any regressions
• I have tested every sample to ensure everything runs correctly
• This PR describes the scope and expected impact of the changes I am making

Sample Checklist

If your PR contains a new or modified sample, these further checks must be carried out in addition to the General Checklist:

• I have tested the sample on at least one compliant Vulkan implementation
• If the sample is vendor-specific, I have tagged it appropriately
• I have stated on what implementation the sample has been tested so that others can test on different implementations and platforms
• Any dependent assets have been merged and published in downstream modules
• For new samples, I have added a paragraph with a summary to the appropriate chapter in the samples readme

[marty-johnson59]

Hi @ShabbyX, we briefly discussed this on the Samples call today and had questions on timing. Do you know if (or when) there are HW drivers that support this? It looked like it is available on Swiftshader and possibly RADV. We're thinking we should hold off until more vendors support this in drivers? We would be interested in your thoughts on timing for this sample. Thanks.

[ShabbyX]

We're thinking we should hold off until more vendors support this in drivers?

Yes, that was my understanding in the call a few weeks ago, which is why I split the PRs. I am in no rush to land this, so take your time!

Do you know if (or when) there are HW drivers that support this?

I know Hans-Kristian had an implementation for mesa (I believe that'd be all mesa drivers), but don't know if that's merged. I also know that Nvidia is working on it, but of course release timing depends on them.

[asuessenbach]

Unfortunately, I don't have HW around supporting VK_EXT_surface_maintenance1.
But the changes compared to #613 look pretty clear.

[gary-sweet]

I don't have a driver that supports swapchain_maintenance1 yet, so all I can do is confirm that this doesn't break the existing functionality for me.

[SaschaWillems]

Works fine for me.

Will approve once the merge conflicts have been resolved :)

[ShabbyX]

Works fine for me.

Will approve once the merge conflicts have been resolved :)

Done

[asuessenbach]

I think, the way to handle the extensions would be to unconditionally add them in the SwapchainRecreation constructor, but mark them as optional.
Then, you don't need to initialize volk on your own, and can handle the implications of that extension not being there in prepare.

[ShabbyX]

I'll try when I find the time, but I think the issue was with surface_maintenance1 being an instance extension that made it complicated.

[SaschaWillems]

Works fine on my NVIDIA RTX 4070 on Windows 11, which finally supports the extension.

I can also confirm that the validation error mentioned above is gone with a build of the latest validation layers from source.