| // Copyright 2019-2021 The Khronos Group, Inc. |
| // |
| // SPDX-License-Identifier: CC-BY-4.0 |
| |
| include::{generated}/meta/{refprefix}VK_KHR_present_wait.txt[] |
| |
| === Other Extension Metadata |
| |
| *Last Modified Date*:: |
| 2019-05-15 |
| *IP Status*:: |
| No known IP claims. |
| *Contributors*:: |
| - Keith Packard, Valve |
| - Ian Elliott, Google |
| - Tobias Hector, AMD |
| - Daniel Stone, Collabora |
| |
| === Description |
| |
| This device extension allows an application that uses the |
| `apiext:VK_KHR_swapchain` extension to wait for present operations to |
| complete. |
| An application can use this to monitor and control the pacing of the |
| application by managing the number of outstanding images yet to be |
| presented. |
| |
| include::{generated}/interfaces/VK_KHR_present_wait.txt[] |
| |
| === Issues |
| |
| 1) When does the wait finish? |
| |
| *RESOLVED*. |
| The wait will finish when the present is visible to the user. |
| There is no requirement for any precise timing relationship between the |
| presentation of the image to the user, but implementations should: signal |
| the wait as close as possible to the presentation of the first pixel in the |
| new image to the user. |
| |
| 2) Should this use fences or other existing synchronization mechanism. |
| |
| *RESOLVED*. |
| Because display and rendering are often implemented in separate drivers, |
| this extension will provide a separate synchronization API. |
| |
| 3) Should this extension share present identification with other extensions? |
| |
| *RESOLVED*. |
| Yes. |
| A new extension, VK_KHR_present_id, should be created to provide a shared |
| structure for presentation identifiers. |
| |
| 4) What happens when presentations complete out of order wrt calls to |
| vkQueuePresent? This could happen if the semaphores for the presentations |
| were ready out of order. |
| |
| *OPTION A*: Require that when a PresentId is set that the driver ensure that |
| images are always presented in the order of calls to |
| vkQueuePresent. |
| |
| *OPTION B*: Finish both waits when the earliest present completes. |
| This will complete the later present wait earlier than the |
| actual presentation. |
| This should be the easiest to implement as the driver need only |
| track the largest present ID completed. |
| This is also the 'natural' consequence of interpreting the |
| existing vkWaitForPresentKHR specificationn. |
| |
| *OPTION C*: Finish both waits when both have completed. |
| This will complete the earlier presentation later than the |
| actual presentation time. |
| This is allowed by the current specification as there is no |
| precise timing requirement for when the presentId value is |
| updated. |
| This requires slightly more complexity in the driver as it will |
| need to track all outstanding presentId values. |
| |
| === Examples |
| |
| === Version History |
| |
| * Revision 1, 2019-02-19 (Keith Packard) |
| - Initial version |