Timeline Semaphores?

[Cazadorro]

I'm trying to figure out where timeline semaphores are. As soon as they were introduced in 1.2 (and backported to earlier versions), Khronos recommended them as the default way of synchronization, more than 2 years ago.

As such, the Vulkan working group highly encourages all developers to make the switch to timeline semaphores for all coarse-grained synchronization purposes. To help facilitate this switch while acknowledging the need to support older Vulkan implementations in the field, an implementation of the timeline semaphore API as a Vulkan 1.1 layer has also been provided under the permissive Apache 2.0 license as part of the Vulkan-ExtensionLayer project.

The only place a binary semaphore was required was once for presentation, but only along side a timeline semaphore that you'd actually use in your own code. Timeline semaphores completely eliminate the need for fences, are easier to use between host and device synchronization, and enable a wider variety of scenarios to synchronize.

I searched here and didn't find any discussion about this either, which is surprising if they really aren't supported in a wrapper, because everyone serious I know has moved on to timeline semaphores. That makes me fearful of using this library.

[Rua]

Development of Vulkano mostly stalled shortly after the release of Vulkan 1.1, so it is lacking many newer features, including timeline semaphores. I've been trying to get things up to speed, but there is a lot to do still and I can only work on one thing at a time. In short, Vulkano is far from finished, and any contributions are greatly appreciated!

Btw, there's now a list of all the things that Vulkano supports and is still missing: https://github.com/vulkano-rs/vulkano/blob/master/COVERAGE.md

[Cazadorro]

That's what I was afraid of. Timeline semaphores, buffer device address, and bindless extensions, are all 100% required for anything a large portion of the wider Vulkan community wants to do, and with out those things this library is a complete non starter to them. With out the proper wrappers here, things end up being less safe and take orders of magnitude more code than the equivalent C++ concept, defeating the purpose of moving over here.

And implementing timeline semaphore is not just a matter of "add the code". A semaphore is no longer a semaphore, it's a binary semaphore, and it's conceptually different than a timeline semaphore to the point where they need to be represented as two different types. When you throw safety into the mix, things get real complicated. And then, how do you deal with supporting vulkan versions which don't have this, would you automatically include the layer that emulates timelinesemaphores? Would they be SOL for new releases? Like there needs to be a serious long term pre discussion before even I'd be even touching code, an actual RFC for this library is likely needed.

I do have experience with implementing my own comprehensive Vulkan wrapper (but for c++), though I don't put a major emphasis on safety, so my applicable experience is limited. I could try to put together some sort of RFC initial discussion. The problem is the whole way synchronization part of this library would likely need to be turned upside-down, since it assumes binary semaphore everywhere, and leaves no space for anything else, especially a problem if the default needs to be timelinesemaphore, and I'm not familiar with this library. Though I'm not exactly gunning to start eating my own dog food with this library given these limitations. These kinds of limitations (not just TLS) often make it impossible to do certain types of work in vulkan.

[ShadowJonathan]

And implementing timeline sempahore is not just a matter of "add the code". A semaphore is no longer a semaphore, it's a binary semaphore, and it's conceptually different than a timeline semaphore to the point where they need to be represented as two different types. When you throw safety into the mix, things get real complicated. And then, how do you deal with supporting vulkan versions which don't have this, would you automatically include the layer that emulates timelinesemaphores? Would they be SOL for new releases? Like there needs to be a serious pre discussion before even touching code, an actual RFC for this library.

I'd like to ask you to re-read this section, and ask again why this library doesn't support it.

This library's maintainance and development is volunteer-ran, demanding features is a bad look and bad practice amongst these kinds of things. Vulkano is not official, it is a community-maintained library.

I suggest you'd leave it at just a feature request, or bring in some constructive discussion on how to sufficiently implement it, and then implement it yourself, if you'd want. Demanding, threatening, and insulting the maintainers is not going to get you any favours.

and I don't understand how this library works

Then i suggest reading up on it, maybe you can find a feature or two to implement.

[Neo-Zhixing]

I'm actually working on a new Future trait that uses TimelineSemaphore by default. Timeline semaphore does simplify the implementation of Futures significantly. I'll share the concept here once I think it's ready enough for discussion.

[Rua]

Vulkano needs to support all Vulkan versions, so we can never completely get rid of binary semaphores. But Future should use timeline semaphores if they are available. So there would have to be a mix of the old and the new, where the code decides at runtime which path to follow. Similar code is already found in other areas where an old API was superceded by a newer one, for example when creating a render pass.