i’ve found 2 problems with VK_KHR_swapchain. System is Win7 SP1 x64 with a GTX 970 and driver 368.39.
There is a corner case problem with vkCreateSwapchainKHR and vkGetPhysicalDeviceSurfaceCapabilitiesKHR. If the window is minimized or resized to the smallest possible height, vkGetPhysicalDeviceSurfaceCapabilitiesKHR will return a currentExtent of (0,0) or (width,0). Regardless of the current size, minImageExtent is (1,1) and maxImageExtent is (16384,16384). The spec defines for Windows that a swapchain must match the current window size, yet vkCreateSwapchainKHR does not support the zero extent and fails. On the other hand, if i clamp the current extent to min and max extent, it works, but the LunarG validation layers throw an error because the swapchain extent is not the same as the current extent. So either vkGetPhysicalDeviceSurfaceCapabilitiesKHR should not report a zero extent (clamp the output), or vkCreateSwapchainKHR should accept a zero extent (clamp the input).
The second problem is with vkQueuePresentKHR. When i use 2 images with FIFO presentation mode, vkQueuePresentKHR becomes a blocking call that only returns after VSync, so can block up to ca. 16.4 ms. On the other hand, calls to vkAcquireNextImageKHR or waiting on its fence or a fence on a submit of the last frame will never exhibit any kind of blocking. Since this not only blocks the render thread, but also access to the swapchain, there is no way to get a semaphore for the next swapchain-image and pre-submit work that should start running after VSync. My understanding was that with a 2 image FIFO swapchain, the semaphore/fence on vkAcquireNextImageKHR could be used to wait for VSync on the GPU/CPU, respectively, to better schedule work. So is this a “bug” in the driver or if not, how should this problem be solved on NVIDIA hardware?