使用多VkPipeline向同一附件集渲染的同步与操作符问题

问题1：两次渲染之间是否需要同步/屏障？ #

需要。虽然你当前在AMD GPU上运行无验证层报错，但这属于GPU厂商实现的宽松行为，不符合Vulkan规范的强制要求，在其他GPU（如NVIDIA）上可能出现渲染错误或数据不一致。

原因如下：

• 两次独立的vkCmdBeginRendering/vkCmdEndRendering属于两个独立的渲染实例，Vulkan不会为跨实例的资源访问自动插入同步机制。
• 第二个Pipeline依赖第一个的颜色附件输出，本质是“第一次渲染的写入操作”与“第二次渲染的读取操作”的依赖关系，必须通过显式同步确保：
  1. 第一次渲染的所有写入操作完成并提交到内存（内存可见性）；
  2. 颜色附件的布局状态在两次渲染之间保持兼容（若第一次VkRenderingAttachmentInfo的finalLayout与第二次的initialLayout不一致，还需布局转换屏障）。

你需要在第一次vkCmdEndRendering之后、第二次vkCmdBeginRendering之前插入一个内存屏障，示例如下（针对颜色附件）：

VkImageMemoryBarrier barrier{};
barrier.sType = VK_STRUCTURE_TYPE_IMAGE_MEMORY_BARRIER;
barrier.srcAccessMask = VK_ACCESS_COLOR_ATTACHMENT_WRITE_BIT;
barrier.dstAccessMask = VK_ACCESS_COLOR_ATTACHMENT_READ_BIT;
barrier.oldLayout = VK_IMAGE_LAYOUT_ATTACHMENT_OPTIMAL; // 第一次渲染结束后的布局
barrier.newLayout = VK_IMAGE_LAYOUT_ATTACHMENT_OPTIMAL; // 第二次渲染开始前的布局（若无需转换可设为相同）
barrier.srcQueueFamilyIndex = VK_QUEUE_FAMILY_IGNORED;
barrier.dstQueueFamilyIndex = VK_QUEUE_FAMILY_IGNORED;
barrier.image = colorAttachmentImage;
barrier.subresourceRange = {VK_IMAGE_ASPECT_COLOR_BIT, 0, 1, 0, 1};

vkCmdPipelineBarrier(cmdBuffer,
    VK_PIPELINE_STAGE_COLOR_ATTACHMENT_OUTPUT_BIT,
    VK_PIPELINE_STAGE_COLOR_ATTACHMENT_OUTPUT_BIT,
    0,
    0, nullptr,
    0, nullptr,
    1, &barrier);

问题2：storeOp与loadOp的设置是否安全？ #

你当前的设置是符合规范且安全的，具体分析：

• 第一次渲染：
  • 颜色附件storeOp = VK_ATTACHMENT_STORE_OP_STORE：正确，因为需要保留渲染结果供第二次读取；
  • 深度附件storeOp = VK_ATTACHMENT_STORE_OP_DONT_CARE：正确，因为第二次渲染不依赖深度附件的结果，无需保留。
• 第二次渲染：
  • 颜色附件loadOp = VK_ATTACHMENT_LOAD_OP_LOAD：正确，明确要读取第一次渲染的结果；
  • 深度附件loadOp = VK_ATTACHMENT_LOAD_OP_DONT_CARE：正确，因为不需要使用之前的深度数据，会直接覆盖或不关心初始值。

需要注意的是，该设置的安全性建立在同步机制正确的前提下，若缺少必要的屏障，即使操作符设置正确，仍可能出现数据异常。

补充：单次渲染内切换Pipeline的差异 #

在单次vkCmdBeginRendering/vkCmdEndRendering序列内切换Pipeline，属于同一个渲染实例的内部操作，Vulkan规范会自动保证后续Pipeline能看到前序渲染的结果，无需额外同步。这种方式效率更高，也更符合动态渲染的设计初衷，但如果存在管线仅共享部分附件的场景，两次独立渲染的方式更灵活，此时必须严格处理同步与附件操作符。

内容的提问来源于stack exchange，提问作者test failed in 1.08s