Vulkan同步：跨渲染通道深度附件WAW hazard两种方案合理性解析

场景说明：第一个渲染通道写入深度附件，第二个渲染通道复用同一深度附件。官方Vulkan Wiki明确这属于WAW（写后写） hazard，必须通过内存依赖避免写入重排，并给出了子通道依赖的示例代码：

.srcStageMask = VK_PIPELINE_STAGE_LATE_FRAGMENT_TESTS_BIT,  // 存储操作始终在late测试阶段执行，晚于子通道访问
.dstStageMask = VK_PIPELINE_STAGE_EARLY_FRAGMENT_TESTS_BIT, // 加载操作始终在early测试阶段执行，早于子通道访问
.srcAccessMask = VK_ACCESS_DEPTH_STENCIL_ATTACHMENT_WRITE_BIT,
.dstAccessMask = VK_ACCESS_DEPTH_STENCIL_ATTACHMENT_WRITE_BIT | VK_ACCESS_DEPTH_STENCIL_ATTACHMENT_READ_BIT

而Vulkan教程给出的方案看起来有所不同：

.srcStageMask = VK_PIPELINE_STAGE_COLOR_ATTACHMENT_OUTPUT_BIT | VK_PIPELINE_STAGE_EARLY_FRAGMENT_TESTS_BIT;
.srcAccessMask = 0
.dstStageMask = VK_PIPELINE_STAGE_COLOR_ATTACHMENT_OUTPUT_BIT | VK_PIPELINE_STAGE_EARLY_FRAGMENT_TESTS_BIT;
.dstAccessMask = VK_ACCESS_COLOR_ATTACHMENT_WRITE_BIT | VK_ACCESS_DEPTH_STENCIL_ATTACHMENT_WRITE_BIT;

忽略颜色附件相关的阶段与访问位后，教程的方案似乎只提供了执行依赖，没有针对深度附件的内存依赖。下面针对核心问题逐一解析：

一、教程方案为何可行？ #

要搞懂这个问题，得先明确Vulkan依赖的两个核心作用：执行依赖（控制管线阶段的执行顺序）和内存依赖（控制内存操作的可见性）。

教程的方案里，srcAccessMask=0看似没有指定深度相关的内存依赖，但结合同一队列下的执行规则，以及Subpass的阶段覆盖，实际已经满足安全要求：

1. 深度附件的存储操作（写入）始终发生在VK_PIPELINE_STAGE_LATE_FRAGMENT_TESTS_BIT阶段，而加载/后续写入操作发生在VK_PIPELINE_STAGE_EARLY_FRAGMENT_TESTS_BIT阶段。
2. 教程的依赖中，srcStageMask和dstStageMask都包含了EARLY_FRAGMENT_TESTS_BIT，这会强制第一个Subpass的所有早于或等于EARLY阶段的操作完成后，第二个Subpass的EARLY及后续阶段才会启动。而第一个Subpass的深度写入（LATE阶段）必然早于第二个Subpass的EARLY阶段执行，因此执行依赖已经锁死了操作顺序。
3. 同一队列下，只要执行依赖保证了阶段的先后顺序，前一阶段的内存操作结果会自动对后一阶段可见，无需额外显式指定内存依赖。

二、与官方方案是否本质相同？ #

两者本质都是通过执行依赖+内存可见性保证来避免WAW hazard，但粒度和精准度不同：

• 官方方案是精准匹配深度操作的专属阶段：直接锁定深度写入的LATE阶段和后续操作的EARLY阶段，访问掩码也明确指向深度附件的读写操作，没有多余的阶段包含，是最规范、性能最优的写法。
• 教程的方案是宽泛的阶段覆盖：同时包含了颜色附件的阶段，虽然srcAccessMask=0，但通过覆盖EARLY阶段的执行依赖，间接保证了深度操作的顺序。这种写法兼容性更强，但可能包含不必要的阶段，带来微小的性能损耗。

三、若真无内存依赖，为何可接受？ #

其实并非完全没有内存依赖，而是同一队列下的执行依赖已经间接保证了内存可见性。Vulkan规范中，同一队列内的操作，只要通过执行依赖强制前一个阶段的所有操作完成后再执行后一个阶段，前一阶段的内存操作结果就会对后一阶段的操作完全可见。因此即使没有显式指定srcAccessMask，只要执行依赖覆盖了正确的阶段，就能避免写入重排，保证操作安全。

当然，实际项目中更推荐使用官方Wiki的方案，因为它精准针对深度附件的操作逻辑，减少冗余，也更符合Vulkan的规范设计思路。

内容的提问来源于stack exchange，提问作者bdwhst