Pipeline barriers across multiple shaders?

Question

Judging by Vulkan barriers explained, it seems like each vkCmdPipelineBarrier introduces a dependency between two subsequent pipeline “runs”. For a typical scenario of a shader A that writes an image and a shader B that samples the same image, it might look like this:

1. dispatch shader that writes to image A
2. vkCmdPipelineBarrier(cmd, VK_PIPELINE_STAGE_COLOR_ATTACHMENT_OUTPUT_BIT, VK_PIPELINE_STAGE_FRAGMENT_SHADER_BIT, ...);
3. dispatch shader that reads from image A

This defines a dependency from the first shader execution's color attachment stage to the second shader execution's fragment stage. But what to do if I want to run independent commands in between? For example

1. dispatch shader that writes to image A
2. dispatch unrelated shader that doesn't touch image A
3. vkCmdPipelineBarrier(cmd, VK_PIPELINE_STAGE_COLOR_ATTACHMENT_OUTPUT_BIT, VK_PIPELINE_STAGE_FRAGMENT_SHADER_BIT, ...);
4. dispatch shader that reads from image A

This still works, but is inefficient: because the fragment shader stage now has to wait for the color attachment output stage of the previous, unrelated shader. How do I specify a dependency on the shader before it?

Answer 1

You are looking for Events. https://vulkan.lunarg.com/doc/view/1.0.57.0/windows/vkspec.html#synchronization-events

Events are a synchronization primitive that can be used to insert a fine-grained dependency between commands submitted to the same queue, or between the host and a queue. Events have two states - signaled and unsignaled. An application can signal an event, or unsignal it, on either the host or the device. A device can wait for an event to become signaled before executing further operations. No command exists to wait for an event to become signaled on the host, but the current state of an event can be queried.

When recording the command buffer, you signal the event via vkCmdSetEvent after an operation. Thereafter vkCmdWaitEvents can be used to define a memory dependency between prior event signal operations and subsequent commands. See https://vulkan.lunarg.com/doc/view/1.0.57.0/windows/vkspec.html#vkCmdWaitEvents.

Make sure to reset the event before using it again via vkCmdResetEvent. And note:

Applications should be careful to avoid race conditions when using events. There is no direct ordering guarantee between a vkCmdResetEvent command and a vkCmdWaitEvents command submitted after it, so some other execution dependency must be included between these commands (e.g. a semaphore).