VK_KHR_present_wait(3)

# VK_KHR_present_wait(3) Manual Page

## Name

VK_KHR_present_wait - device extension

Loading… please wait.

## Registered Extension Number

249

## Revision

1

## Ratification Status

Ratified

## Extension and Version Dependencies

VK_KHR_swapchain
and
VK_KHR_present_id

## Contact

- Keith Packard keithp

## 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 `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.

## New Commands

- vkWaitForPresentKHR

## New Structures

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDevicePresentWaitFeaturesKHR

## New Enum Constants

- `VK_KHR_PRESENT_WAIT_EXTENSION_NAME`

- `VK_KHR_PRESENT_WAIT_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PRESENT_WAIT_FEATURES_KHR`

## 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

## See Also

VkPhysicalDevicePresentWaitFeaturesKHR, vkWaitForPresentKHR

## Document Notes

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.

## Copyright

Copyright 2014-2024 The Khronos Group Inc.

SPDX-License-Identifier: CC-BY-4.0