// Copyright 2014-2021 The Khronos Group, Inc.
//
// SPDX-License-Identifier: CC-BY-4.0

include::{generated}/meta/{refprefix}VK_KHR_shared_presentable_image.txt[]

=== Other Extension Metadata

*Last Modified Date*::
    2017-03-20
*IP Status*::
    No known IP claims.
*Contributors*::
  - 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

=== Description

This extension extends `apiext: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
presentation.

include::{generated}/interfaces/VK_KHR_shared_presentable_image.txt[]

=== Issues

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 slink: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 pname:minImageCount and pname:presentMode values of the
slink:VkSwapchainCreateInfoKHR be ignored, or required to be compatible
values?

*RESOLVED*: pname:minImageCount must be set to 1, and pname:presentMode
should be set to either ename:VK_PRESENT_MODE_SHARED_DEMAND_REFRESH_KHR or
ename:VK_PRESENT_MODE_SHARED_CONTINUOUS_REFRESH_KHR.

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 ename:VK_IMAGE_LAYOUT_SHARED_PRESENT_KHR layout
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
being performed.

7) Do we need a new API for the trigger to refresh new content?

*RESOLVED*: flink:vkQueuePresentKHR to act as API to trigger a refresh, as
will allow combination with other compatible extensions to
flink:vkQueuePresentKHR.

8) How should an application detect a ename:VK_ERROR_OUT_OF_DATE_KHR error
on a swapchain using the ename:VK_PRESENT_MODE_SHARED_CONTINUOUS_REFRESH_KHR
present mode?

*RESOLVED*: Introduce flink:vkGetSwapchainStatusKHR to allow applications to
query the status of a swapchain using a shared presentation mode.

9) What should subsequent calls to flink:vkQueuePresentKHR for
ename:VK_PRESENT_MODE_SHARED_CONTINUOUS_REFRESH_KHR swapchains be defined to
do?

*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?

*RESOLVED*: No.
It is not possible to transfer ownership of a shared presentable image
obtained from a swapchain created using ename:VK_SHARING_MODE_EXCLUSIVE
after it has been presented.

11) How should flink:vkQueueSubmit behave if a command buffer uses an image
from a ename:VK_ERROR_OUT_OF_DATE_KHR swapchain?

*RESOLVED*: flink:vkQueueSubmit is expected to return the
ename:VK_ERROR_DEVICE_LOST error.

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.


=== Version History
 * Revision 1, 2017-03-20 (Alon Or-bach)
   - Internal revisions