Support the VK_KHR_timeline_semaphore extension. #1124
Conversation
This implementation uses `MTLSharedEvent` where possible, and emulates it on the host otherwise. Unlike binary semaphores, `MTLSharedEvent`s map well to timeline semaphores; there should be no problems using them when they're available. I'm extremely confident in the `MTLSharedEvent`-based implementation. It passes nearly all the synchronization tests. I'm less confident in the emulated implementation.
| return new MVKSemaphoreMTLEvent(this, pCreateInfo); | ||
| } else { | ||
| return new MVKSemaphoreEmulated(this, pCreateInfo); | ||
| } |
There was a problem hiding this comment.
Currently, by default, _useMTLFenceForSemaphores is enabled and _useMTLEventForSemaphores is disabled, which means regular VkSemaphores will prefer using MTLFence over MTLEvent.
Given that if a timeline semaphore is requested, we must use MTLSharedEvent, should we re-evaluate and possibly flip this? Is there any drive or appetite to prefer using MTLEvent over MTLFence for regular VkSemaphores?
There was a problem hiding this comment.
IIRC the reason for preferring MTLFence for binary semaphores is that we observed problems when MTLEvents were used with presentation, where waits would time out and subsequently cause the system to revoke access to the device. The presentation code has changed significantly since then, but I'm still investigating whether or not it's safe to start using MTLEvent again.
(I keep forgetting that most people don't have memories as long as mine. How ironic.)
There was a problem hiding this comment.
I keep forgetting that most people don't have memories as long as mine. How ironic. (🤦🏻♂️...for the irony joke).
Yeah...raw memory is definitely not my strong suit. I'd not survive long in medical school. 😉
Sorry...I didn't expect you to troll back into the previous change triggers...but was more looking for your thoughts on whether either our code has evolved...or Apple's MTLEvent code has...based on the sync testing you were doing.
The presentation code has changed significantly since then, but I'm still investigating whether or not it's safe to start using MTLEvent again.
Okay. Thanks for the review. If you do continue to investigate and it reveals that MTLEvents make sense, we can flip back.
This implementation uses
MTLSharedEventwhere possible, and emulatesit on the host otherwise. Unlike binary semaphores,
MTLSharedEventsmap well to timeline semaphores; there should be no problems using them
when they're available.
I'm extremely confident in the
MTLSharedEvent-based implementation. Itpasses nearly all the synchronization tests. I'm less confident in the
emulated implementation.