通用图形API中rasterizer discard（光栅化丢弃）的适用场景

首先先澄清一个常见的认知偏差：启用光栅化丢弃后，并不会跳过透视除法、视锥体裁剪、视口变换这些为光栅化服务的固定功能几何流程，只是直接终止在光栅化环节入口，不会生成任何片元，后续的片元着色、逐片元测试、帧缓冲写入流程全部不会执行。顶点着色器之后的曲面细分控制/评估着色器、几何着色器、图元组装、变换反馈（流输出）阶段都会完整运行，不是“仅运行顶点着色器”的状态。

核心适用场景 #

• 几何数据处理与复用：当你需要拿到经过完整几何管线（顶点形变、曲面细分、几何着色器图元扩增/变换）处理后的几何数据，不需要实际渲染像素时，就可以开启光栅化丢弃，配合变换反馈把输出的顶点数据写入缓冲区供后续使用。常见用途包括GPU侧粒子系统位置更新、骨骼动画蒙皮后的顶点数据缓存、GPU驱动的遮挡剔除结果输出、广告牌/草叶等程序化生成几何的预计算。
• 性能度量与调试：单独测试几何阶段（顶点、曲面细分、几何着色器）的性能开销时，开启光栅化丢弃可以完全排除片元阶段的算力干扰，拿到更准确的几何阶段耗时数据；调试几何处理逻辑时，也可以用这个模式跳过无意义的片元计算，加快调试迭代速度。
• 辅助渲染算法的前置步骤：比如光源空间的几何数量统计、粗粒度遮挡剔除的深度输入生成、可变率着色的瓦片密度计算等不需要最终颜色输出的前置几何处理步骤，都可以用光栅化丢弃砍掉不必要的片元开销。

为什么不直接用计算着色器替代 #

• 固定功能硬件的效率优势：图形管线的几何阶段有专用的固定功能电路处理图元组装、索引解析、视锥体裁剪、透视除法、曲面细分面片生成这类逻辑，这些逻辑如果用计算着色器手动实现，不仅代码量极大，性能也远追不上专用固定功能单元的效率。比如硬件曲面细分的细分规则是固定的，你在计算着色器里手写一套同等精度的细分逻辑，性能可能差数倍。
• 输入装配逻辑的原生支持：图形管线自带顶点属性解析、索引缓冲遍历、实例化绘制、图元重启等输入装配能力，如果你用计算着色器处理同样的顶点流，所有这些逻辑都要手动实现，对于已经按照图形管线规范组织好的顶点数据来说，属于无意义的重复开发。
• 现有代码的复用成本：绝大多数渲染项目的几何处理逻辑（比如蒙皮、几何着色器做图元扩增）本身就是为图形管线写的，开启光栅化丢弃不需要改写任何着色器代码，就能直接拿到几何阶段的输出结果，如果换成计算着色器，你需要把整套几何处理逻辑重新实现一遍，维护成本极高。

关于“光栅化丢弃是为了支持带曲面细分/几何着色器的管线写缓冲区”的判断 #

这个说法只对了一半。
光栅化丢弃确实覆盖了“跑完全部几何阶段、不输出渲染结果、把数据写入缓冲区”的使用需求，但它的核心定位是消除无效开销，而非专门提供缓冲区写入能力。缓冲区写入的能力来自变换反馈、存储镜像、存储缓冲区这类独立的API特性，在光栅化丢弃特性出现之前，开发者如果想跑几何阶段拿输出结果，必须绑定一个最小尺寸（比如1x1）的帧缓冲，让管线完整跑完光栅化和片元阶段，哪怕根本不需要任何像素输出，平白浪费大量算力。光栅化丢弃的作用就是直接砍掉这部分完全无用的流程，让几何阶段的计算不需要为无意义的片元处理买单。

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