vulkan - 带有屏障或渲染 channel 的移动图像布局

Question

vulkan 文档提到，与使用障碍(即 VkAttachmentDescription)移动它们相比，渲染 channel 中的移动图像布局(参见 vkCmdPipelineBarrier 结构)是首选。我可以理解，因为后者引入了限制并行执行的同步点。

现在考虑一个典型的例子:从 VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL 的转换至 VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL .在这种情况下，资源将在着色器中被读取，但为了安全地做到这一点，有必要将颜色附件的写入与着色器中的读取同步。换句话说，无论如何我们都需要使用屏障，并且在渲染 channel 中移动布局似乎根本没有任何优势。

可以以某种方式详细解释所有这些是如何工作的吗？在哪些情况下在渲染 channel 中移动布局具有真正的优势？是否存在不需要进一步同步的(实际)布局更改？

Answer 1

首先，你没有选择。 API 强制您提供 finalLayout , 和中级 VkAttachmentReference::layout s。您可以使用 vkCmdPipelineBarrier在渲染 channel 中有条件地(又名子 channel 自依赖)，但规则之一是您是 不是 允许更改附加图像的布局:

If a VkImageMemoryBarrier is used, the image and image subresource range specified in the barrier must be a subset of one of the image views used by the framebuffer in the current subpass. Additionally, oldLayout must be equal to newLayout, and both the srcQueueFamilyIndex and dstQueueFamilyIndex must be VK_QUEUE_FAMILY_IGNORED.

因此，在渲染过程中，您只能使用渲染过程机制更改布局，或者您必须在渲染过程之外。只剩下“外部渲染 channel ”案例需要讨论:

考虑渲染 channel 的好方法是它(可能基于平台)将资源(使用 loadOp )复制到专用内存，完成后将其复制回(使用 storeOp )回通用内存。

话虽如此，假设您可以将布局转换为 finalLayout 是合理的。免费作为 storeOp 的一部分. (类似地，从 initialLayout 到第一个 VkAttachmentReference::layout 的过渡作为 loadOp 的一部分。)因此，如果可能\足够方便，将布局过渡作为渲染 channel 的一部分是有意义的。