VK_SHARING_MODE_EXCLUSIVE queue-family ownership transfer under concurrent submissions

VK_SHARING_MODE_EXCLUSIVE queue-family ownership transfer under concurrent submissions

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?