Skip to main content

Khronos Blog

Resolving Long Standing Issues with Vulkan Windowing System Integration (WSI)

by

The recently released VK_EXT_surface_maintenance1 and VK_EXT_swapchain_maintenance1 extensions resolve a number of longstanding issues with Vulkan's WSI extensions.

Most importantly, it is now possible for applications to know when resources associated with a present operation can be destroyed, e.g. the semaphores provided in VkPresentInfoKHR::pWaitSemaphores. This is done by providing a fence in VkSwapchainPresentFenceInfoEXT that is chained to VkPresentInfoKHR. Once the fence is signaled, the application can destroy said semaphores. Additionally, with the outstanding present operations processed according to these fences, the application is able to safely destroy swapchains (retired or otherwise).

Two mechanisms are added to alleviate issues with respect to window resizing and rotation.

  • Applications are now able to release images back to the swapchain without presenting them through vkReleaseSwapchainImagesEXT. This is useful when the swapchain gets out of date or has become suboptimal, and the application is eager to start presenting to a new swapchain right away. Peak memory usage may be reduced during swapchain recreation when using oldSwapchain and calling this before the new swapchain is created.
  • Applications can now specify the desired behavior when the window size no longer matches the swapchain's, by providing a scaling method through VkSwapchainPresentScalingCreateInfoEXT.

A swapchain creation flag is added, namely VK_SWAPCHAIN_CREATE_DEFERRED_MEMORY_ALLOCATION_BIT_EXT, which lets the implementation amortize the cost of swapchain image memory allocation over multiple frames, or leave some images entirely unallocated if never actually acquired. This is a small optimization to app startup time, but also may reduce peak memory usage during swapchain recreation. Once specified though, the application is unable to pre-record commands using a swapchain image until it is acquired at least once, and the deferred allocation operation may add unpredictability to the cost of acquiring images.

Finally, to avoid unnecessarily recreating the swapchain when changing present modes, VkSwapchainPresentModesCreateInfoEXT can be used to specify which supported compatible present modes the swapchain may switch to, and do so at present time through VkSwapchainPresentModeInfoEXT. This is particularly important for front-buffer rendering when switching between the present modes provided by VK_KHR_shared_presentable_image.

Thank you for your patience as we worked through these issues. As always, please provide feedback in the Vulkan-Docs GitHub repository.

Comments