VkSwapchainPresentModesCreateInfoEXT with swapchain recreation produces wrong message

[Agrael1]

Environment:

• OS: Windows 11
• GPU and driver version: NVidia A4000, 560.x
• SDK or header version if building from repo: 1.3.296
• Options enabled (synchronization, best practices, etc.): yes

Describe the Issue

I had created the swapchain with VkSwapchainPresentModesCreateInfoEXT initially, but on resize I forgot to add the same pNext and got weird error:

[Validation layer]: VUID-VkSwapchainCreateInfoKHR-pNext-07781
 [Message]:Validation Error: [ VUID-VkSwapchainCreateInfoKHR-pNext-07781 ] | MessageID = 0x4c8929c1 | vkCreateSwapchainKHR(): pCreateInfo->imageExtent (width = 2560, height = 1349), which is outside the bounds returned by vkGetPhysicalDeviceSurfaceCapabilitiesKHR(): currentExtent = (width = 1920, height = 1080), minImageExtent = (width = 1920, height = 1080), maxImageExtent = (width = 1920, height = 1080).
The Vulkan spec states: If a VkSwapchainPresentScalingCreateInfoEXT structure was not included in the pNext chain, or it is included and VkSwapchainPresentScalingCreateInfoEXT::scalingBehavior is zero then 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.3.296.0/windows/1.3-extensions/vkspec.html#VUID-VkSwapchainCreateInfoKHR-pNext-07781)

although the resize code contains vkGetPhysicalDeviceSurfaceCapabilitiesKHR and returned size is correct.

Expected behavior

A message stating that I have forgot to include the same pnexts or nothing.

[artem-lunarg]

A message stating that I have forgot to include the same pnexts or nothing.

@Agrael1 validation layer probably can't use previous behavior to make suggestion how to use API, it validates API usage based only on the specification.

As I understand the first part of the message is problematic:

pCreateInfo->imageExtent (width = 2560, height = 1349), which is outside the bounds returned by vkGetPhysicalDeviceSurfaceCapabilitiesKHR(): currentExtent = (width = 1920, height = 1080), minImageExtent = (width = 1920, height = 1080), maxImageExtent = (width = 1920, height = 1080).

Does the message report pCreateInfo->imageExtent (width = 2560, height = 1349 incorrectly compared to what you get from vkGetPhysicalDeviceSurfaceCapabilitiesKHR ?

[artem-lunarg]

One suggestion is to enable Thread Safety checks (for example in vkconfig) to check there is no threading errors (in theory it can affect caching we use to store surface queries).

[Agrael1]

Does the message report pCreateInfo->imageExtent (width = 2560, height = 1349 incorrectly compared to what you get from vkGetPhysicalDeviceSurfaceCapabilitiesKHR ?

Yes, I get correct extents, but they are reported as incorrect:

There is no multithreading in my app, it is a basic example.

[artem-lunarg]

@Agrael1 if it’s a small program do you have an opportunity to provide source code, we can then quickly analyze it? There is an option to use LunarG sharing portal, the shared material won’t be publicly visible. If this is an option we can send the invitation on your preferred email.

[Agrael1]

well, if you can download Wisdom there is branch fix/swapchain_instability. The CMake config should either be preset x64-debug-vk from CMakePresets or just add -DWISDOM_FORCE_VULKAN.

The example of interest is Example.exe. Its location is examples/platform/shared. If you just resize the window, the message will pop up.

Otherwise I could try to make smaller example, yet it will still download Wisdom.

Code of swapchain creation is here

and recreation is here

[artem-lunarg]

@Agrael1 thanks, that's great. I will work with this.

[artem-lunarg]

Can reproduce the validation error with nvidia gpu. No errors when run on amd.

[Agrael1]

Can you also see the stutters of the triangle? If so, the Swapchain maintenance on NVidia is not working correctly and should be reported to NVidia.

[Agrael1]

Also, IIRC AMD may not have swapchain maintenance implemented, the code I provided would just skip the creation of dynamic vsync altogether

[artem-lunarg]

Yes, on amd it's probably because of extension support. I can see the issue in our code, already reproduced in the internal test, working on the fix.