New Game Changing Vulkan Extensions for Mobile: Timeline Semaphores

[Samsung Newsroom]

The Samsung Developers team works with many companies in the mobile and gaming ecosystems. We're excited to support our partner, Arm, as they bring timely and relevant content to developers looking to build games and high-performance experiences. This Vulkan Extensions series will help developers get the most out of the new and game-changing Vulkan extensions on Samsung mobile devices.

In previous blogs, we have already explored two key Vulkan extension game changers that will be enabled by Android R. These are Descriptor Indexing and Buffer Device Address. In this blog, we explore the third and final game changer, which is 'Timeline Semaphores'.

The introduction of timeline semaphores is a large improvement to the synchronization model of Vulkan and is a required feature in Vulkan 1.2. It solves some fundamental grievances with the existing synchronization APIs in Vulkan.

The problems with VkFence and VkSemaphore

In earlier Vulkan extensions, there are two distinct synchronization objects for dealing with CPU <-> GPU synchronization and GPU queue <-> GPU queue synchronization.

The VkFence object only deals with GPU -> CPU synchronization. Due to the explicit nature of Vulkan, you must keep track of when the GPU completes the work you submit to it.

vkQueueSubmit(queue, …, fence);

The previous code is the way we would use a fence, and later this fence can be waited on. When the fence signals, we know it is safe to free resources, read back data written by GPU, and so on. Overall, the VkFence interface was never a real problem in practice, except that it feels strange to have two entirely different API objects which essentially do the same thing.

VkSemaphore on the other hand has some quirks which makes it difficult to use properly in sophisticated applications. VkSemaphore by default is a binary semaphore. The fundamental problem with binary semaphores is that we can only wait for a semaphore once. After we have waited for it, it automatically becomes unsignaled again. This binary nature is very annoying to deal with when we use multiple queues. For example, consider a scenario where we perform some work in the graphics queue, and want to synchronize that work with two different compute queues. If we know this scenario is coming up, we will then have to allocate two VkSemaphore objects, signal both objects, and wait for each of them in the different compute queues. This works, but we might not have the knowledge up front that this scenario will play out. Often where we are dealing with multiple queues, we have to be somewhat conservative and signal semaphore objects we never end up waiting for. This leads to another problem …

A signaled semaphore, which is never waited for, is basically a dead and useless semaphore and should be destroyed. We cannot reset a VkSemaphore object on the CPU, so we cannot ever signal it again if we want to recycle VkSemaphore objects. A workaround would be to wait for the semaphore on the GPU in a random queue just to unsignal it, but this feels like a gross hack. It could also potentially cause performance issues, as waiting for a semaphore is a full GPU memory barrier.

Object bloat is another considerable pitfall of the existing APIs. For every synchronization point we need, we require a new object. All these objects must be managed, and their lifetimes must be considered. This creates a lot of annoying “bloat” for engines.

The timeline – fixing object bloat – fixing multiple waits

The first observation we can make of a Vulkan queue is that submissions should generally complete in-order. To signal a synchronization object in vkQueueSubmit, the GPU waits for all previously submitted work to the queue, which includes the signaling operation of previous synchronization objects. Rather than assigning one object per submission, we synchronize in terms of number of submissions. A plain uint64_t counter can be used for each queue. When a submission completes, the number is monotonically increased, usually by one each time. This counter is contained inside a single timeline semaphore object. Rather than waiting for a specific synchronization object which matches a particular submission, we could wait for a single object and specify “wait until graphics queue submission #157 completes.”

We can wait for any value multiple times as we wish, so there is no binary semaphore problem. Essentially, for each VkQueue we can create a single timeline semaphore on startup and leave it alone (uint64_t will not overflow until the heat death of the sun, do not worry about it). This is extremely convenient and makes it so much easier to implement complicated dependency management schemes.

Unifying VkFence and VkSemaphore

Timeline semaphores can be used very effectively on CPU as well:

VkSemaphoreWaitInfoKHR info = { VK_STRUCTURE_TYPE_SEMAPHORE_WAIT_INFO_KHR };
info.semaphoreCount = 1;
info.pSemaphores = &semaphore;
info.pValues = &value;
vkWaitSemaphoresKHR(device, &info, timeout);

This completely removes the need to use VkFence. Another advantage of this method is that multiple threads can wait for a timeline semaphore. With VkFence, only one thread could access a VkFence at any one time.

A timeline semaphore can even be signaled from the CPU as well, although this feature feels somewhat niche. It allows use cases where you submit work to the GPU early, but then 'kick' the submission using vkSignalSemaphoreKHR. The accompanying sample demonstrates a particular scenario where this function might be useful:

VkSemaphoreSignalInfoKHR info = { VK_STRUCTURE_TYPE_SEMAPHORE_SIGNAL_INFO_KHR };
info.semaphore = semaphore;
info.value = value;
vkSignalSemaphoreKHR(device, &info);

Creating a timeline semaphore

When creating a semaphore, you can specify the type of semaphore and give it an initial value:

VkSemaphoreCreateInfo info = { VK_STRUCTURE_TYPE_SEMAPHORE_CREATE_INFO };
VkSemaphoreTypeCreateInfoKHR type_info = { VK_STRUCTURE_TYPE_SEMAPHORE_TYPE_CREATE_INFO_KHR };
type_info.semaphoreType = VK_SEMAPHORE_TYPE_TIMELINE_KHR;
type_info.initialValue = 0;
info.pNext = &type_info;
vkCreateSemaphore(device, &info, NULL, &semaphore);

Signaling and waiting on timeline semaphores

When submitting work with vkQueueSubmit, you can chain another struct which provides counter values when using timeline semaphores, for example:

VkSubmitInfo submit = { VK_STRUCTURE_TYPE_SUBMIT_INFO };
submit.waitSemaphoreCount = 1;
submit.pWaitSemaphores = &compute_queue_semaphore;
submit.pWaitDstStageMask = &wait_stage;
submit.commandBufferCount = 1;
submit.pCommandBuffers = &cmd;
submit.signalSemaphoreCount = 1;
submit.pSignalSemaphores = &graphics_queue_semaphore;
 VkTimelineSemaphoreSubmitInfoKHR timeline = {
VK_STRUCTURE_TYPE_TIMELINE_SEMAPHORE_SUBMIT_INFO_KHR };
timeline.waitSemaphoreValueCount = 1;
timeline.pWaitSemaphoreValues = &wait_value;
timeline.signalSemaphoreValueCount = 1;
timeline.pSignalSemaphoreValues = &signal_value;
submit.pNext = &timeline;
 signal_value++; // Generally, you bump the timeline value once per submission.
 vkQueueSubmit(queue, 1, &submit, VK_NULL_HANDLE);

Out of order signal and wait

A strong requirement of Vulkan binary semaphores is that signals must be submitted before a wait on a semaphore can be submitted. This makes it easy to guarantee that deadlocks do not occur on the GPU, but it is also somewhat inflexible. In an application with many Vulkan queues and a task-based architecture, it is reasonable to submit work that is somewhat out of order. However, this still uses synchronization objects to ensure the right ordering when executing on the GPU. With timeline semaphores, the application can agree on the timeline values to use ahead of time, then go ahead and build commands and submit out of order. The driver is responsible for figuring out the submission order required to make it work. However, the application gets more ways to shoot itself in the foot with this approach. This is because it is possible to create a deadlock with multiple queues where queue A waits for queue B, and queue B waits for queue A at the same time.

Ease of porting

It is no secret that timeline semaphores are inherited largely from D3D12’s fence objects. From a portability angle, timeline semaphores make it much easier to have compatibility across the APIs.

Caveats

As the specification stands right now, you cannot use timeline semaphores with swap chains. This is generally not a big problem as synchronization with the swap chain tends to be explicit operations renderers need to take care of.

Another potential caveat to consider is that the timeline semaphore might not have a direct kernel equivalent on current platforms, which means some extra emulation to handle it, especially the out-of-order submission feature. As the timeline synchronization model becomes the de-facto standard, I expect platforms to get more native support for it.

Conclusion

All three key Vulkan extension game changers improve the overall development and gaming experience through improving graphics and enabling new gaming use cases. We hope that we gave you enough samples to get you started as you try out these new Vulkan extensions to help bring your games to life

Follow Up

Thanks to Hans-Kristian Arntzen and the team at Arm for bringing this great content to the Samsung Developers community. We hope you find this information about Vulkan extensions useful for developing your upcoming mobile games.

The Samsung Developers site has many resources for developers looking to build for and integrate with Samsung devices and services. Stay in touch with the latest news by creating a free account or by subscribing to our monthly newsletter. Visit the Marketing Resources page for information on promoting and distributing your apps and games. Finally, our developer forum is an excellent way to stay up-to-date on all things related to the Galaxy ecosystem.

View the full blog at its source