KhronosGroup / KhronosGroup/Vulkan-Docs
Support for DRM `syncobj` FDs in `vkGetSemaphoreKHR`/`vkImportSemaphoreFdKHR`
- Dominant language
- JavaScript
- Stars
- 3.3k
- Forks
- 549
- Avg merge
- 5d 5h
- Merged PRs (30d)
- 2
Description
[DRM timeline sync objects](https://www.kernel.org/doc/html/v5.4/gpu/drm-mm.html?highlight=syncobj#drm-sync-objects) seem tailor-made for interop with Vulkan timeline semaphores. However, while it's possible to import these using [`vkImportSemaphoreFdKHR`](https://registry.khronos.org/VulkanSC/specs/1.0-extensions/man/html/vkImportSemaphoreFdKHR.html) and `VK_EXTERNAL_SEMAPHORE_HANDLE_TYPE_OPAQUE_FD_BIT` on some drivers, there are a few issues that make importing/exporting unergonomic:
- When importing, the `SYNC_FD` type seems more correct, and it's not clear in the spec which should be used in this case (unless I missed it). However, `SYNC_FD` is restricted to temporary binary semaphore imports, and does not allow permanent timeline semaphore imports.
- When exporting a semaphore as a FD using [`vkGetSemaphoreFdKHR`](https://registry.khronos.org/VulkanSC/specs/1.0-extensions/man/html/vkGetSemaphoreFdKHR.html), there's no way to distinguish what type of FD you're getting.
Should syncobjs be covered by an additional enum value in [`HandleTypeFlagBits`](https://registry.khronos.org/VulkanSC/specs/1.0-extensions/man/html/VkExternalSemaphoreHandleTypeFlagBits.html)? Or should the the spec/validation be relaxed to allow timeline semaphores to be imported/exported using `SYNC_FD`?
Contributor guide
Assessment
This issue has not been assessed yet.