绘制调用与状态切换优化

调用图形 API 的开销主要在 CPU 端的驱动里：状态切换昂贵，每次绘制调用有固定开销，大量小批次会让 GPU"饿死"。对策是：合理放置缓冲；按状态代价排序分组；共享纹理和着色器；合并网格和实例化以减少调用；并用一个整数排序键同时兼顾状态分组与前后排序。

缓冲的放置（18.4.2 节）

独立显卡的桌面系统 CPU 与 GPU 各有内存，驱动决定资源位置但可接受提示：每帧变化的数据用动态缓冲（不需要 GPU 上的永久存储）；不变形或只靠着色器变形（如蒙皮）的物体用静态缓冲存放在 GPU 内存，避免每帧经总线传输——GPU 内部带宽远高于 CPU-GPU 总线。
主机、集成显卡笔记本和移动设备多为统一内存，仍应正确标记资源为仅 CPU 或仅 GPU：两者都访问的区域一方写入后另一方必须使缓存失效，代价很高。

状态切换的代价

API 调用越多应用时间越多；依赖 GPU 返回值的查询函数可能因 CPU 同步停顿让帧率减半。
GPU 可能是计算机科学中最复杂的状态机，状态切换的大部分开销在 CPU 上的驱动。GPU 与 API 匹配时代价可预测；功耗或面积受限、有硬件 bug 要绕过时，驱动可能付出意外的高代价。例：PowerVR 的混合是可编程的，驱动需要把当前混合状态打补丁进像素着色器。"效果因平台而异"。
Everitt 与 McDonald 给出 2014 年 NVIDIA OpenGL 驱动上从贵到便宜的大致顺序：

状态	每秒约可执行次数
渲染目标 (FBO)	~60k
着色器程序	~300k
混合模式 (ROP)	—
纹理绑定	~1.5M
顶点格式	—
UBO 绑定	—
顶点绑定	—
uniform 更新	~10M

比这些更贵的是在 GPU 渲染模式与计算着色器模式之间切换。

减少状态切换

按状态排序（批处理 batching）：先按着色器分组，再按纹理，依代价顺序往下。
共享数据：把多张纹理放进大图集，最好是纹理数组；支持时用无绑定纹理 (bindless)。着色器切换比更新 uniform 贵，所以同一类材质的变体可用带 if 的单个着色器表示以得到更大批次——但着色器变复杂可能降低 GPU 性能，只能测量判断（参见着色频率与材质系统）。
成组设置：把多个 uniform 放进一个 uniform 缓冲（DirectX 称常量缓冲）一次绑定，省调用时间和逐调用错误检查。
冗余过滤：现代驱动通常把状态设置推迟到第一次绘制，并过滤冗余调用（用脏标记）。所以每次绘制后"恢复默认状态"（Enable(X); Draw(M1); Disable(X); 再 Enable(X); Draw(M2); ...）会浪费大量时间。应用层往往更清楚何时真正需要切换，例如不透明的 replace 到透明的 over 每帧只需一次。Galeano 发现不过滤冗余调用会让他们的 WebGL 应用每帧多花近 2 ms；但驱动已高效过滤时，应用再逐调用检查就是浪费，投入多少取决于驱动。

小批次问题：合并与实例化

每次绘制调用都有与大小无关的固定开销，少量大网格远比大量小网格高效。2003 年 Wloka 测得每批两个三角形时吞吐量比峰值低 375 倍（每秒 0.4M 而非 150M 三角形），场景完全受 CPU/API 限制，GPU 无能为力。其经验法则："每帧只能有 X 个批次"；2003 年拐点约每物体 130 个三角形、建议每帧 300 次绘制，2006 年拐点升到 510 个三角形，2012 年有团队的上限是每帧 16,000 次。DirectX 12、Vulkan、Metal 能把驱动开销降到很低，但 GPU 自身对每个网格也有固定成本。
合并 (consolidation)：把状态相同、彼此相对静止的物体合并成一个网格，一次生成反复使用；同时也减少应用处理的物体数。坑：批次过大会让视锥剔除等算法失效，可借助包围体层次把相邻静态物体分组；合并后物体不可区分，选择拾取时可在每个顶点存物体 ID。
实例化 (instancing)：一次调用多次绘制同一基础模型，另有每实例数据结构（位置、朝向，以及叶子颜色、风吹弯曲等任何着色器可用的属性）。适合茂密丛林、植被（CryEngine 中同色物体一次绘制）和人群（从部件集合挑选身体部位、随机着色和贴花），可与 LOD 结合（远处用替身）。合并实例化 (merge-instancing) 让合并网格中的物体本身也能被实例化。
坑：几何着色器理论上能复制数据做实例化，但实例多时比 API 实例化慢，其本意是局部小规模放大；Mali 等分块渲染器上几何着色器是软件实现。Mali 最佳实践指南原话："Find a better solution to your problem. Geometry shaders are not your solution."

排序键：状态排序与深度排序的折中（18.4.5 节）

按材质分组和按距离从前往后排序通常给出不同顺序，二者冲突。常见灵活方案是为每个物体建一个整数排序键，从高位到低位依次是：

flowchart LR
  A["透明位: 透明物体排在所有不透明物体之后"] --> B["低精度距离: 透明物体取反以从后往前"]
  B --> C["着色器 ID"]
  C --> D["纹理 ID"]

如上图，按整数从小到大排序即可。限制距离位数（甚至只分两三个深度区间）可以让同一距离范围内按着色器分组生效；深度和着色器都相同时再按纹理分组。可增删字段，例如混合状态、z-buffer 读写。也可混合方案：近处按深度、其余按材质。坑：一些移动端分块 GPU 从前往后排序毫无收益，只需优化状态排序。

GEA 的视角：为什么旧 API 的状态切换贵，以及 PSO（卷 II 11.4.8、11.5.2）

全局管线状态

每个管线阶段都有自己的状态（例如顶点着色器用哪个程序、输入输出格式、绑定哪些顶点缓冲；光栅化器的填充模式、剔除模式、是否保守光栅化），合起来叫管线状态。GPU 内部同时跑很多阶段实例，但在 API 的编程模型里只有"一条"管线：一个 draw call 的所有实例共享提交时生效的状态，不同网格需要不同配置就要在 draw call 之间重新设置（卷 II 11.4.8）。
OpenGL 把状态当全局变量；D3D11 用设备上下文对象 ID3D11DeviceContext，但它实际上是单例（立即上下文），状态同样是全局的。API 在底层把这些调用翻译成 CPU 端的命令列表提交给 GPU，GPU 按收到的顺序执行。

状态切换为什么贵

D3D11 中各阶段状态分开设置，例如用 OMSetBlendState 设置混合状态。但在现代 GPU 上多个阶段的状态往往相互依赖，改混合状态可能牵动光栅化器状态，所以 OpenGL 和 D3D11 每改一个阶段都可能被迫做昂贵的全管线重配置（卷 II 11.4.8.4）。
因此有经验的程序员都知道要尽量减少状态切换：把共享同一组材质属性的网格归成批次，每批先配置一次状态，再用一次 draw call 画完。这与本页「减少状态切换」一致。

按材质排序与过度绘制的冲突

按材质排序会增加过度绘制，而 early-z 要求从前往后画。GEA 的解决办法是 z 预通道：第一遍从前往后只写深度，第二遍按材质排序画颜色（卷 II 11.5.2，详见深度缓冲中的 GEA 部分）。本页「排序键」一节用一个排序键折中状态排序和深度排序，是另一种思路。

管线状态对象 (PSO)

D3D12 把完整管线状态封装进 PSO（ID3D12PipelineState），其中既有应用请求的高层配置，也有 GPU 用的设备专用数据。创建 PSO 时解析跨阶段依赖，并把着色器编译成本机 GPU 的机器码；之后用它配置硬件就很快（卷 II 11.4.8.5）。
通常每种状态组合（大致每种材质）建一个 PSO，可以在启动时全部创建，相当于把状态切换的代价预付掉，不必每帧付多次。
代价与折中：PSO 创建可能很慢，玩家会因首次启动太久而不满。办法之一是按 GPU-驱动组合把 PSO 缓存到磁盘，只付一次；但首次启动仍可能很慢，所以许多游戏改为在运行中按需创建 PSO，在"每帧付状态切换代价"和"启动时付全部 PSO 创建代价"之间取得平衡。
- 补充：GEA 没有提到按需创建的副作用。PSO 创建（含驱动编译着色器）通常要几毫秒到上百毫秒，在渲染线程上首次遇到新材质时同步创建就会造成明显的卡顿，即 PC 游戏常见的"着色器编译卡顿"；所以引擎通常在后台线程预缓存（在加载阶段根据将要用到的材质组合提前异步创建），而不是等到绘制时才建，例如 UE5.1 起的 PSO Precaching（Epic "PSO Precaching for Unreal Engine" 文档）。
D3D12、Vulkan、Metal 没有设备上下文，直接暴露命令列表，不再受单线程立即上下文的限制；D3D11 的延迟上下文只是把命令录进内存，必须经立即上下文提交，用来让多个线程并行录制（卷 II 11.4.8.2–11.4.8.3，见多线程渲染与任务系统）。API 层面的更多内容见图形 API 设备、管线状态与资源。