禁用深度测试与将深度比较操作设为ALWAYS的差异及性能分析

直接禁用深度测试相比仅将深度比较操作配置为ALWAYS是存在明确优势的，二者并不是等价的管线配置，最突出的差异体现在硬件资源调用逻辑和渲染效率上，绝大多数场景下禁用深度测试的性能表现更优。

两种配置虽然最终视觉表现几乎一致（只要不修改其他深度相关状态），但在图形API和GPU硬件的执行逻辑上存在本质区别：

• 深度缓冲访问逻辑不同：当开启深度测试、比较函数设为ALWAYS时，深度测试模块本身仍处于激活状态：如果深度写入掩码处于开启状态，所有光栅化产出的片元都会将自身深度值写入深度缓冲区；哪怕手动关闭深度写入，部分硬件实现仍会在管线流程中读取对应位置的深度缓冲值，为可能的状态修改预留通路。而直接禁用深度测试后，GPU会完全切断对深度缓冲的所有读写通路，无论深度写入掩码是什么状态，都不会触碰深度缓冲对应的内存地址，也不会触发任何深度相关的内存操作。
• 管线调度逻辑不同：深度比较设为ALWAYS时，固定功能管线中的深度测试阶段、提前深度测试（Early-Z）单元仍然会被调度，只是比较逻辑固定返回“通过”结果，片元仍然需要走过完整的深度处理流水段；同时所有和深度测试结果绑定的联动逻辑（比如模板测试的深度通过/失败触发动作、深度值钳位、保守深度判断等）仍然会正常执行。而禁用深度测试后，整个深度相关的固定功能单元会被硬件直接旁路，所有依赖深度测试结果的联动逻辑都不会被触发，片元处理流水线长度更短。
• 驱动优化空间不同：开启深度测试时，哪怕比较函数是ALWAYS，驱动在编译管线状态对象（PSO）、着色器时，也必须保留所有和深度计算、深度输出相关的指令——比如着色器中手动输出片元深度的gl_FragDepth/SV_Depth指令，驱动不敢随意裁掉，要为后续可能的深度状态修改预留支持。而明确禁用深度测试后，驱动可以直接剔除所有深度相关的指令，不需要为这部分逻辑预留硬件资源。
• 异常行为边界不同：如果当前帧缓冲没有绑定深度附件，开启深度测试（哪怕比较函数是ALWAYS）会触发API的未定义行为，不同驱动可能出现渲染错误、甚至设备崩溃；但直接禁用深度测试时，哪怕帧缓冲没有深度附件也属于合法状态，不会出现异常。

在绝大多数桌面、移动GPU实现中，直接禁用深度测试的渲染效率都会高于“开启深度测试+比较函数为ALWAYS”的配置，性能收益的核心来源有三个：

• 节省大量内存带宽：这是最主要的收益来源，尤其是在移动端Tile-Based渲染架构下表现更明显。开启深度测试时，哪怕比较函数永远通过，硬件仍然需要为深度缓冲预留带宽：如果开启深度写入，每个片元都要执行一次深度缓冲写操作；哪怕关闭深度写入，部分硬件仍会在Tile加载阶段把深度缓冲数据从显存读到片上高速缓存，渲染结束后再写回。而禁用深度测试后，硬件完全不需要为深度缓冲分配Tile缓存空间，既不会加载也不会写回深度数据，在高分辨率渲染、全屏后处理、大量透明物体渲染等不需要深度的Pass中，这部分带宽节省往往能带来10%以上的帧率提升。
• 提升片元吞吐效率：开启深度测试时，哪怕比较逻辑没有实际剔除效果，每个片元仍然要经过深度测试固定功能单元的流水段，会带来微小的流水线延迟，在片元吞吐量拉满的场景下（比如存在大量overdraw的粒子渲染），这部分延迟会累积成可见的性能损耗。禁用深度测试后，片元从光栅化阶段输出后可以直接进入后续的颜色混合流程，跳过了不必要的流水段，单位时间内能处理的片元数量更高。
• 降低着色器开销：前面说过，禁用深度测试后驱动可以直接裁掉着色器中所有计算、输出片元深度的指令，哪怕着色器里写了自定义深度输出的逻辑，也不会生成对应的硬件指令，能直接减少着色器的执行周期。

注：有部分年份较早的桌面驱动会对“深度比较设为ALWAYS+深度写入关闭”的组合做特殊适配，自动把这个状态替换成禁用深度测试的逻辑，但这属于厂商驱动的个例优化，不是跨硬件、跨图形API的通用行为，开发时不能默认二者等价。

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