为何越来越多渲染器将直接光照放在计算着色器而非像素着色器？

• 直接光照阶段迁移到计算着色器并非在所有场景、所有硬件上都能获得性能提升，但在当前主流主机、桌面级现代GPU上，针对多光源、带软阴影、材质复杂度较高的生产级渲染管线，计算着色器实现普遍能比传统像素着色器路径获得10%~30%的稳定帧率收益，在填充率压力大、光源数量上百的开放世界场景中收益还会更高。
• 异步计算带来的跨队列并行能力只是选型的加分项，真不是核心原因——很多团队即使不开异步计算，也会优先选择计算着色器实现直接光照，本质是计算着色器的执行模型更适配复杂直接光照的计算特性。

计算着色器方案的核心性能优势（和异步计算无关） #

这些优势是像素着色器的编程模型天生不具备的，也是大部分团队选型的核心出发点：

• 可手动调度片上共享内存：像素着色器的线程虽然也是按wave/warp粒度在GPU上调度，但没有暴露可编程控制的片上共享内存。计算着色器可以按屏幕tile（通常是16x16或32x32像素块）分配线程组，提前在组内做分块光源剔除、阴影图纹素预加载、材质参数复用——比如Forward+管线里最耗性能的多光源遍历，用计算着色器做分块剔除后，每个像素只需要遍历对当前tile有贡献的个位数光源，比像素着色器里逐像素遍历全量光源的效率高一个量级；做PCF软阴影时，还可以把线程组需要的阴影图纹素一次性读入共享内存，所有线程复用，大幅降低显存带宽占用。
• 执行负载可控，无效开销更低：像素着色器的调度完全和光栅化固定流程绑定，光栅器输出像素quad时会自动生成不输出结果的辅助线程（helper lane）处理纹理采样的导数计算，遇到三角形边缘、提前深度测试失败的像素时，这些辅助线程会空跑消耗算力；同时像素着色器无法调整线程分配，遇到简单材质和复杂材质混在同一个wave时会产生严重的线程束分化，整个wave要等最慢的线程跑完才能退出。计算着色器可以自定义线程分组规则，甚至能根据材质复杂度、屏幕区域动态分配计算负载，还能提前跳过所有确定不需要计算的像素，没有多余的辅助线程开销。
• 数据读写更灵活：像素着色器对颜色、深度缓冲的写入是固定的输出绑定模式，无法随机读写其他位置的像素数据，也很难灵活存储中间计算结果。计算着色器可以通过UAV随机读写任意缓冲资源，计算直接光照时可以顺便把漫反射分量、高光分量、光源贡献列表等中间结果存下来，直接给后续SSR、SSAO、后处理阶段复用，省掉大量重复计算的开销。

异步计算的实际作用 #

异步计算确实能带来额外的性能收益，但属于“锦上添花”而非“必须选”的理由：
传统像素着色器的直接光照完全跑在图形队列里，和光栅化、顶点处理等固定功能流程串行执行，GPU的计算单元经常会出现空闲时隙——比如光栅器处理三角形顶点插值、裁剪的时候，计算单元是闲置的。如果把直接光照放到计算队列，通过异步计算和图形队列的光栅化、阴影绘制、后处理等任务并行调度，就能把这些空闲的计算单元利用起来，在不增加额外硬件开销的情况下拿到额外算力。
但要注意，如果场景本身光照逻辑非常简单（比如只有单个平行光、无软阴影、光源数量少于5个），计算着色器路径反而可能更慢——毕竟像素着色器路径里的深度测试、像素坐标映射、quad拼接都是固定功能硬件免费加速的，简单场景下计算着色器自己实现这些逻辑的额外开销，反而会盖过它的性能优势。

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