Confirmation regarding swap chain resizing

According to the spec for VkSurfaceCapabilitiesKHR it states:

currentExtent is the current width and height of the surface, or the special value (0xFFFFFFFF, 0xFFFFFFFF) indicating that the surface size will be determined by the extent of a swapchain targeting the surface.

Does this mean that i’ll have to destroy and recreate my surface whenever i need to change my swapchain extent?

According to my test, that seems to be the case, cause if i just recreate my swapchain with a different extent (even though i called vkGetPhysicalDeviceSurfaceCapabilitiesKHR to check that my extent has been changed), i’ll get an error from the validation layer and later on an access violation somewhere down the line on my swap chain handle if i ignore it.

Just want to get a confirmation if this is the expected behavior. Cause i’ll have to reinitialize the entire vulkan (save the vkInstance) just to change my swap chain resolution

I don’t think so. Surface should be reusable. But a Surface must not be currently used by more than one Swapchain, so you either have to destroy the old Swapchain before creating the new one or you have to provide it to the oldSwapchain parameter (which has its own advantages and disadvantages).

PS: In the swapchain extension issue 9) it says you should just re-query Surface and recreate Swapchain.

What kind of error do you get specifically?

probably an error in the driver then or issue with the validation layer.

it’s saying that my extent doesn’t match the extent obtained from: vkGetPhysicalDeviceSurfaceCapabilitiesKHR, the validation layer is showing the old value before i resized my window

but the extent i passed in for the new swap chain is taken from the surface; the value for my surface changed since i resized my window, i called vkGetPhysicalDeviceSurfaceCapabilitiesKHR again to confirm that the size is no longer the same as before and took the exact same value to recreate my swap chain tried both method: recreating the swapchain and creating a new swapchain both cause a validation error.

currently fixing some issue with my windowing call, was wondering if it’s due to a bug in my windowing update, will test it again after fixing some windowing stuff.

apparently it’s an issue with the validation layer (likely caching the old value and not updating it when i call it again).

cause i’m still getting the same error which says:

vkCreateSwapChainKHR() called with pCreateInfo -> imageExtent = (2736, 1824), which is not equal to the currentExtent = (1008, 729) returned by vkGetPhysicalDeviceSurfaceCapabilitiesKHR()

but my surface extent has already been updated since i already called it and it shows 2736, 1824 which is why i’m recreating with it. it causes an access violation later on if i just ignore the error. but if i turn off the validation layer, everything works fine.

NOTE: there was a bug in my windowing call that i had to fix; i forgot to call SWP_SHOWWINDOW when calling SetWindowPos and the window was going mad after a few change in resolution hence i tot it was an issue with the driver, everything works fine after i added in SWP_SHOWWINDOW and turned off validation layer

I find it somewhat unlikely something like that would only surface now. You must be doing something differently…

Make sure you have the latest drivers, latest SDK and try latest cube demo (which does resizing).

Do you do it in reaction to WM_SIZE (or sooner)?

Might need to see your code to help more.

nevermind it’s not that, i was firing a delayed event to resize my graphic when the actual window resized, so when i was increasing my size it was fine but when i was reducing the size it was causing problem (this explains the access violation issue i got since i’m trying to draw a larger area than what i’m supposed to?).

so after fixing that everything ran fine if lunarG validation layer was turned off, but when i turn it on i get the same error and if i ignore the error, vkGetSwapchainImagesKHR returns with VK_SUCCESS but the image count returned was whatever value it was previously set to before i call vkGetSwapchainImagesKHR.

i’m using the latest beta driver that works with vulkan (using intel card so no official driver yet) with the latest lunarG sdk, i tried the cube demo, didn’t get any issue with it, so i’m definitely doing something wrong, will take a look at the demo code first and see if i’m missing anything.

ok finally found it, when i was resizing i called vkEnumeratePhysicalDevices again to repopulate my array of available physical device. i checked that the physical device i got from both call was returning the same physical device and i proceed to recreate my swap chain, but apparently though i’m using the same physical device, the validation layer doesn’t like that i called vkEnumeratePhysicalDevices. It’s fine to call it to obtain the size to enumerate, i can’t use it to obtain the array of physical device.

that sounds like a bug in validation layer.

What error message are you getting from the validation layer, exactly?

You should be able to enumerate physical devices as often as you want after you called it once to get the count (within the same instance). The only way I think you could get a message here is if you got the count, enumerated, created the device, destroyed the device (as part of the resize), destroyed the instance (also as part of this resize), created a new instance, and then tried to enumerate without getting the count first.

I also don’t think you would need to enumerate again after a resize, unless you think that it is possible for the device configuration to change during the resize. In any case, you shouldn’t need to destroy and recreate the instance as the result of a resize.

If you still think there is a bug, it will get better attention if you file an issue at :

i wrote the error msg earlier, it’s a bug in the validation layer found a submission regarding it:

OK, at first I didn’t see the relationship between the call to enumerate devices and your error messages.

I played with the cube demo a bit and I changed it to call enumerate devices again at the bottom of demo_init_vk() and got different, but strange validation errors from swapchain. So something looks off. We’ll try to look into it soon.