Validation message between queue families produced Aquire/Release errors

Hi All,

I have a 2 queue upload and present setup, and the queues are on different families. (No reported issue if queue are on the same queue family) I have barriers in place for layout changes in the first queue and barriers in place for queue family changes in the second queue. And I get the following validation messages:

Log: VK: Msg: ERROR 0x1000 0x0002 0 ‘UNASSIGNED-VkImageMemoryBarrier-image-00004’ ‘vkQueueSubmit(): in submitted command buffer VkImageMemoryBarrier aquiring ownership of VkImage (0x16), from srcQueueFamilyIndex 1 to dstQueueFamilyIndex 0 has no matching release barrier queued for execution.’
Log: VK: Msg: WARN 0x0100 0x0002 0 ‘UNASSIGNED-VkImageMemoryBarrier-image-00003’ ‘vkQueueSubmit(): VkImageMemoryBarrier releasing queue ownership of VkImage (0x28 ), from srcQueueFamilyIndex 0 to dstQueueFamilyIndex 1 duplicates existing barrier queued for execution, without intervening acquire operation.’

Does anybody know what these messages are requesting me to change? Or what I have have done wrong?

Thanks.

1 Like

Your queue transfer synchronization is invalid.

The layers can’t find the previous release barrier for your acquire barrier, which must be identical (valid match).

For transfer there must be two barriers (one in each queue). One is relese, one is acquire. The arguments of those two barriers must match exactly (except dst stage and mask for release and src stage and mask for acquire should be ignored by driver). There should be synchronization between the two (e.g. a Semaphore).

From your log it is weird the release barrier warning is after the acquire. Make sure the release is submitted to the original queue, before the acquire to the new queue. It is also suspicious that srcQueueFamilyIndex differs as well as image.

From your log it is weird the release barrier warning is after the acquire

I think that was a bad copy/paste, this is the message when the pipe depth is only 1:

Log: VK: Msg: ERROR 0x1000 0x0002 0 ‘UNASSIGNED-VkImageMemoryBarrier-image-00004’ ‘vkQueueSubmit(): in submitted command buffer VkImageMemoryBarrier aquiring ownership of VkImage (0x16), from srcQueueFamilyIndex 1 to dstQueueFamilyIndex 0 has no matching release barrier queued for execution.’
Log: VK: Msg: WARN 0x0100 0x0002 0 ‘UNASSIGNED-VkImageMemoryBarrier-image-00003’ ‘vkQueueSubmit(): VkImageMemoryBarrier releasing queue ownership of VkImage (0x16), from srcQueueFamilyIndex 0 to dstQueueFamilyIndex 1 duplicates existing barrier queued for execution, without intervening acquire operation.’

The layers can’t find the previous release barrier for your acquire barrier, which must be identical (valid match).

Are you saying that I have to change the queue families in both queues?
At present the first queue just does a memory barrier, no queue family changes. In the second queue it changes the queue family.

Yes. In the original queue you must submit a releasing barrier. And in the new queue family you must submit a acquiring barrier:
https://www.khronos.org/registry/vulkan/specs/1.0/html/vkspec.html#synchronization-queue-transfers

Or if you do not care about the data (e.g. reusing Image after present), you can do so with no queue family transfer.

Thank you very much, this is exactly what I was missing. And that link is spot on.

How to set dstStage of release barrier and srcStage of acquire barrier? I didn’t find vulkan spec define this.

In whichever way that ensures:

An application must ensure that these operations occur in the correct order by defining an execution dependency between them, e.g. using a semaphore.