存在依赖的连续RenderPass同步及subpass渲染相关问题

必须做同步，没有例外。
GPU的指令执行是并行乱序的，提交命令的顺序不代表GPU实际执行的顺序，两个RenderPass之间如果没有显式同步，会出现两类问题：

• 执行时序错乱：第二个RenderPass开始采样时，第一个RenderPass的片元着色、颜色写入操作可能还没执行完，会采样到只渲染了部分的中间结果
• 内存不可见：第一个RenderPass写入渲染纹理的内容可能还驻留在GPU的片上缓存/L2缓存里，没有刷新到全局显存，第二个RenderPass采样时会读到旧的脏数据

不同图形API的同步实现逻辑本质一致：

• Vulkan：需要通过VkSubpassDependency定义跨Pass的执行依赖，同时插入布局转换屏障，将渲染纹理从COLOR_ATTACHMENT_OPTIMAL布局切换到SHADER_READ_ONLY_OPTIMAL布局，同时保证内存可见性
• D3D12：需要在两个Pass之间插入ResourceBarrier，将对应纹理的状态从D3D12_RESOURCE_STATE_RENDER_TARGET转换为D3D12_RESOURCE_STATE_PIXEL_SHADER_RESOURCE
• Metal：需要插入MTLFence或者自定义内存屏障，保证前序Pass的写入完成且对后续采样可见

如果省略同步步骤，会出现偶发花屏、画面撕裂、内容错乱的问题，且问题在不同厂商GPU、不同驱动版本上表现不一致，移动端TBDR架构上出错概率远高于桌面端。

这个问题要分场景判断，结论是subpass无法完全等效独立渲染纹理，仅在非常受限的场景下可以替代两个独立RenderPass：

1. 同尺寸、逐像素访问的场景可以用subpass实现
   如果第一个Pass的输出和swapchain尺寸完全一致，且第二个Pass仅需要按当前片元的对应位置读取第一个Pass的结果（比如基础的色调映射、延迟渲染中GBuffer到光照Pass的逐像素读取），完全可以把两个步骤合并到同一个RenderPass的两个subpass里实现，这种实现方式在移动端TBDR架构上性能远高于两个独立RenderPass——中间结果不需要从片上Tile内存刷回全局显存，带宽开销大幅降低。
2. 主流图形API不支持同一个RenderPass下存在不同尺寸的附件
   Vulkan、D3D12、Metal的规范都明确要求：同一个RenderPass实例绑定的所有附件，尺寸必须和RenderPass设置的renderArea尺寸完全匹配，不存在给不同subpass单独设置不同尺寸附件的能力。如果你的第一个Pass需要渲染低分辨率的中间结果（比如半分辨率的后处理缓冲、小分辨率阴影图），根本无法通过同一个RenderPass的subpass实现。
3. subpass输入附件的能力远弱于独立渲染纹理
   即使尺寸匹配，subpass使用的输入附件也无法替代普通渲染纹理：
   • 访问限制：输入附件仅支持读取当前片元对应位置的纹素，不支持任意UV坐标采样，对采样偏移量、mipmap采样、纹理过滤（双线性/三线性/各向异性）的支持都有严格限制，如果你第二个Pass需要做模糊、扭曲、UV动画这类需要采样非对应位置纹素的操作，输入附件完全无法满足需求
   • 生命周期限制：subpass附件的设计目标是服务于当前RenderPass内部的数据流，如果你需要把第一个Pass的输出复用到其他后续的RenderPass（比如把颜色结果同时给后处理、UI、截图模块用），还是需要把内容写入独立的纹理资源，此时用subpass没有任何收益。

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