重叠图像障碍的行为是什么？

Question

障碍的标准用法相对简单，但我想知道两个（或更多）重叠图像障碍的行为是什么（特别是关于它们的副作用——布局转换）。例如。（伪代码）：

begin( commandBuffer );
1: write( image );
2: imageBarrier(
     image,
     src=STAGE_FRAGMENT(from the write at 1:),
     dst=STAGE_FRAGMENT(intended for read in FS of read at 4:),
     appropriate src and dst access flags,
     newLayout=A
   );
3: imageBarrier(
     image,
     src=STAGE_FRAGMENT(from the write at 1:),
     dst=STAGE_TRANSFER(intended for read by transfer of readT at 5:),
     appropriate src and dst access flags,
     newLayout=B
   );
4: read( image ); // through vkCmdDraw -- expects layout A
5: readT( image ); // different kind of read through Transfer -- expects layout B
end( commandBuffer );

这合法吗？（你能用规格报价来支持它吗？）
程序各点的图像布局是什么？
为了完整起见，proper/best 的写法是什么（一个生产者，两个消费者的情况）？（交换第 3 行：和第 4 行：并使其成为读-读依赖？）

Answer 1

一张图片不能同时采用多种布局。对于您在上面建议的代码，由于两个障碍彼此没有依赖关系，所以一个会先于另一个发生，但未指定顺序。所以之后图像的布局将是一个或另一个。这意味着两个读取操作之一将失败。

如果您有两个操作使用来自两个不同布局的图像，那么其中一个操作必须先于另一个执行，因为它们都无法读取所需布局中的图像。因此，它们之间必须存在执行依赖性：

1: write( image ); 2: imageBarrier( image, src=COLOR_ATTACHMENT_OUT, dst=FRAGMENT_SHADER, newLayout=A ); 3: read( image ); // e.g. through vkCmdDraw -- expects layout A 4: imageBarrier( image, src=FRAGMENT_SHADER, dst=TRANSFER, newLayout=B ); 5: readT( image ); // different kind of read e.g. Transfer -- expects layout B

#4 中的依赖关系表明布局转换和后续的 TRANSFER 命令只有在所有先前的 FRAGMENT_SHADER 操作完成后才会发生。

make it Read-Read dependency

这不是 "Read-Read dependency"。布局转换修改图像（理论上无论如何），就像您直接将值写入图像一样确定。所以从逻辑上讲，你拥有的是 "I need to read from it in the FS. After that, I have to transition it to a new layout. After that, I need to read from it in a transfer operation".

这是一个"Read-Write-Read dependency."中间部分需要等到第一次读取完成，但是第二次读取要等到中间部分完成后才能进行。您需要具有关联图像内存屏障和布局转换的执行依赖项。

重叠图像障碍的行为是什么？

What's the behavior of overlaping Image Barriers?

vulkan