VK_SHARING_MODE_EXCLUSIVE queue-family ownership transfer under concurrent submissions

Question

For a VkImage or VkBuffer created with VK_SHARING_MODE_EXCLUSIVE, concurrent access from multiple queue families requires an explicit ownership release barrier in the source queue family and an acquire barrier in the destination family, ordered by semaphores or fences. The specification defines the required ordering and visibility, but it does not define how much internal serialization or implicit layout-transition latency an implementation may add while remaining conformant.

This creates an unresolved scheduling question: when two unrelated submissions target different queues but touch the same exclusive resource, a driver may internally lock queue submission, descriptor updates, memory mappings, or sparse operations in ways that serialize otherwise independent work. The same barrier graph can therefore exhibit different latency across drivers, queue configurations, or Vulkan versions, even when all explicit synchronization is correct.

Is there a documented boundary between permissible internal scheduling and a conformance concern when cross-queue ownership transfers introduce latency only under concurrent requests? How should an application reason about the performance impact of VK_SHARING_MODE_EXCLUSIVE versus VK_SHARING_MODE_CONCURRENT without assuming a specific driver scheduling strategy? What verification approach distinguishes a missing barrier from implementation-defined cross-queue serialization?

Tasadduq Burney · Answer

Direct answerNo. The Vulkan specification does not document a maximum latency or scheduling boundary for VK_SHARING_MODE_EXCLUSIVE ownership transfers. It requires only that a release barrier in the source queue family and an acquire barrier in the destination family create the specified happens-before ordering. Any extra internal serialization a driver adds while preserving that ordering is conformant, so latency that appears only under concurrent submissions is not, by itself, a conformance concern.Confirmed factsExclusive resources are owned by one queue family at a time; transfers require srcQueueFamilyIndex and dstQueueFamilyIndex on the appropriate memory barrier.The specification does not bound driver-internal locking, submission serialization, or layout-transition latency.Validation layers report missing or incorrectly ordered ownership barriers; they do not flag performance-only internal scheduling.VK_SHARING_MODE_CONCURRENT removes ownership barriers but may introduce other costs, such as additional memory bandwidth or driver-level serialization for simultaneous access.Verification steps for this caseRun with VK_LAYER_KHRONOS_validation enabled. If ownership-transfer warnings appear, correct the barrier graph before measuring performance.Place timeline semaphore signals, or calibrated-timestamp markers if available, immediately around the release and acquire barriers.Measure the resource access from one queue family as a baseline, then repeat with concurrent submissions from different queue families.If latency increases only in the concurrent case and validation layers are silent, attribute the difference to permissible implementation-defined scheduling rather than a missing barrier.Optionally recreate the resource with VK_SHARING_MODE_CONCURRENT and compare. Lower concurrent latency indicates ownership-transfer overhead dominates; similar latency points to other factors.How to reason about EXCLUSIVE versus CONCURRENTTreat VK_SHARING_MODE_EXCLUSIVE as potentially higher-latency when ownership changes frequently, but do not assume a fixed driver cost. Profile on the target queue families and hardware. Use VK_SHARING_MODE_CONCURRENT only when measurement shows the transfer overhead outweighs its possible access costs, or when you can avoid transfers entirely with dedicated resources or double-buffering.One missing diagnostic detail that changes the recommendation: are validation-layer ownership-transfer warnings present during the latency measurement? If yes, fix the synchronization first; if no, proceed with the performance comparison above.

VK_SHARING_MODE_EXCLUSIVE queue-family ownership transfer under concurrent submissions

VK_SHARING_MODE_EXCLUSIVE queue-family ownership transfer under concurrent submissions

1 answer

Direct answer

Confirmed facts

Verification steps for this case

How to reason about EXCLUSIVE versus CONCURRENT

Your perspective belongs here.

0 question comments