Semaphore Wait-Before-Signal

The Vulkan SC Specification describes wait-before-signal in section "6.6 Queue Forward Progress" for timeline semaphores. Timeline semaphores are VkSemaphore objects created as type VK_SEMAPHORE_TYPE_TIMELINE.

The benefits of wait-before-signal justify supporting it with timeline semaphores. Using wait-before-signal can reduce synchronization latency by removing CPU host operations from the critical path of GPU and device synchronization. Likewise, synchronizing work with a wait-before-signal of Deterministic Fences (using VK_NV_external_sci_sync2 to interoperate with NvStreams) can avoid the Inter-Process Communication (IPC) overhead of sharing NvStreams NvSciSyncFence objects at runtime that would otherwise be necessary.

Design with care when using wait-before-signal synchronization in Vulkan SC applications. Problems with use of wait-before-signal can subtly introduce hangs of Vulkan SC commands or create long latencies that end with timeouts. If the GPU is waiting for a signal from the CPU at the same time the CPU is waiting, the system can enter a deadlock state until a timeout elapses.

To preclude any such hangs, you have the option of not enabling the timelineSemaphore feature.

When your application requests timeline semaphore wait-before-signal, with the waits on a CPU or GPU, the wait will not complete successfully if the signal operation becomes delayed indefinitely. These hang conditions can occur with native timeline semaphores, and with NvSciSync interoperability to VkSemaphore objects. The high-level guidance to ensure queue forward progress while using wait-before-signal is as follows:

1. For each counter value of a timeline semaphore that your application waits upon, the signaler must not be delayed by the waiters.
2. Consider in your control flow analysis that the VkQueue objects contain FIFO buffers of calibratable fixed size in this Vulkan SC implementation.