1. 项目概述为什么我们需要SRP Batcher如果你在Unity3D里做过稍微复杂点的3D项目尤其是移动端或者需要大量同屏物体的项目肯定对“Draw Call”这个词又爱又恨。爱的是它直接关系到渲染性能恨的是优化它往往意味着各种折腾比如手动合并网格、使用静态/动态合批或者上GPU Instancing。但今天要聊的SRP Batcher是Unity在引入可编程渲染管线SRP后提供的一种全新的、更底层的优化手段。它不减少Draw Call的数量却能大幅降低每个Draw Call的CPU准备开销。简单来说它让CPU对GPU说“干活”的效率变得更高了。我第一次在URP项目里打开Frame Debugger看到“SRP Batch”这个条目时也是一头雾水。传统的“Batch”通常意味着合批即多个物体合并成一个Draw Call。但SRP Batcher的“Batch”指的是一系列绑定和绘制命令的序列它优化的是命令提交的流程。这对于大量使用不同材质但共享同一着色器变体的场景比如成千上万个外观各异但使用同款标准着色器的角色或道具来说性能提升是颠覆性的。理解它的原理不仅能帮你更好地使用URP/HDRP更能让你在编写自定义SRP时设计出更高效的渲染架构。2. SRP Batcher核心原理持久化的GPU数据与高速通道要理解SRP Batcher我们必须先抛开“合批减少Draw Call”的传统观念。它的核心思想是数据持久化和命令流优化。2.1 传统渲染流程的瓶颈在传统渲染管线包括内置管线中CPU在提交一个Draw Call前需要做大量准备工作设置渲染状态绑定顶点缓冲区、索引缓冲区、纹理、采样器状态等。更新常量缓冲区将当前物体的变换矩阵unity_ObjectToWorld等、以及当前材质的所有属性颜色、纹理偏移、浮点参数等从CPU内存复制到GPU的常量缓冲区。问题在于每次绘制一个使用不同材质的物体即使它们用的是同一个着色器CPU也需要重新绑定该材质的所有数据到GPU。这个过程涉及内存拷贝和GPU API调用开销不小。当场景中有成千上万个材质实例时CPU大部分时间都花在了这种重复的“设置-提交”循环上。2.2 SRP Batcher的解决之道SRP Batcher改变了这个游戏规则。它建立了一个持久的GPU内存区域来存储材质数据。其工作流程可以拆解为以下几个关键步骤第一步材质数据的GPU常驻当一个材质第一次被渲染时SRP Batcher会将该材质的所有属性定义在UnityPerMaterialCBuffer中的变量上传到GPU上一块固定的、持久化的内存区域中。此后只要这个材质的属性不发生变化这些数据就一直驻留在GPU上不再需要每帧从CPU重新上传。注意这里的“材质属性不变”指的是通过Material组件设置的SetFloat、SetColor等属性值没有改变。如果你动态修改了材质属性SRP Batcher仍然需要更新GPU上对应的数据块但这通常比传统流程的完整重新绑定要高效。第二步引擎数据的快速流式更新对于每个物体每帧都必然变化的“引擎属性”如模型矩阵unity_ObjectToWorld、法线矩阵、光照探针数据等定义在UnityPerDrawCBuffer中SRP Batcher开辟了一个大型的、循环使用的GPU常量缓冲区。CPU每帧的工作就是快速地将所有需要渲染的物体的这些引擎数据以紧密打包Packed的方式流式地更新到这个大缓冲区里。你可以把这个大缓冲区想象成一个“传送带”。CPU是搬运工不停地把每个物体的位置、旋转信息引擎数据放到传送带上。GPU则从传送带上按顺序读取数据来绘制物体。而材质数据比如颜色、金属度就像每个物体自带的“工具包”早就放在GPU的仓库里了GPU需要时直接根据索引去取不需要CPU每次重新搬运。第三步高效的命令提交在绘制时CPU不再需要为每个物体单独绑定其材质常量缓冲区。它只需要告诉GPU“绘制第N个物体使用仓库里第M个材质数据包引擎数据在传送带的第K个位置”。这个指令非常轻量。多个使用相同着色器变体的物体它们的绘制指令可以被组织成一个连续的“SRP Batch”提交。虽然每个物体可能仍然对应一个独立的Draw Call但提交这些Draw Call的CPU开销被降到了最低。关键区别总结传统方式[绑定材质数据 - 绑定引擎数据 - 绘制]为一个原子操作每个材质实例重复此操作。SRP Batcher方式初始化材质数据上传至GPU并持久化。每帧引擎数据流式更新至大缓冲区。绘制提交轻量级绘制指令引用持久化的材质数据和流式的引擎数据。这种架构使得渲染性能的瓶颈从“材质数量”很大程度上转移到了“着色器变体数量”。只要物体使用相同的着色器变体即使有成百上千个不同的材质实例SRP Batcher也能高效处理。3. 实现兼容性让你的Shader和Renderer“入伙”要让SRP Batcher为你的物体工作必须满足两个层面的兼容性着色器兼容和渲染器兼容。缺一不可。3.1 着色器兼容性规则这是最核心的规则。SRP Batcher要求着色器以特定的方式声明常量缓冲区以便它能正确地区分和管理“引擎数据”和“材质数据”。强制性规则所有引擎内置属性必须声明在名为UnityPerDraw的单个常量缓冲区中。这些属性通常是Unity内置的例如CBUFFER_START(UnityPerDraw) float4x4 unity_ObjectToWorld; float4x4 unity_WorldToObject; float4 unity_LODFade; real4 unity_WorldTransformParams; // ... 以及光照探针、Lightmap数据等相关变量 CBUFFER_END在编写自定义Shader时最简单的方法是直接包含UnityInput.hlsl头文件它已经帮你正确定义好了这个缓冲区。所有材质属性必须声明在名为UnityPerMaterial的单个常量缓冲区中。你在Properties块中定义的属性以及在SubShader中使用的相关变量都必须放在这个缓冲区里。// 在Properties中定义 _MainTex (Texture, 2D) white {} _Color (Color, Color) (1,1,1,1) _Glossiness (Smoothness, Range(0,1)) 0.5 // 在HLSLPROGRAM中声明和关联 CBUFFER_START(UnityPerMaterial) float4 _MainTex_ST; // 注意纹理的缩放偏移也属于材质属性 float4 _Color; float _Glossiness; CBUFFER_END SAMPLER(sampler_MainTex); TEXTURE2D(_MainTex);一个极易踩坑的点纹理的缩放偏移变量_MainTex_ST也必须放在UnityPerMaterial中即使你没有在Properties里显式定义它。Unity会自动生成这个变量你必须手动将其纳入常量缓冲区。如何检查兼容性在Unity编辑器中点击你的Shader文件在Inspector面板的顶部你可以直接看到“SRP Batcher”的兼容状态。兼容显示“兼容”。不兼容会显示具体原因例如“Found property ‘_MyProperty’ in block ‘UnityPerMaterial’ which is not actually in the CBUFFER”。这通常意味着你漏掉了某个属性。对于Shader Graph用户URP/HDRP内置的Lit/Unlit Shader Graph节点生成的着色器默认是兼容的。但如果你使用了自定义HLSL节点并在其中引用了新的材质属性你必须确保这些属性通过Blackboard添加到Shader Graph中这样它们才会被自动归入正确的CBuffer。3.2 渲染器兼容性规则即使着色器兼容了使用该着色器的物体GameObject也必须满足以下条件才能走SRP Batcher的渲染路径物体必须包含网格或蒙皮网格渲染器。粒子系统渲染器Particle System Renderer目前不兼容SRP Batcher。物体不能使用MaterialPropertyBlock。这是最重要的限制之一。为什么MaterialPropertyBlockMPB会破坏兼容性MPB允许你在运行时为每个渲染器实例覆盖材质属性这是一种非常灵活的每实例数据传递方式。然而SRP Batcher的核心是材质数据的持久化。如果允许通过MPB动态覆盖就意味着材质数据不再是“持久不变”的破坏了SRP Batcher的根基。因此任何附加了MPB的渲染器都会被强制降级到传统的渲染路径。实操心得 在项目初期就要决定数据传递策略。如果物体需要大量每实例数据如不同的颜色、血量显示等你有几个选择策略A推荐如果实例数量巨大且数据规律考虑使用GPU Instancing。但注意GPU Instancing和SRP Batcher是互斥的你需要为材质启用Instancing并确保着色器支持这会将物体踢出SRP Batcher路径。策略B如果实例不多可以创建多个材质实例Material Instances。虽然这会增加材质数量但只要它们使用同一着色器变体SRP Batcher依然能高效处理。这比使用MPB要友好得多。策略C将每实例数据编码到顶点颜色、UV通道或自定义顶点流中。这需要修改网格数据适合美术流程固定的情况。4. 启用、验证与性能分析理解了原理和规则接下来就是在项目中实际应用和验证SRP Batcher。4.1 在URP/HDRP中启用URP SRP Batcher在URP中默认是关闭的需要手动开启。在Project窗口中找到你的URP Asset文件通常名为UniversalRP-HighQuality等。在Inspector面板中找到Advanced设置区域。勾选SRP Batcher选项。提示如果看不到这个选项点击任意设置区域右上角的垂直省略号⋮图标选择“Show Additional Properties”或“Show All Additional Properties”。HDRP 在HDRP中SRP Batcher默认是开启的通常不建议关闭。你可以在HDRP Asset的Debug模式下找到该选项进行查看或临时禁用用于性能对比测试。运行时控制 你也可以通过代码在运行时全局开关SRP Batcher这在某些调试场景下有用using UnityEngine.Rendering; // 启用 SRP Batcher GraphicsSettings.useScriptableRenderPipelineBatching true; // 禁用 SRP Batcher GraphicsSettings.useScriptableRenderPipelineBatching false;4.2 使用Frame Debugger进行验证Frame Debugger是分析SRP Batcher行为最直观的工具。通过它你可以清楚地看到哪些物体被合入了SRP Batch哪些没有以及原因是什么。操作步骤打开Window Analysis Frame Debugger。点击Enable开始捕获一帧的渲染数据。在左侧的渲染事件列表中展开RenderLoopNewBatcher.Draw在URP中通常位于“Render Opaques”或“Render Transparents”事件下。你会看到一系列名为“SRP Batch”的条目。解读Frame Debugger信息点击一个“SRP Batch”右侧面板会显示详细信息Draw Calls这个Batch中包含的绘制调用数量。理想情况下一个Batch应包含大量Draw Calls。Shader该Batch使用的着色器。Keywords该Batch启用的着色器关键字。这是关键不同的关键字组合会产生不同的着色器变体。Reason解释为什么从这里开始了一个新的Batch。常见原因有Nodes have different shaders物体使用了不同的着色器。Nodes have different shader keywords物体虽然使用同一着色器但启用了不同的关键字如_NORMALMAPON/OFF导致实际变体不同。Nodes have different render states物体的渲染状态不同例如一个开启了深度写入另一个关闭了。Renderer is not compatible渲染器不兼容如使用了MaterialPropertyBlock。性能分析要点 如果你的场景中出现了大量只包含寥寥几个Draw Calls的SRP Batch这通常是一个警告信号说明你的着色器变体管理可能有问题。例如如果你为同一个着色器定义了10个功能开关Keyword理论上在最坏情况下会产生2^101024种变体组合这可能导致物体因为微小的功能差异而被拆分成大量的小Batch完全抵消了SRP Batcher的优势。4.3 性能对比SRP Batcher vs GPU Instancing这是一个常见的抉择。两者都是优化渲染性能的利器但适用场景不同。特性SRP BatcherGPU Instancing核心优化对象CPU端渲染状态设置与数据提交开销GPU端的顶点处理与重复绘制开销数据要求材质属性可以不同但必须使用相同着色器变体网格、材质所有属性必须完全相同兼容性冲突与MaterialPropertyBlock、粒子渲染器不兼容与SRP Batcher不兼容需手动关闭其一最佳适用场景大量物体外观各异不同材质实例但使用同一套着色逻辑如URP Lit。大量完全相同的物体如草地、树木、子弹、同一型号的士兵。性能瓶颈着色器变体数量过多导致Batch拆分。单个实例数据量过大或实例数量超过GPU单次绘制上限。如何选择场景中主要是大量完全相同的物体如森林、人群优先使用GPU Instancing。你需要为材质勾选“Enable GPU Instancing”并确保着色器支持。场景中主要是大量外观不同但着色逻辑相同的物体如角色穿着不同装备、场景中有各种颜色的道具SRP Batcher是更好的选择。如果场景混合了以上两种情况你需要进行性能剖析。使用Unity Profiler的Rendering区域对比开启/关闭SRP Batcher、启用/禁用Instancing时的CPU渲染线程耗时和GPU耗时根据实际情况做出权衡。有时为了支持Instancing而让大量物体退出SRP Batcher可能得不偿失。5. 高级技巧与疑难排查在实际项目中要最大化SRP Batcher的收益需要一些策略和排错技巧。5.1 管理着色器变体数量这是影响SRP Batcher效率的头号因素。每个不同的着色器变体都会导致一个新的SRP Batch。策略1精简着色器功能在项目初期与美术和技术美术紧密合作规划好材质系统。避免创建功能大而全的“万能着色器”。可以考虑按渲染类型拆分一个用于标准不透明物体主纹理法线金属度/光滑度。一个用于透明物体。一个用于简单特效无光照、顶点动画。 每个着色器只包含必要的功能开关。策略2使用Shader变体集合Shader Variant Collection虽然SRP Batcher希望变体少但项目难免需要一些变体。为了减少运行时因变体缺失导致的编译卡顿并让Frame Debugger的分析更清晰应该积极使用Shader Variant Collection来预编译和收集常用的变体组合。策略3利用材质属性覆盖而非关键字对于一些非此即彼的开关功能如果可以用材质属性如Float配合Shader中的if或step函数实现就尽量不要使用Shader Keyword。因为属性变化不会产生新变体而Keyword会。当然这需要在性能分支开销和变体数量之间权衡。5.2 处理不兼容的第三方资源或遗留代码你可能会遇到一些第三方模型或旧代码它们使用了MaterialPropertyBlock导致无法合批。解决方案A重构数据传递方式如果MPB只是用来传递一些简单的每实例颜色或浮点数考虑将其“烘焙”到顶点颜色中或者通过创建多个材质实例来替代。解决方案B局部牺牲全局受益如果某个特定系统如特效系统、高亮系统必须使用MPB且影响的物体数量有限可以接受这些物体不走SRP Batcher。确保项目的主体部分如场景静态物件、主要角色是兼容的即可。可以使用Layer来区分这些物体并在渲染时做到心中有数。5.3 自定义SRP中的实现要点如果你在编写自己的Scriptable Render Pipeline想要支持SRP Batcher你需要做两件事在C#端启用在你的RenderPipeline实例中确保GraphicsSettings.useScriptableRenderPipelineBatching为true。在渲染循环中调用正确的APISRP Batcher的底层管理是Unity引擎自动处理的。你只需要像往常一样调用CommandBuffer.DrawRenderer或context.DrawRenderers。兼容的渲染器会自动走SRP Batcher路径。你的主要工作是设计好排序和渲染队列逻辑让使用相同着色器的物体尽量连续地被渲染。5.4 常见问题排查清单当你发现SRP Batcher没有生效或者性能提升不显著时可以按照以下清单排查检查全局开关确认URP/HDRP Asset中的SRP Batcher已启用且代码中没有将其关闭。检查着色器兼容性在Inspector中逐一检查项目中使用的主要着色器确认显示“SRP Batcher: Compatible”。使用Frame Debugger这是最重要的工具。查看SRP Batch被拆分的原因Reason。如果是“different shader keywords”检查材质的关键字使用合并或减少不必要的变体。如果是“Renderer is not compatible”检查该物体是否附加了MaterialPropertyBlock或者是否是粒子系统。检查渲染顺序不透明的物体通常按从近到远深度排序这可能会打断基于着色器的合批。可以尝试调整摄像机或修改渲染队列但要注意这可能影响过度绘制。对于大量使用相同着色器的物体深度排序对合批的打断有时是可以接受的性能权衡。剖析性能使用Profiler对比开启和关闭SRP Batcher时RenderLoop.NewBatcher.Draw阶段的CPU时间。如果差距不大可能说明你的场景中不兼容的物体太多或者Batch被拆分得太碎需要回到第3步进行优化。我个人在优化一个中型URP项目时的体会是SRP Batcher带来的最大收益往往不是在项目初期而是在内容大量填充的中后期。当场景中塞满了成千上万个由美术制作的、使用各种不同材质实例的资产时开启SRP Batcher能让渲染CPU时间保持在一个非常稳定的水平而不会随着材质数量的增加而线性增长。这种可预测的性能表现对于确保复杂场景的流畅度至关重要。它更像是一个为项目规模保驾护航的底层基础设施理解了它的原理你就能更好地规划你的材质和着色器架构从根源上规避性能问题。