Extension and Version Dependencies
Alon Or-bach alonorbach
Other Extension Metadata
- Last Modified Date
- IP Status
No known IP claims.
Alon Or-bach, Samsung Electronics
Ian Elliott, Google
Jesse Hall, Google
Pablo Ceballos, Google
Chris Forbes, Google
Jeff Juliano, NVIDIA
James Jones, NVIDIA
Daniel Rakos, AMD
Tobias Hector, Imagination Technologies
Graham Connor, Imagination Technologies
Michael Worcester, Imagination Technologies
Cass Everitt, Oculus
Johannes Van Waveren, Oculus
This extension extends
VK_KHR_swapchain to enable creation of a
shared presentable image.
This allows the application to use the image while the presention engine is
accessing it, in order to reduce the latency between rendering and
New Enum Constants
1) Should we allow a Vulkan WSI swapchain to toggle between normal usage and shared presentation usage?
RESOLVED: No. WSI swapchains are typically recreated with new properties instead of having their properties changed. This can also save resources, assuming that fewer images are needed for shared presentation, and assuming that most VR applications do not need to switch between normal and shared usage.
2) Should we have a query for determining how the presentation engine refresh is triggered?
RESOLVED: Yes. This is done via which presentation modes a surface supports.
3) Should the object representing a shared presentable image be an extension of a VkSwapchainKHR or a separate object?
RESOLVED: Extension of a swapchain due to overlap in creation properties and to allow common functionality between shared and normal presentable images and swapchains.
4) What should we call the extension and the new structures it creates?
RESOLVED: Shared presentable image / shared present.
5) Should the
presentMode values of the
VkSwapchainCreateInfoKHR be ignored, or required to be compatible
minImageCount must be set to 1, and
should be set to either
6) What should the layout of the shared presentable image be?
RESOLVED: After acquiring the shared presentable image, the application
must transition it to the
prior to it being used.
After this initial transition, any image usage that was requested during
swapchain creation can be performed on the image without layout transitions
7) Do we need a new API for the trigger to refresh new content?
RESOLVED: vkQueuePresentKHR to act as API to trigger a refresh, as will allow combination with other compatible extensions to vkQueuePresentKHR.
8) How should an application detect a
on a swapchain using the
RESOLVED: Introduce vkGetSwapchainStatusKHR to allow applications to query the status of a swapchain using a shared presentation mode.
9) What should subsequent calls to vkQueuePresentKHR for
VK_PRESENT_MODE_SHARED_CONTINUOUS_REFRESH_KHR swapchains be defined to
RESOLVED: State that implementations may use it as a hint for updated content.
10) Can the ownership of a shared presentable image be transferred to a different queue?
It is not possible to transfer ownership of a shared presentable image
obtained from a swapchain created using
after it has been presented.
11) How should vkQueueSubmit behave if a command buffer uses an image
RESOLVED: vkQueueSubmit is expected to return the
12) Can Vulkan provide any guarantee on the order of rendering, to enable beam chasing?
RESOLVED: This could be achieved via use of render passes to ensure strip rendering.
For more information, see the Vulkan Specification
This page is a generated document. Fixes and changes should be made to the generator scripts, not directly.