vulkan - 跨多个着色器的管道障碍？

Question

判断Vulkan barriers explained , 好像每个 vkCmdPipelineBarrier引入了两个后续管道“运行”之间的依赖关系。对于写入图像的着色器 A 和对同一图像进行采样的着色器 B 的典型场景，它可能如下所示:

调度着色器写入图像 A

vkCmdPipelineBarrier(cmd, VK_PIPELINE_STAGE_COLOR_ATTACHMENT_OUTPUT_BIT, VK_PIPELINE_STAGE_FRAGMENT_SHADER_BIT, ...);

从图像 A 读取的调度着色器

这定义了从第一个着色器执行的颜色附加阶段到第二个着色器执行的片段阶段的依赖关系。但是如果我想在两者之间运行独立的命令怎么办？例如

调度着色器写入图像 A

调度不接触图像 A 的无关着色器

vkCmdPipelineBarrier(cmd, VK_PIPELINE_STAGE_COLOR_ATTACHMENT_OUTPUT_BIT, VK_PIPELINE_STAGE_FRAGMENT_SHADER_BIT, ...);

从图像 A 读取的调度着色器

这仍然有效，但效率低下:因为片段着色器阶段现在必须等待前一个不相关着色器的颜色附件输出阶段。如何在它之前指定对着色器的依赖？

Answer 1

您正在寻找事件。
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.

记录命令缓冲区时，您通过 vkCmdSetEvent 发出事件信号手术后。此后 vkCmdWaitEvents可用于定义先前事件信号操作和后续命令之间的内存依赖关系。见 https://vulkan.lunarg.com/doc/view/1.0.57.0/windows/vkspec.html#vkCmdWaitEvents .

确保在通过 vkCmdResetEvent 再次使用之前重置事件.并注意:

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).