GPU Instancing 底层原理：为什么能减少 Draw Call

理解 Instancing 与 LOD 协同优化的前提，是先理解 GPU Instancing 本身的底层工作原理。

传统渲染流程中，每个对象都需要 CPU 端发起一次 Draw Call。Draw Call 本身不昂贵，但 CPU 端在两次 Draw Call 之间需要做大量工作：设置渲染状态（Shader、材质、纹理）、更新 Uniform Buffer、调用图形 API。即使在现代硬件上，CPU 端的"渲染状态切换"开销也是显著的——单次开销可能在 0.01 毫秒量级，但当场景中有 1 万个对象时，总开销就达到 100 毫秒，完全无法接受。

GPU Instancing 的核心思想是：一次 Draw Call 提交所有同质对象的渲染数据，由 GPU 内部并行绘制。具体实现机制是：CPU 准备一个包含所有对象变换矩阵的缓冲区（Per-Instance Buffer），调用一次 Draw Call 时附带这个缓冲区，GPU 端的顶点着色器接收一个额外的 Instance ID 输入，用这个 ID 从缓冲区读取对应的变换矩阵，对每个顶点进行位移。整个过程中 CPU 端只发起了 1 次 Draw Call，无论场景中有 100 个还是 10000 个对象。

这一机制有几个关键约束，决定了它与 LOD 协同的复杂性：

• 同质性约束：所有被合并的对象必须使用同一个 Mesh 和同一个 Material（材质属性可以不同，但 Shader 必须相同）。
• Per-Instance 限制：变换矩阵、颜色等"实例级属性"通过缓冲区传递，但复杂属性（如光照参数）需要通过 MaterialPropertyBlock 间接传递，有性能开销。
• Shader 支持要求：Shader 必须显式声明 #pragma multi_compile_instancing，Shader Graph 节点需要启用 instancing 属性。

理解这些约束是后续讨论 LOD 与 Instancing 协同问题的关键。LOD 切换意味着"同一对象在不同距离使用不同 Mesh"——这与 Instancing 要求的"同质性"形成直接冲突，需要特殊处理。

LOD 与 Instancing 的根本冲突：何时合并何时拆分

LOD 与 Instancing 的根本冲突点在于：同一类对象在不同距离可能使用不同 LOD 层级的不同 Mesh。如果场景中 1000 棵树，其中 800 棵处于 LOD 0（最近），150 棵处于 LOD 1（中等距离），50 棵处于 LOD 2（远），那么这 1000 棵树实际上跨越了 3 个不同的 Mesh，无法被合并到同一个 Instancing Batch 中。

Unity 的处理方式是：按 LOD 层级分别发起 Instancing Draw Call。也就是说，800 棵 LOD 0 树会合并为 1 次 Draw Call，150 棵 LOD 1 树合并为 1 次，50 棵 LOD 2 树合并为 1 次，总计 3 次 Draw Call。这相比每棵树 1 次 Draw Call 是巨大的优化（1000 次降至 3 次），但相比理想化的 1 次 Draw Call 仍有差距。

这种处理方式带来几个重要的实际影响：

• Draw Call 数量 = 使用的 LOD 层级数 × 同层级的实例批次。如果场景中有 10 种不同类型的对象，每种 3 个 LOD 层级，理论 Draw Call 数为 30。
• 不同 LOD 层级的 Mesh 切换会破坏 GPU 缓存。GPU 内部为 Instancing 维护的批处理缓冲区在 Mesh 切换时需要重建，有一次性开销。
• MaterialPropertyBlock 的使用会显著降低 Instancing 效率。如果同一类对象在材质属性上有差异（如颜色、贴图变化），需要使用 MaterialPropertyBlock，这会大幅降低 Instancing 的可合并性。

优化建议：

1. 尽量使用相同 LOD 层级数。如果不同对象类型使用不同 LOD 层级数，会增加总批次。
2. 避免 MaterialPropertyBlock。如果需要"同 Mesh 不同外观"，考虑使用 Shader 的 per-instance 属性（通过 Instancing API 暴露），而不是 MaterialPropertyBlock。
3. 为 LOD 切换添加 hysteresis（迟滞）。如果对象在两个 LOD 层级边界来回切换，会导致每帧重新计算实例分组，产生性能抖动。

SRP Batcher 登场：另一条优化路径的崛起

2018 年 Unity 推出 Scriptable Render Pipeline（SRP）时，引入了一项革命性的渲染优化机制：SRP Batcher。SRP Batcher 的目标与 Instancing 相同（减少 Draw Call），但实现路径完全不同。

SRP Batcher 的核心思路是：合并 Constant Buffer（CBUFFER）状态，让 GPU 不需要在每次 Draw Call 之间重新设置渲染状态。具体实现是：

• 所有兼容 SRP Batcher 的 Shader 必须将材质属性声明在 UnityPerMaterial CBUFFER 中。
• Unity 在 CPU 端为每个兼容 Shader 维护一个"大缓冲区"，所有使用该 Shader 的对象共享这个缓冲区。
• Draw Call 之间不需要重新上传 Constant Buffer 数据，GPU 端可以直接切换到下一个对象的"虚拟 CBUFFER 槽位"。

SRP Batcher 的优势在于：

• 不要求对象同质：不同 Mesh、不同 LOD 层级都可以被 SRP Batcher 优化。
• 不需要手动启用：满足条件时自动启用。
• 与现代 GPU 架构高度契合：大幅减少 GPU 端的渲染状态切换。

关键限制：

• Shader 必须兼容：必须将材质属性放在 UnityPerMaterial CBUFFER 中，不使用 #pragma multi_compile_instancing 标记。
• 与 GPU Instancing 互斥：一个对象不能同时使用 SRP Batcher 和 GPU Instancing。启用 SRP Batcher 时，Instancing 路径会失效。
• 不适用于自定义 Shader 变体：大量关键字组合（Keyword Combinations）会破坏 SRP Batcher 兼容性。

对 LOD 优化的实际影响：当项目启用 SRP Batcher 时，原本依赖 Instancing 的大规模同质对象（草地、树）会自动切换到 SRP Batcher 路径，Draw Call 数量同样显著下降。这意味着在 URP/HDRP 项目中，开发者不再需要为 Instancing 调试投入大量精力——只要 Shader 兼容性处理好，SRP Batcher 会自动处理大部分优化。

三大管线下 Instancing + LOD 行为差异

Unity 目前维护三套渲染管线（Built-in、URP、HDRP），它们在 Instancing + LOD 协同优化上表现显著不同：

Built-in Render Pipeline

• 默认开启 GPU Instancing（材质勾选 Enable GPU Instancing 即可）。
• 无 SRP Batcher，所有优化依赖 Instancing + Dynamic Batching。
• Instancing 效率高，但需要手动管理大量重复对象的 Instancing 设置。

Universal Render Pipeline (URP)

• SRP Batcher 默认启用，自动为兼容 Shader 优化。
• GPU Instancing 仍然可用，但与 SRP Batcher 互斥——同一对象不能两者都启用。
• Shader Graph 默认不兼容 SRP Batcher（早期版本），需要手动调整 CBUFFER 布局。
• 实际项目建议：先尝试 SRP Batcher 路径，对未兼容对象回退到 Instancing。

High Definition Render Pipeline (HDRP)

• SRP Batcher 深度集成，HDRP 几乎所有内置 Shader 都兼容。
• GPU Instancing 路径支持有限，HDRP 倾向于通过 SRP Batcher + Lit Shader 处理同质对象。
• 大规模同质对象（如草、树）通过 HDRP 自带的 SpeedTree 与 Terrain 系统处理，有专门的优化路径。

实际项目中，最常见的困惑是：我在 URP 项目中勾选了材质的 Enable GPU Instancing，为什么 Profiler 显示 Draw Call 没降？答案是：URP 中 SRP Batcher 默认启用，勾选 Instancing 的对象如果 Shader 兼容 SRP Batcher，会被 SRP Batcher 路径处理（Instancing 失效），Draw Call 的下降来自 SRP Batcher 而非 Instancing。要验证这点，可以在 Profiler 的 Rendering 标签中查看 "SRP Batcher" 行的状态。

BatchRendererGroup：Unity 6 引入的新路径

Unity 6 引入的 BatchRendererGroup (BRG) API 是渲染优化路径的又一次演进。BRG 的目标不是取代 SRP Batcher 或 Instancing，而是为高级开发者提供"更低层级、更细粒度控制"的渲染优化接口。

BRG 的核心机制：

• 开发者直接管理 GPU 缓冲区：包括 Per-Instance 数据（变换矩阵、颜色、自定义属性）、Per-Group 元数据。
• 自定义实例筛选与 LOD 选择逻辑：开发者可以编写自己的代码决定哪些实例应该被渲染、LOD 层级如何分配。
• 绕过 LOD Group 组件：BRG 不依赖 LOD Group，可以实现自定义的 LOD 策略（如基于屏幕占比、基于预算、基于距离的混合策略）。

BRG 的适用场景：

• 大规模同质对象（数万到数十万），需要精细控制每个对象的渲染状态。
• 自定义 LOD 策略，LOD Group 提供的"按距离阈值"模型不够用，需要更复杂的逻辑。
• 性能敏感型项目，愿意投入学习曲线换取更高的优化空间。

BRG 的学习曲线陡峭：

• 需要手动管理 GPU 资源生命周期，包括缓冲区的创建、更新、释放。
• 需要理解 BRG 的内部数据结构（BatchID、BatchBuffer、Metadata 等）。
• 调试工具相对较少，问题排查比 SRP Batcher / Instancing 困难。
• 官方文档和社区案例有限，主要参考 Unity 官方 Sample 与 ECS Entities Graphics 包的实现。

对独立游戏开发者的实际建议：在 2025 年，BRG 是"值得了解但不必立即投入"的技术。中小型项目通过 SRP Batcher + Instancing 就能获得足够的优化空间；只有当项目规模达到"SRP Batcher + Instancing 也无法满足性能"的程度时，再考虑 BRG。

典型场景实战：草地、树木、石块的优化策略

案例一：草地（数千到数万株）

优化路径选择：

• 推荐：SpeedTree 8 草地 + URP 兼容 Shader。SpeedTree 是 Unity 内置的植被渲染系统，深度集成 LOD、Wind Animation、Billboard 远景。配合 URP 自带的 Lit Shader 兼容 SRP Batcher，可以实现上万株草的流畅渲染。
• 备选：GPU Instancing + 手动 LOD 配置。为草创建 2-3 个 LOD 层级（高密度、中密度、Billboard），启用 GPU Instancing 合并 Draw Call。
• 避免：URP Terrain Detail System 渲染大量草。这套系统在草的数量超过几千时性能下降明显，不适合高密度草场。

关键参数：

• 草的 LOD 切换距离：近距离 0-10m 用 LOD 0（高密度），中距离 10-30m 用 LOD 1（中密度），远距离 30m+ 用 Billboard（单四边形）。
• Wind Animation 范围：建议 30m 内的草才启用风动画，更远距离的草静态渲染。

案例二：树木（数百到数千棵）

优化路径选择：

• 推荐：SpeedTree 8 树木。SpeedTree 提供完整的三阶段 LOD 切换（高模 / 简化模 / Billboard），与 Unity URP/HDRP 深度集成。
• 备选：Mesh LOD Group + GPU Instancing。为每棵树手工配置 3 个 LOD 层级，启用 Instancing。适合树木数量较少（数百棵）、每棵树的视觉表现重要的项目。

关键参数：

• Billboard 距离：通常 50m+ 切换为 Billboard。Billboard 是单四边形贴图，渲染开销极低。
• 阴影 LOD：远距离的树应使用简化的阴影（如 Blob Shadow 或单四边形阴影），减少 Shadow Map 的渲染开销。

案例三：石块与装饰物（数千到数万个）

优化路径选择：

• 推荐：GPU Instancing + 1-2 个 LOD 层级。石块通常几何体相对简单，1-2 个 LOD 层级足够。
• 备选：SRP Batcher 自动优化。如果石块使用 SRP Batcher 兼容 Shader，会被自动优化。

关键参数：

• 关闭石块的 Cast Shadow：数千个石块每个都投射阴影会导致 Shadow Map 性能爆炸。保留 5-10% 的"重要石块"投射阴影，其余关闭。
• 使用 Atlas 贴图：将多种石块合并到同一张贴图，可以大幅提升 SRP Batcher 的批处理效率。

决策树：什么场景用哪条路径

面对"用 Instancing 还是 SRP Batcher 还是 BRG"的问题，可以用以下决策树判断：

第一层：项目使用什么管线？

• Built-in 管线→ 默认走 Instancing 路径，需要手动配置。
• URP 管线→ 默认走 SRP Batcher 路径，需要检查 Shader 兼容性。
• HDRP 管线→ 默认走 SRP Batcher 路径 + HDRP 专用优化。

第二层：对象规模？

• 数百到数千→ SRP Batcher / Instancing 都能处理，优先 SRP Batcher。
• 数千到数万→ 需要 SRP Batcher 优化 + 仔细的 Shader 兼容性管理。
• 数万到数十万→ 考虑 BatchRendererGroup 或 ECS Entities Graphics。

第三层：是否需要自定义 LOD 策略？

• 否（按距离阈值即可）→ SRP Batcher / Instancing。
• 是（基于屏幕占比、基于预算等）→ BatchRendererGroup。

第四层：项目周期与团队能力？

• 周期紧 / 团队对 BRG 不熟→ 选择更成熟的 SRP Batcher + Instancing。
• 周期充足 / 团队有学习能力→ 可以尝试 BRG + 自定义 LOD 策略。

初级用户路径：5 分钟启用 Instancing

1. 选择需要优化的对象（草地、树、石头等重复对象）。
2. 在材质 Inspector 中勾选 Enable GPU Instancing。
3. 确保 Shader 支持 Instancing（内置 Shader 都支持，自定义 Shader 需要 #pragma multi_compile_instancing）。
4. 用 Profiler 检查 Draw Call 数量是否下降。

这四步完成，你已经启用了 Instancing 优化。不需要理解所有底层机制。

中级用户路径：构建混合优化架构

对于中等规模项目（数千到数万对象），建议构建以下混合优化架构：

1. 基础层：LOD Group + SRP Batcher。所有对象配置 LOD Group，确保 Shader 兼容 SRP Batcher。预期 Draw Call 降低 50-70%。
2. 补充层：GPU Instancing 处理剩余同质对象。对 SRP Batcher 兼容性不好的对象，启用 Instancing 路径。
3. 监控层：Profiler 持续观察。通过 Profiler 的 Rendering 标签观察 Draw Call、SRP Batcher 状态、SetPass Calls 数量，定位优化瓶颈。
4. 进阶层：针对瓶颈引入 BRG。只有当 SRP Batcher + Instancing 仍无法满足目标帧率时，再考虑 BRG 路径。

这套架构的核心思路是"先简单后复杂，先通用后定制"，避免一开始就投入 BRG 等复杂技术带来的不必要风险。

争议焦点：SRP Batcher 是否将取代 Instancing

社区中持续讨论的一个争议是：随着 SRP Batcher 的成熟，GPU Instancing 是否会被淘汰？

支持 SRP Batcher 取代派的观点：

• SRP Batcher 不要求对象同质，更灵活。
• SRP Batcher 自动启用，开发者负担小。
• SRP Batcher 与现代 GPU 架构契合度更高。

支持 Instancing 长期存续派的观点：

• Instancing 在移动端表现更稳定（部分移动 GPU 对 SRP Batcher 支持有限）。
• Instancing 对自定义 Shader 兼容性更好。
• BRG 等新路径本质上是"自定义 Instancing"，说明 Instancing 思想是基础。

Xmohe 判断：两者的"取代"关系是伪命题。SRP Batcher 和 Instancing 是不同应用场景下的不同工具，SRP Batcher 在 URP/HDRP 通用场景中更优，Instancing 在移动端和特殊自定义场景中仍有不可替代的价值。开发者应该理解两者的差异并根据项目特点选择，而不是押注其中一个会"赢"。

Xmohe 编辑观点：渲染优化没有"银弹"。SRP Batcher、Instancing、BRG 是三个层次的工具：SRP Batcher 是"开箱即用的通用方案"，Instancing 是"灵活可控的传统方案"，BRG 是"为极致性能定制的进阶方案"。正确的决策路径是先 SRP Batcher，再 Instancing，最后 BRG。本文配套的决策树是这条路径的具体化。