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