1// Copyright (c) 2014-2018 Khronos Group. This work is licensed under a 2// Creative Commons Attribution 4.0 International License; see 3// http://creativecommons.org/licenses/by/4.0/ 4 5include::meta/VK_KHR_shared_presentable_image.txt[] 6 7*Last Modified Date*:: 8 2017-03-20 9*IP Status*:: 10 No known IP claims. 11*Contributors*:: 12 - Alon Or-bach, Samsung Electronics 13 - Ian Elliott, Google 14 - Jesse Hall, Google 15 - Pablo Ceballos, Google 16 - Chris Forbes, Google 17 - Jeff Juliano, NVIDIA 18 - James Jones, NVIDIA 19 - Daniel Rakos, AMD 20 - Tobias Hector, Imagination Technologies 21 - Graham Connor, Imagination Technologies 22 - Michael Worcester, Imagination Technologies 23 - Cass Everitt, Oculus 24 - Johannes Van Waveren, Oculus 25 26This extension extends `<<VK_KHR_swapchain>>` to enable creation of a shared 27presentable image. 28This allows the application to use the image while the presention engine is 29accessing it, in order to reduce the latency between rendering and 30presentation. 31 32=== New Object Types 33 34None. 35 36=== New Enum Constants 37 38 * Extending elink:VkPresentModeKHR: 39 ** ename:VK_PRESENT_MODE_SHARED_DEMAND_REFRESH_KHR 40 ** ename:VK_PRESENT_MODE_SHARED_CONTINUOUS_REFRESH_KHR 41 42 * Extending elink:VkImageLayout: 43 ** ename:VK_IMAGE_LAYOUT_SHARED_PRESENT_KHR 44 45 * Extending elink:VkStructureType: 46 ** ename:VK_STRUCTURE_TYPE_SHARED_PRESENT_SURFACE_CAPABILITIES_KHR 47 48 49=== New Enums 50 51None. 52 53=== New Structures 54 55 * slink:VkSharedPresentSurfaceCapabilitiesKHR 56 57=== New Functions 58 59 * flink:vkGetSwapchainStatusKHR 60 61 62=== Issues 63 641) Should we allow a Vulkan WSI swapchain to toggle between normal usage and 65shared presentation usage? 66 67*RESOLVED*: No. 68WSI swapchains are typically recreated with new properties instead of having 69their properties changed. 70This can also save resources, assuming that fewer images are needed for 71shared presentation, and assuming that most VR applications do not need to 72switch between normal and shared usage. 73 742) Should we have a query for determining how the presentation engine 75refresh is triggered? 76 77*RESOLVED*: Yes. 78This is done via which presentation modes a surface supports. 79 803) Should the object representing a shared presentable image be an extension 81of a slink:VkSwapchainKHR or a separate object? 82 83*RESOLVED*: Extension of a swapchain due to overlap in creation properties 84and to allow common functionality between shared and normal presentable 85images and swapchains. 86 874) What should we call the extension and the new structures it creates? 88 89*RESOLVED*: Shared presentable image / shared present. 90 915) Should the pname:minImageCount and pname:presentMode values of the 92slink:VkSwapchainCreateInfoKHR be ignored, or required to be compatible 93values? 94 95*RESOLVED*: pname:minImageCount must be set to 1, and pname:presentMode 96should be set to either ename:VK_PRESENT_MODE_SHARED_DEMAND_REFRESH_KHR or 97ename:VK_PRESENT_MODE_SHARED_CONTINUOUS_REFRESH_KHR. 98 996) What should the layout of the shared presentable image be? 100 101*RESOLVED*: After acquiring the shared presentable image, the application 102must transition it to the ename:VK_IMAGE_LAYOUT_SHARED_PRESENT_KHR layout 103prior to it being used. 104After this intial transition, any image usage that was requested during 105swapchain creation can: be performed on the image without layout transitions 106being performed. 107 1087) Do we need a new API for the trigger to refresh new content? 109 110*RESOLVED*: flink:vkQueuePresentKHR to act as API to trigger a refresh, as 111will allow combination with other compatible extensions to 112flink:vkQueuePresentKHR. 113 1148) How should an application detect a ename:VK_ERROR_OUT_OF_DATE_KHR error 115on a swapchain using the ename:VK_PRESENT_MODE_SHARED_CONTINUOUS_REFRESH_KHR 116present mode? 117 118*RESOLVED*: Introduce flink:vkGetSwapchainStatusKHR to allow applications to 119query the status of a swapchain using a shared presentation mode. 120 1219) What should subsequent calls to flink:vkQueuePresentKHR for 122ename:VK_PRESENT_MODE_SHARED_CONTINUOUS_REFRESH_KHR swapchains be defined to 123do? 124 125*RESOLVED*: State that implementations may use it as a hint for updated 126content. 127 12810) Can the ownership of a shared presentable image be transferred to a 129different queue? 130 131*RESOLVED*: No. 132It is not possible to transfer ownership of a shared presentable image 133obtained from a swapchain created using ename:VK_SHARING_MODE_EXCLUSIVE 134after it has been presented. 135 13611) How should flink:vkQueueSubmit behave if a command buffer uses an image 137from an ename:VK_ERROR_OUT_OF_DATE_KHR swapchain? 138 139*RESOLVED*: flink:vkQueueSubmit is expected to return the 140ename:VK_ERROR_DEVICE_LOST error. 141 14212) Can Vulkan provide any guarantee on the order of rendering, to enable 143beam chasing? 144 145*RESOLVED*: This could be achieved via use of render passes to ensure strip 146rendering. 147 148 149=== Version History 150 * Revision 1, 2017-03-20 (Alon Or-bach) 151 - Internal revisions 152