1// Copyright 2014-2022 The Khronos Group Inc. 2// 3// SPDX-License-Identifier: CC-BY-4.0 4 5include::{generated}/meta/{refprefix}VK_KHR_shared_presentable_image.adoc[] 6 7=== Other Extension Metadata 8 9*Last Modified Date*:: 10 2017-03-20 11*IP Status*:: 12 No known IP claims. 13*Contributors*:: 14 - Alon Or-bach, Samsung Electronics 15 - Ian Elliott, Google 16 - Jesse Hall, Google 17 - Pablo Ceballos, Google 18 - Chris Forbes, Google 19 - Jeff Juliano, NVIDIA 20 - James Jones, NVIDIA 21 - Daniel Rakos, AMD 22 - Tobias Hector, Imagination Technologies 23 - Graham Connor, Imagination Technologies 24 - Michael Worcester, Imagination Technologies 25 - Cass Everitt, Oculus 26 - Johannes Van Waveren, Oculus 27 28=== Description 29 30This extension extends `apiext:VK_KHR_swapchain` to enable creation of a 31shared presentable image. 32This allows the application to use the image while the presention engine is 33accessing it, in order to reduce the latency between rendering and 34presentation. 35 36include::{generated}/interfaces/VK_KHR_shared_presentable_image.adoc[] 37 38=== Issues 39 401) Should we allow a Vulkan WSI swapchain to toggle between normal usage and 41shared presentation usage? 42 43*RESOLVED*: No. 44WSI swapchains are typically recreated with new properties instead of having 45their properties changed. 46This can also save resources, assuming that fewer images are needed for 47shared presentation, and assuming that most VR applications do not need to 48switch between normal and shared usage. 49 502) Should we have a query for determining how the presentation engine 51refresh is triggered? 52 53*RESOLVED*: Yes. 54This is done via which presentation modes a surface supports. 55 563) Should the object representing a shared presentable image be an extension 57of a slink:VkSwapchainKHR or a separate object? 58 59*RESOLVED*: Extension of a swapchain due to overlap in creation properties 60and to allow common functionality between shared and normal presentable 61images and swapchains. 62 634) What should we call the extension and the new structures it creates? 64 65*RESOLVED*: Shared presentable image / shared present. 66 675) Should the pname:minImageCount and pname:presentMode values of the 68slink:VkSwapchainCreateInfoKHR be ignored, or required to be compatible 69values? 70 71*RESOLVED*: pname:minImageCount must be set to 1, and pname:presentMode 72should be set to either ename:VK_PRESENT_MODE_SHARED_DEMAND_REFRESH_KHR or 73ename:VK_PRESENT_MODE_SHARED_CONTINUOUS_REFRESH_KHR. 74 756) What should the layout of the shared presentable image be? 76 77*RESOLVED*: After acquiring the shared presentable image, the application 78must transition it to the ename:VK_IMAGE_LAYOUT_SHARED_PRESENT_KHR layout 79prior to it being used. 80After this initial transition, any image usage that was requested during 81swapchain creation can: be performed on the image without layout transitions 82being performed. 83 847) Do we need a new API for the trigger to refresh new content? 85 86*RESOLVED*: flink:vkQueuePresentKHR to act as API to trigger a refresh, as 87will allow combination with other compatible extensions to 88flink:vkQueuePresentKHR. 89 908) How should an application detect a ename:VK_ERROR_OUT_OF_DATE_KHR error 91on a swapchain using the ename:VK_PRESENT_MODE_SHARED_CONTINUOUS_REFRESH_KHR 92present mode? 93 94*RESOLVED*: Introduce flink:vkGetSwapchainStatusKHR to allow applications to 95query the status of a swapchain using a shared presentation mode. 96 979) What should subsequent calls to flink:vkQueuePresentKHR for 98ename:VK_PRESENT_MODE_SHARED_CONTINUOUS_REFRESH_KHR swapchains be defined to 99do? 100 101*RESOLVED*: State that implementations may use it as a hint for updated 102content. 103 10410) Can the ownership of a shared presentable image be transferred to a 105different queue? 106 107*RESOLVED*: No. 108It is not possible to transfer ownership of a shared presentable image 109obtained from a swapchain created using ename:VK_SHARING_MODE_EXCLUSIVE 110after it has been presented. 111 11211) How should flink:vkQueueSubmit behave if a command buffer uses an image 113from a ename:VK_ERROR_OUT_OF_DATE_KHR swapchain? 114 115*RESOLVED*: flink:vkQueueSubmit is expected to return the 116ename:VK_ERROR_DEVICE_LOST error. 117 11812) Can Vulkan provide any guarantee on the order of rendering, to enable 119beam chasing? 120 121*RESOLVED*: This could be achieved via use of render passes to ensure strip 122rendering. 123 124 125=== Version History 126 127 * Revision 1, 2017-03-20 (Alon Or-bach) 128 ** Internal revisions 129