Awkward synchronization requirements imposed on Vulkan-capable implementations

[Ralith]

xrAcquireSwapchainImage is the only function which the application must call before submitting commands that access a swapchain image which is also permitted by XR_KHR_vulkan_enable to access the application's graphics queue. Sharing swapchain images with a compositor requires that the OpenXR implementation submit acquire/release barriers enclosing the application's work on the application's queue, corresponding to release/acquire barriers on the compositor's queue. Hence, xrAcquireSwapchainImage must submit an acquire barrier to a Vulkan application's queue.

Such a barrier must have an execution dependency on the compositor's corresponding "release" barrier. Because a traditional Vulkan semaphore cannot be waited on until a submission has been made that will signal it, implementing such a dependency with one requires blocking the CPU in xrAcquireSwapchainImage on the compositor's submission of its corresponding release barrier, which seems to defeat the purpose of a separate xrWaitSwapchainImage call.

This can be worked around with timeline semaphores, but that prevents compatibility with older drivers, and presumably wasn't the intention of the spec as it leaves xrWaitSwapchainImage as a noop. Alternatively, semaphores could perhaps be replaced with VkEvents that are signaled after blocking the CPU in xrWaitSwapchainImage, but this is unconventional, and events are thought to be poorly supported by most Vulkan implementations.

[rpavlik]

Personally speaking, I suspect that the list of externally-synchronized functions in that extension is outdated (It's definitely not marked-up properly in XML, though I'm not sure how you actually would mark up external-sync requirements added by an extension...)

[rpavlik-bot]

An issue (number 1363) has been filed to correspond to this issue in the internal Khronos GitLab.

If you have a Khronos account, you can access that issue at KHR:openxr/openxr#1363.

[rpavlik]

So my notes say this was addressed in 1.0.13, but the item only clarifies when a swapchain image should be released: it doesn't handle the fact that the runtime is apparently supposed to not touch the queues during a call where a sync primitive is implied. Going to re-open this on the Khronos side, unless you think it's been sufficiently resolved in 1.0.13.

[rpavlik]

Ah, the changelog fragment mentioned this one instead of #50. This one is in fact still open, but #50 has been directly addressed.