1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
|
// Copyright 2016-2023 The Khronos Group Inc.
//
// SPDX-License-Identifier: CC-BY-4.0
include::{generated}/meta/{refprefix}VK_KHR_timeline_semaphore.adoc[]
=== Other Extension Metadata
*Last Modified Date*::
2019-06-12
*IP Status*::
No known IP claims.
*Interactions and External Dependencies*::
- This extension interacts with
`apiext:VK_KHR_external_semaphore_capabilities`
- This extension interacts with `apiext:VK_KHR_external_semaphore`
- This extension interacts with `apiext:VK_KHR_external_semaphore_win32`
*Contributors*::
- Jeff Bolz, NVIDIA
- Yuriy O'Donnell, Epic Games
- Faith Ekstrand, Intel
- Jesse Hall, Google
- James Jones, NVIDIA
- Jeff Juliano, NVIDIA
- Daniel Rakos, AMD
- Ray Smith, Arm
=== Description
This extension introduces a new type of semaphore that has an integer
payload identifying a point in a timeline.
Such timeline semaphores support the following operations:
* Host query - A host operation that allows querying the payload of the
timeline semaphore.
* Host wait - A host operation that allows a blocking wait for a timeline
semaphore to reach a specified value.
* Host signal - A host operation that allows advancing the timeline
semaphore to a specified value.
* Device wait - A device operation that allows waiting for a timeline
semaphore to reach a specified value.
* Device signal - A device operation that allows advancing the timeline
semaphore to a specified value.
=== Promotion to Vulkan 1.2
All functionality in this extension is included in core Vulkan 1.2, with the
KHR suffix omitted.
The original type, enum and command names are still available as aliases of
the core functionality.
include::{generated}/interfaces/VK_KHR_timeline_semaphore.adoc[]
=== Issues
1) Do we need a new object type for this?
*RESOLVED*: No, we just introduce a new type of semaphore object, as
`VK_KHR_external_semaphore_win32` already uses semaphores as the destination
for importing D3D12 fence objects, which are semantically close/identical to
the proposed synchronization primitive.
2) What type of payload the new synchronization primitive has?
*RESOLVED*: A 64-bit unsigned integer that can only be set to strictly
increasing values by signal operations and is not changed by wait
operations.
3) Does the new synchronization primitive have the same signal-before-wait
requirement as the existing semaphores do?
*RESOLVED*: No.
Timeline semaphores support signaling and waiting entirely asynchronously.
It is the responsibility of the client to avoid deadlock.
4) Does the new synchronization primitive allow resetting its payload?
*RESOLVED*: No, allowing the payload value to "`go backwards`" is
problematic.
Applications looking for reset behavior should create a new instance of the
synchronization primitive instead.
5) How do we enable host waits on the synchronization primitive?
*RESOLVED*: Both a non-blocking query of the current payload value of the
synchronization primitive, and a blocking wait operation are provided.
6) How do we enable device waits and signals on the synchronization
primitive?
*RESOLVED*: Similar to `VK_KHR_external_semaphore_win32`, this extension
introduces a new structure that can be chained to slink:VkSubmitInfo to
specify the values signaled semaphores should be set to, and the values
waited semaphores need to reach.
7) Can the new synchronization primitive be used to synchronize presentation
and swapchain image acquisition operations?
*RESOLVED*: Some implementations may have problems with supporting that
directly, thus it is not allowed in this extension.
8) Do we want to support external sharing of the new synchronization
primitive type?
*RESOLVED*: Yes.
Timeline semaphore specific external sharing capabilities can be queried
using flink:vkGetPhysicalDeviceExternalSemaphoreProperties by chaining the
new slink:VkSemaphoreTypeCreateInfoKHR structure to its
pname:pExternalSemaphoreInfo structure.
This allows having a different set of external semaphore handle types
supported for timeline semaphores vs. binary semaphores.
9) Do we need to add a host signal operation for the new synchronization
primitive type?
*RESOLVED*: Yes.
This helps in situations where one host thread submits a workload but
another host thread has the information on when the workload is ready to be
executed.
10) How should the new synchronization primitive interact with the ordering
requirements of the original sname:VkSemaphore?
*RESOLVED*: Prior to calling any command which may: cause a wait operation
on a binary semaphore, the client must: ensure that the semaphore signal
operation that has been submitted for execution and any semaphore signal
operations on which it depends (if any) must: have also been submitted for
execution.
11) Should we have separate feature bits for different sub-features of
timeline semaphores?
*RESOLVED*: No.
The only feature which cannot be supported universally is timeline semaphore
import/export.
For import/export, the client is already required to query available
external handle types via
flink:vkGetPhysicalDeviceExternalSemaphoreProperties and provide the
semaphore type by adding a slink:VkSemaphoreTypeCreateInfoKHR structure to
the pname:pNext chain of slink:VkPhysicalDeviceExternalSemaphoreInfo so no
new feature bit is required.
=== Version History
* Revision 1, 2018-05-10 (Faith Ekstrand)
** Initial version
* Revision 2, 2019-06-12 (Faith Ekstrand)
** Added an initialValue parameter to timeline semaphore creation
|
