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