Timeline semaphore

The existing semaphore type is now called a BINARY semaphore, as signals and waits must always happen in 1:1 pairs. Completing a wait for a semaphore on the VkQueue also unsignals it. This is problematic for more advanced use cases where we wish to create a single producer, multiple consumers scenario. To make binary semaphores work, we would have to signal multiple semaphores in a single vkQueueSubmit, and then assign one semaphore to each waiting queue. This is rather awkward, since it might not be obvious at signal time how this scenario will play out, and juggling N semaphores just for this case is not fun.

When juggling N semaphores, it might also happen that a semaphore was not required after all, and we are now sitting with a signalled semaphore which cannot be recycled and signalled again unless we wait for it first. The solution here is to just destroy such "hung" semaphores, which is unfortunate. Ideally we would be able to reset semaphores on the host as well, but no such API exists and submitting a wait to GPU just for the purpose of unsignalling a semaphore is silly.

There is also an object bloat problem. Usually, there are many submissions in flight on a GPU, and to be able to synchronize with each submission, we must keep track of a certain number of semaphores which are in-flight at any one time. This is doable, but inelegant. There is a similar problem for VkFence as well.

The final problem is a lack of out-of-order signal and wait. This is a somewhat of a niche problem, but in a world with free threaded task graphs, it could make sense to be able to submit work out of order and let synchronization objects take care of synchronization on the GPU. With binary semaphores, a signal must be submitted before the wait, which guarantees forward progress, but guarantees jank in the engine. There are certainly good reasons for this restriction, but it removes some flexibility.

In order to signal on a VkQueue, we wait for everything that happened before we signal anything. This also means that future signal operations will wait for a superset of the operations in the signal that came before. In this sense, instead of thinking of synchronizing against individual submissions, we can think about things like "Wait for submission #134 on compute queue to complete", i.e. we just associate a single monotonically increasing number to a queue. Submitting to a VkQueue can now be considered a simple increment of the monotonically increasing number.

This is the foundation of timeline semaphores. A VkSemaphore can have a 64-bit counter associated with it and there are two new operations we can do:

From an application point of view, there is no longer a need to own synchronization objects and applications can instead agree on 64-bit counters.

Timeline semaphores also adds support for submitting waits before the corresponding signal operation. This hands over the burden to the driver, where it will need to either hold back submissions on its own, or defer this work to the kernel driver. Either way, the application no longer needs to hold back submissions.

This can be quite useful when applications have multiple threads which perform queue submission, since ensuring ordering otherwise would require a lot of careful thread synchronization.

There is no unsignal operation with timeline semaphores, so it’s perfectly fine to do something like:

Once the counter reaches 40, it will always be at least 40, and we can keep waiting for this counter as long as we wish.

VkFence is somewhat redundant when we have timeline semaphores, since we can now wait for counter values on CPU as well. There is not even a requirement to externally synchronize VkSemaphore objects when doing so, which is very nice! To synchronize GPU work with CPU, we just need to know the timeline value we signalled with.

In this sample, we make use of two VkQueues, an async compute queue which performs simulation, and the main graphics queue which blits to swapchain and presents the results. The two queues need to carefully synchronize with each other. This sample could trivially be done with binary semaphores of course, so in this sample we implement it in a difficult way to demonstrate the full API capabilities.

The key aspects we use to demonstrate out of order submission are dedicated workers thread which perform all work related to simulation on the async compute queue, and drawing on the graphics queue. They never synchronize with the main thread except at teardown, so the only way to synchronize them is through timeline semaphores. To avoid issues when running the sample on Windows platforms (particularly when resizing the window), forward progress in the queues is throttled by the main thread (i.e. only allowing the timeline to advance when a render call is active).

To simulate "Game of Life", we allocate two images of 64x64 RGBA8. First, one image is initialized with initial state, and from here there is a ping-pong where image N is updated, while reading from image 1 - N. After updating image N, the main thread will sample from image N.

The sequential flow of the rendering is something like:

And so on …​ With out of order signal, we can end up observing this order of submissions instead.

When submitting out of order, it is important that you don’t just submit work way ahead of where the GPU actually is, since the latency becomes extremely large. The natural place to keep submission explosion under control here is the place where we wait for the timeline on host, since we need to re-record command buffers anyways.

When submitting out-of-order we end up in a situation where a queue cannot see any forward progress until another queue submits. Calling vkDeviceWaitIdle at this point triggers a deadlock of the application since vkDeviceWaitIdle will never finish, as there is one queue which cannot make forward progress. While calling vkDeviceWaitIdle, you cannot call vkQueueSubmit due to external synchronization rules.

Instead, just wait for timeline semaphores on host to "drain" the GPU, or if you must use API calls, use vkQueueWaitIdle and only wait on queues which you need.

Similar to vkDeviceWaitIdle, when tearing down the application, an out-of-order submission might be waiting on work which never comes, and that queue becomes deadlocked. To alleviate this, we can make use of host signalling of timeline semaphores to unblock everything in one fell swoop.

From TimelineSemaphore::finish_timeline_workers():

From TimelineSemaphore::finish_timeline_workers():

Since this sample needs to run on all implementations which support timeline semaphores, the sample also demonstrates the limitations of out-of-order queue submissions. It’s easy to land in a situation where you deadlock the GPU or driver which only happens on single queue Vulkan implementations. There are two fixes we need to make this work.