C Specification

The VkPastPresentationTimingGOOGLE structure is defined as:

// Provided by VK_GOOGLE_display_timing
typedef struct VkPastPresentationTimingGOOGLE {
    uint32_t    presentID;
    uint64_t    desiredPresentTime;
    uint64_t    actualPresentTime;
    uint64_t    earliestPresentTime;
    uint64_t    presentMargin;
} VkPastPresentationTimingGOOGLE;

Members

  • presentID is an application-provided value that was given to a previous vkQueuePresentKHR command via VkPresentTimeGOOGLE::presentID (see below). It can be used to uniquely identify a previous present with the vkQueuePresentKHR command.

  • desiredPresentTime is an application-provided value that was given to a previous vkQueuePresentKHR command via VkPresentTimeGOOGLE::desiredPresentTime. If non-zero, it was used by the application to indicate that an image not be presented any sooner than desiredPresentTime.

  • actualPresentTime is the time when the image of the swapchain was actually displayed.

  • earliestPresentTime is the time when the image of the swapchain could have been displayed. This may differ from actualPresentTime if the application requested that the image be presented no sooner than VkPresentTimeGOOGLE::desiredPresentTime.

  • presentMargin is an indication of how early the vkQueuePresentKHR command was processed compared to how soon it needed to be processed, and still be presented at earliestPresentTime.

Description

The results for a given swapchain and presentID are only returned once from vkGetPastPresentationTimingGOOGLE.

The application can use the VkPastPresentationTimingGOOGLE values to occasionally adjust its timing. For example, if actualPresentTime is later than expected (e.g. one refreshDuration late), the application may increase its target IPD to a higher multiple of refreshDuration (e.g. decrease its frame rate from 60Hz to 30Hz). If actualPresentTime and earliestPresentTime are consistently different, and if presentMargin is consistently large enough, the application may decrease its target IPD to a smaller multiple of refreshDuration (e.g. increase its frame rate from 30Hz to 60Hz). If actualPresentTime and earliestPresentTime are same, and if presentMargin is consistently high, the application may delay the start of its input-render-present loop in order to decrease the latency between user input and the corresponding present (always leaving some margin in case a new image takes longer to render than the previous image). An application that desires its target IPD to always be the same as refreshDuration, can also adjust features until actualPresentTime is never late and presentMargin is satisfactory.

See Also

VK_GOOGLE_display_timing, vkGetPastPresentationTimingGOOGLE

Document Notes

For more information, see the Vulkan Specification

This page is extracted from the Vulkan Specification. Fixes and changes should be made to the Specification, not directly.

Copyright

Copyright 2014-2024 The Khronos Group Inc.

SPDX-License-Identifier: CC-BY-4.0