• Home
  • Line#
  • Scopes#
  • Navigate#
  • Raw
  • Download
1// Copyright 2019-2021 The Khronos Group, Inc.
2//
3// SPDX-License-Identifier: CC-BY-4.0
4
5include::{generated}/meta/{refprefix}VK_KHR_present_wait.txt[]
6
7=== Other Extension Metadata
8
9*Last Modified Date*::
10    2019-05-15
11*IP Status*::
12    No known IP claims.
13*Contributors*::
14  - Keith Packard, Valve
15  - Ian Elliott, Google
16  - Tobias Hector, AMD
17  - Daniel Stone, Collabora
18
19=== Description
20
21This device extension allows an application that uses the
22`apiext:VK_KHR_swapchain` extension to wait for present operations to
23complete.
24An application can use this to monitor and control the pacing of the
25application by managing the number of outstanding images yet to be
26presented.
27
28include::{generated}/interfaces/VK_KHR_present_wait.txt[]
29
30=== Issues
31
321) When does the wait finish?
33
34*RESOLVED*.
35The wait will finish when the present is visible to the user.
36There is no requirement for any precise timing relationship between the
37presentation of the image to the user, but implementations should: signal
38the wait as close as possible to the presentation of the first pixel in the
39new image to the user.
40
412) Should this use fences or other existing synchronization mechanism.
42
43*RESOLVED*.
44Because display and rendering are often implemented in separate drivers,
45this extension will provide a separate synchronization API.
46
473) Should this extension share present identification with other extensions?
48
49*RESOLVED*.
50Yes.
51A new extension, VK_KHR_present_id, should be created to provide a shared
52structure for presentation identifiers.
53
544) What happens when presentations complete out of order wrt calls to
55vkQueuePresent? This could happen if the semaphores for the presentations
56were ready out of order.
57
58*OPTION A*: Require that when a PresentId is set that the driver ensure that
59images are always presented in the order of calls to vkQueuePresent.
60
61*OPTION B*: Finish both waits when the earliest present completes.
62This will complete the later present wait earlier than the actual
63presentation.
64This should be the easiest to implement as the driver need only track the
65largest present ID completed.
66This is also the 'natural' consequence of interpreting the existing
67vkWaitForPresentKHR specificationn.
68
69*OPTION C*: Finish both waits when both have completed.
70This will complete the earlier presentation later than the actual
71presentation time.
72This is allowed by the current specification as there is no precise timing
73requirement for when the presentId value is updated.
74This requires slightly more complexity in the driver as it will need to
75track all outstanding presentId values.
76
77=== Examples
78
79=== Version History
80
81 * Revision 1, 2019-02-19 (Keith Packard)
82   - Initial version
83