★ FEATURED ARTICLE 从URP项目里300个物体把帧率拖到30fps那次说起。我当时打开Profiler一查Draw Call逼近800其中一半开销都花在了重复设置材质属性上。团队里有人喊开GPU Instancing有人喊该用SRP Batcher听起来这俩是一个东西实际用起来却天差地别。这篇文章就把SRP Batcher和GPU Instancing讲透它们分别解决了什么问题、在什么场景下选谁、能不能叠着用以及我踩过的坑。1. 两个优化思路的本质差异CPU瓶颈和GPU瓶颈要分开治很多刚接触Unity渲染优化的同学会把SRP Batcher和GPU Instancing混为一谈因为它们的目标都是减少渲染开销。但它们作用的层次完全不同理解错了直接导致配置无效白费力气。先看渲染一帧的基本流程CPU要把每个物体的变换矩阵、材质参数、Shader属性上传给GPU然后告诉GPU按这个状态画这个网格。如果场景里有300个物体哪怕它们用同一个材质Unity每帧也要提交几百次渲染状态这就是经典的CPU性能瓶颈。SRP Batcher的出发点就是干掉这种重复提交。它把材质属性提前缓存到GPU端的一块持久缓冲区里当多个物体使用同一个Shader变体时CPU只需要在切换物体网格时更新一个很小的索引而不需要重新上传整块材质数据。换句话说它优化的是CPU在设置渲染状态时的开销是CPU侧的减负。GPU Instancing则完全是另一条路。它的目标是把多个相同网格的物体在一次Draw Call里全部打包发送给GPU。这样CPU只需要发起一次绘制命令GPU会通过实例化缓冲区读取每个物体自己的变换矩阵和属性。它优化的是绘制命令的数量是Draw Call层面的合并。如果场景里有500棵完全相同的树用Instancing可以把Draw Call从500降到1。一句话总结SRP Batcher是同一个Shader变体下减少状态切换GPU Instancing是相同网格相同材质合并绘制命令。前者针对CPU的设置开销后者针对GPU的绘制调用。常见的误区是开了一个就觉得另一个没用——实际上在复杂场景里两者经常需要同时打开它们优化的是两个方向的开销。2. SRP Batcher的缓存原理和生效前提2.1 材质属性如何被缓存到GPU端SRP Batcher的核心机制是一个大Buffer。想象你在场景里摆了200个立方体它们全部使用一个标准材质只是个别物体的颜色不同。传统路径下CPU每帧要循环200次每次都把颜色、光滑度、纹理偏移这些参数上传到GPU。SRP Batcher的做法是把这些参数打包进一个持久化的CBUFFER放在GPU显存里。渲染时CPU只更新需要变化的那个物体的属性其他物体直接复用缓冲区里已有的数据。关键点在于这个缓冲区可以跨材质复用只要Shader变体和SRP Batcher兼容。所以哪怕场景里的物体使用了5种不同材质只要它们内核是同一套兼容ShaderSRP Batcher也能把大部分状态设置开销省掉。省掉的开销远不止Draw Call它在Profiler里显示为Batch Count的下降。2.2 兼容Shader和CBUFFER声明SRP Batcher不是默认就能用的。Shader必须按照规范把变化属性放在CBUFFER_START(UnityPerMaterial)和CBUFFER_END之间。这个声明告诉Unity这些属性可以被SRP Batcher锁定到GPU缓存里不要每帧重新上传。标准Shader Graph生成的Shader自动满足这个条件但手写Shader很容易漏掉。漏掉CBUFFER声明会怎样Unity会认为这个Shader不具备SRP Batcher兼容性整个材质打回传统路径CPU开销瞬间回到解放前。这在Profiler里非常明显SRP Batcher的Batch Count不涨但SetPass Call暴涨。排查时先确认Shader是否兼容再看URP Asset里的SRP Batcher开关是否打开两个条件缺一个都不生效。2.3 材质属性频繁更新对缓存的影响SRP Batcher不是万能的它对属性频繁更新的场景很敏感。如果在脚本里用material.SetColor()每帧修改某个物体的颜色这个变化会标记为脏数据导致该物体退出缓存路径重新走一次属性上传。频繁修改的材料多起来之后缓存优势就会被激烈的数据更新抵消甚至比传统路径更慢。我的建议是真正会每帧变化的物体不要依赖SRP Batcher考虑拆分逻辑。比如颜色变化交给Shader本身的Vertex Animation或者材质动画混合来表现避免每帧触发属性上传。或者利用MaterialPropertyBlock来隔离变化MPB的优先级反而更高不影响其他物体的缓存状态。这些细节在后期性能优化时特别值钱。3. GPU Instancing的正确开启方式和条件限制3.1 Instancing的硬性条件GPU Instancing听起来简单——勾一个复选框就完事。但它的前置条件相当严苛几何数据必须一致即所有实例必须使用同一个Mesh材质必须是同一个材质实例Shader必须声明支持Instancing通常是通过实例化缓冲区宏把每个实例的属性颜色、变换矩阵等复制一份。以Unity内置的Standard Shader为例材质面板上的Enable GPU Instancing复选框勾上之后默认Shader就带上了Instancing变体。Shader Graph生成的Shader默认包含实例化宏但要保证所有实例属性都通过UNITY_INSTANCING_BUFFER声明。如果某个属性在Shader里被放置在普通uniform中而不是实例化Buffer中那么该属性无法在实例间不同所有实例读到的会是同一个值。3.2 代码层面的三种实例化方式除了让美术拖物体进场景来自然合批代码里更推荐直接调用实例化接口。最常见的是Graphics.DrawMeshInstanced它把网格和一个实例属性数组一次提交给GPU。这个方法适合预制体数量可控、不会超过单次调用上限通常是1023个实例的情况。超过上限就要换DrawMeshInstancedIndirect它把实例数据放到ComputeBuffer里由GPU侧通过间接参数决定绘制数量。这种方式配合粒子系统、大规模草地生成器是标配。第三种方式是在自研的批量渲染系统里自己管理Matrix数组和嵌套进RenderParams的实例属性。这种方法最灵活可以在同一帧内对成百上千个物体完成Instancing但要求你对整个生命周期有掌控力。做开放世界地表植被时我通常把地形上的草和石头按区块划分每帧只Instancing可见区块的网格。3.3 实例数上限和属性缓冲区的坑DrawMeshInstanced的实例上限在大多数平台是1023这个数字来自常量缓冲区大小限制。超过上限就需要拆分批次或者改用Indirect版本。另一个坑是实例属性缓冲区的大小如果你为每个实例准备了矩阵、颜色、缩放、随机值缓冲区会迅速膨胀。我的经验是尽量压缩实例属性。比如颜色可以用32位打包进一个float4随机值预先烘焙进顶点色避免在运行时为每个实例计算复杂属性。实测下来在移动端用Instancing渲染500个相同的低模箱子Draw Call从500降到1帧耗时从12ms降到5ms。但同一场景改成3000个小草块普通Instancing会因为顶点量太大而卡在顶点处理阶段。Instancing优化的是Draw Call瓶颈不是顶点填充率瓶颈。4. 叠加使用的工程实践先分场景再做取舍4.1 什么时候SRP Batcher什么时候GPU Instancing场景里大量物体是相同Mesh、相同材质优先GPU Instancing——比如树木、石块、颗粒物。场景里大量物体是不同Mesh、相同或相似Shader优先SRP Batcher——比如建筑群、多个道具模型、不同造型但公用材质的预制体。混合场景里比如一个村庄房屋和围栏是不同Mesh但共用一套木质材质墙壁可能是白墙材质茅草屋顶是茅草材质——这种情况下SRP Batcher能把整个村庄的材质状态设置开销压下去而路边的树、地里的草因为Mesh相同走GPU Instancing效率更高。所以我的做法是先用SRP Batcher把基础材质状态开销打底再对成批的同类小物体启用Instancing。两个优化可以共存URP没有强制二选一。但要注意某些情况下两者会争抢资源。例如一个物体的Mesh本身就相同且材质也相同此时Instancing的收益已经覆盖了状态设置开销SRP Batcher的额外干预可能反而造成CPU端的微小损耗这个问题开不开SRP Batcher都无所谓。4.2 静态批处理和动态批处理的取舍除了SRP Batcher和GPU Instancing还有Static Batching和Dynamic Batching这两个传统批处理方案。Static Batching在构建时把多个静态物体的Mesh合并成一个大Mesh大幅减少Draw Call但会增加内存占用和构建时间。Dynamic Batching每帧动态合并小物体主要用于三角形数量很少的物体CPU开销高在移动端不建议大量依赖。在线性应用场景中的取舍是静态物体多且不用移动用Static Batching动态物体数量少且顶点少用Dynamic Batching大量相同动态物体用GPU Instancing大量不同动态物体但Shader兼容用SRP Batcher。这四个可以组合但组合越多排查问题的难度越大。我的建议是先精一个再叠加另一个不要一上来把四个全开。4.3 Culling和LOD的交互叠了一层优化之后不要忘了裁剪和LOD。GPU Instancing可以很大程度缓解Draw Call但它不会自动帮你跳过渲染看不见的物体。所以在大型场景中必须配合Frustum Culling、Occlusion Culling和LOD来减少进入渲染管线的候选物体数量。实践中我会把植被系统做成LOD GroupLOD0用高模网格LOD1和LOD2用简模。每个LOD级别都启用Instancing当摄像机拉远时自动切换。这里有个坑LOD切换本身会打破Instancing批次因为不同LOD是不同Mesh。所以最好把同屏数量最多的LOD级别通常是LOD1作为Instancing主批次LOD0和LOD2单独做保守的批次切割。另外Occlusion Culling在移动端可能因为遮挡数据频繁更新而引入额外开销需要实测。我的经验是静态场景里启用Occlusion Culling收益很大动态场景反而可能帮倒忙。做动态场景时优先用视锥裁剪距离裁剪再叠加SRP Batcher和Instancing效果更稳定。5. 实测中遇到的三个问题排查经历5.1 ModelImporter的网格数据影响第一次做GPU Instancing时我设置好了Shader勾了Enable GPU Instancing但Profiler里Draw Call数纹丝不动。排查半天发现是ModelImporter的Read/Write选项没打开网格数据没有上传到GPU可实例化缓冲区。Unity的导入设置里需要勾选Read/Write Enabled否则实例化属性更新时无法从Mesh数据中读取顶点信息。这个设置对内置管线可能无感但到了SRP和GPU Instancing环境下就暴露了。经验教训启用实例化前先确认Mesh导入设置没有关闭可写权限。5.2 实例化阴影造成的额外Draw Call开启了GPU Instancing的物体如果阴影设置为实时模式阴影渲染也会产生额外的实例化批次。默认情况下Unity会为阴影使用同一个实例化材质但如果材质有特殊性质比如透明或裁剪纹理就可能生成额外的阴影变体导致Draw Call翻倍。我的做法是大片草地和低矮植物直接使用阴影裁剪纹理的模式但要测试阴影距离。阴影距离调远Draw Call会稳步上涨必须在画质和性能间平衡。5.3 SRP Batcher在UI粒子中的误伤还有一次我被SRP Batcher的全局开关坑了。因为SRP Batcher是按Shader变体来锁缓存如果我用了非兼容Shader混在UI或粒子系统里这些对象的渲染会立即退出批处理路径退回传统方式导致SetPass Call飙升。更麻烦的是混合使用兼容和不兼容Shader时SRP Batcher统计里的Batch Count会下降但总耗时不一定下降因为不兼容的Shader会拖慢整体提交节奏。解决办法是要么把所有Shader都改成兼容SRP Batcher的写法要么把非兼容Shader独立成单独的RenderQueue来隔离。实测中我采用后者配合RenderFeature把UI粒子提到单独Pass效果比硬改Shader更省事。6. 如何用Profile分析工具验证两种优化的实际收益6.1 Profiler里的关键指标区分优化的前提是能量化收益。在Unity Profiler的Rendering区域有两个关键字段SetPass Call和Draw Call。SetPass Call表示渲染状态切换的次数Draw Call表示提交给GPU的绘制命令数。开启SRP Batcher后SetPass Call会明显下降而Draw Call可能不变甚至微升因为SRP Batcher需要维护缓存状态。开启GPU Instancing后Draw Call会直接下降一截。所以判断哪个优化生效要看对得上号的指标不能只盯着Draw Call看。很多人开完SRP Batcher后发现Draw Call没降就以为它没用其实是误解。6.2 Frame Debugger验证渲染顺序Frame Debugger可以看到每一帧具体的渲染事件。如果某个物体是以Instanced的方式渲染Frame Debugger的事件名称会出现Draw Mesh [N instances]字样。如果是SRP Batcher帮助合并的状态你会看到一连串相同Shader变体的Draw调用连在一起中间没有SetPass Call。我循环检查Frame Debugger的经验先定位Draw Call数量最大的那一段看它是否被批处理如果没批再看它是否被SRP Batcher缓存命中如果既没批也没缓存优先考虑Shader兼容性和网格导入设置。这套排查顺序几乎帮我把80%的渲染性能问题定位到具体环节。6.3 不同平台的表现差异最后提醒一点SRP Batcher和GPU Instancing在PC、移动端和主机上的表现不是完全一致的。PC的CPU性能强GPU实例化带宽充足两种优化收益都明显。移动端的CPU较弱SRP Batcher对CPU减负的效果更突出但移动端的GPU并行能力有限Instancing的收益可能不如PC明显而且实例数超过几百之后顶点填充率会优先受限。我在移动端做过对比150个相同物体Instancing开启后Draw Call从150降到1但帧耗时只下降了20%因为GPU端计算量没变。真正把时间拉下来的是同时启用SRP Batcher把CPU端的状态设置从每物体一次降到全局一次。所以移动端的优化策略一定要两条腿走路不能迷信单一大招。7. 进阶思路从工具性优化到架构级优化如果只把SRP Batcher和GPU Instancing当作勾选框那发挥的空间很有限。渲染优化的尽头是架构设计。比如做开放世界时我会在场景初始化阶段把物体按可实例化类型分区管理每个分区只存储网格引用、矩阵数组和材质索引。渲染时直接把这些数据扔给DrawMeshInstanced或SRP Batcher的兼容材质通道而不是逐个遍历Transform去获取矩阵这种级别的小优化可以叠加出明显收益。另一个思路是把动态物体和静态物体分开静态物体预烘焙好变换走SRP Batcher的缓存路径动态物体则每帧更新矩阵但尽量打包成实例化批次。这要求美术和程序对动态和静态有明确的约定不能等到合批阶段才处理。比如一个可破坏的墙墙块在未破坏前是静态的破坏后变成动态碎片架构上就要提前设计好它的状态切换逻辑否则每次切换都会打碎批处理引入不可控的Draw Call尖峰。这几个月下来我最大的体会是SRP Batcher和GPU Instancing不是两个需要纠结的选择题而是渲染优化工具箱里的两个常规器械。不同场景、不同瓶颈、不同平台选不同组合效果才会最好。与其迷信某个开关不如花时间把Profiler读明白把Shader的兼容性摸清楚把网格导入设置和LOD策略理顺。这些东西拉通之后不管项目是PC还是移动端都能找到一条踏实的优化路径。
阅读完成 · 觉得有帮助？
