Support for DRM `syncobj` FDs in `vkGetSemaphoreKHR`/`vkImportSemaphoreFdKHR`

[colinmarc]

DRM timeline sync objects seem tailor-made for interop with Vulkan timeline semaphores. However, while it's possible to import these using vkImportSemaphoreFdKHR 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, there's no way to distinguish what type of FD you're getting.

Should syncobjs be covered by an additional enum value in HandleTypeFlagBits? Or should the the spec/validation be relaxed to allow timeline semaphores to be imported/exported using SYNC_FD?

[oddhack]

@linyaa-kiwi this looks like an SI TSG issue.

[linyaa-kiwi]

cc @gfxstrand

[cubanismo]

Neither VK_EXTERNAL_SEMAPHORE_HANDLE_TYPE_OPAQUE_FD_BIT (FD referring to an undefined (hence "opaque") object type with limited functionality requirements defined by Vulkan. Might refer to a DRM syncobj, might not) nor VK_EXTERNAL_SEMAPHORE_HANDLE_TYPE_SYNC_FD_BIT (Linux sync_file) correspond to DRM syncobj FDs. They would need a new handle type enum. There was some dithering in the past about whether DRM syncobj timelines were an object that should be surfaced by more application-visible APIs like Vulkan as opposed to treated as driver-internal constructs, but I think other parts of the ecosystem have embraced them enough that it probably makes sense to include them in Vulkan as well at this point.

[colinmarc]

@cubanismo importing a syncobj timeline from wayland as VK_EXTERNAL_SEMAPHORE_HANDLE_TYPE_OPAQUE_FD_BIT actually just stopped working for me on NVIDIA 560/565. I swear it was working before. Here is the code where I import it.

My DebugUtilsMessenger spits out the error Failed to allocate semaphore device memory. Is that intended to be working today or did I misunderstand something about the current support?

[cubanismo]

No, it's not expected to work. It would never have worked. The NV Linux driver doesn't use DRM syncobj (Or DRM at all) to implement timeline semaphores and never has, so at best it might have been silently failing before, but we just verified it's been returning the correct error message in this case while following up on a another bug report, so I'm doubtful that was happening.

[mahkoh]

On systems where VK_EXTERNAL_SEMAPHORE_HANDLE_TYPE_OPAQUE_FD_BIT is syncobj you can detect this today by calling one of the DRM icotls that expect syncobj arguments. If so, you can use the syncobj as you would if there were an official extension, I believe.