I have a problem I have postponed until now but I need to resolve this. In our application the main thread handles Win32 window events and message handling. A second thread is used for rendering, and contains all our Vulkan code. This works perfectly fine until the issue of window resizing comes up. If I drag a resizable window around a bit, I will receive Vulkan validation errors like this after a few seconds:
Validation Error: [ VUID-VkSwapchainCreateInfoKHR-imageExtent-01274 ] Object 0: handle = 0x2871d308270, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0x7cd0911d | vkCreateSwapchainKHR() called with imageExtent = (1266,473), which is outside the bounds returned by vkGetPhysicalDeviceSurfaceCapabilitiesKHR(): currentExtent = (1286,473), minImageExtent = (1286,473), maxImageExtent = (1286,473). The Vulkan spec states: imageExtent must be between minImageExtent and maxImageExtent, inclusive, where minImageExtent and maxImageExtent are members of the VkSurfaceCapabilitiesKHR structure returned by vkGetPhysicalDeviceSurfaceCapabilitiesKHR for the surface (https://vulkan.lunarg.com/doc/view/1.2.141.0/windows/1.2-extensions/vkspec.html#VUID-VkSwapchainCreateInfoKHR-imageExtent-01274)
I presume what is happening is the window is being resized on the main thread and the new size does not match the expected size at the start of a rendering operation.
There pretty much is TOCTOU issue and the VU cannot fundamentally be satisfied. I think drivers are fine with that. The bad behavior is basically the image might not be scaled the way you want it if the sizes mismatch. It should not be a major problem if you properly listen to sizing events and OUT_OF_DATE error code.
Okay, so we have two issues. One is that the validation layer might be creating a false positive. I can disable this by just checking the error string for this message.
The other is the actual behavior of the code. I am currently not performing any type of syncronization of the window size. All window events are being evaluated on one thread, whole the rendering thread does its own thing. I have no idea what is happening inside of vkGetPhysicalDeviceLimits() or whether this is safe to use on a separate thread as the wndproc callback is simultaneously executing on the main thread. Do we have any information on this?
My solution is to use a resizable parent window and a non-resizable child window. When the parent window is resized by the user, the child window is deleted and a new child window and framebuffer are created with the new size. Dynamically resizing a window is kind of contradictory to how Vulkan works so I am not going to fight it.