srp batcher
In 2018, we’ve introduced a highly customizable rendering technology we call Scriptable Render Pipeline (SRP). A part of this is a new low-level engine rendering loop called SRP Batcher that can speed up your CPU during rendering by 1.2x to 4x, depending on the Scene. Let’s see how to use this feature at its best!
在2018年，我们引入了一种高度可定制的渲染技术，称为Scriptable Render Pipeline(SRP) 。 其中一部分是一个称为SRP Batcher的新的低级引擎渲染循环，它可以在渲染期间将CPU的速度提高1.2倍至4倍，具体取决于场景。 让我们来看看如何最好地使用此功能！
NOTE: when we talk about x4 speedup, we’re talking about the CPU rendering code (the “RenderLoop.Draw” and “ShadowLoop.Draw” profiler markers). We’re not talking about global framerate (FPS)).
注意：当我们谈论x4加速时，我们在谈论CPU渲染代码(“ RenderLoop.Draw”和“ ShadowLoop.Draw”事件探查器标记)。 我们不是在谈论全球帧率(FPS)。
团结与材料 (Unity and Materials)
The Unity editor has a really flexible rendering engine. You can modify any Material property at any time during a frame. Plus, Unity historically was made for non-constant buffers, supporting Graphics APIs such as DirectX9. However, such nice features have some drawbacks. For example, there is a lot of work to do when a DrawCall is using a new Material. So basically, the more Materials you have in a Scene, the more CPU will be required to setup GPU data.
Unity编辑器具有非常灵活的渲染引擎。 您可以在框架期间随时修改任何Material属性。 另外，从历史上看，Unity是用于非恒定缓冲区的，支持DirectX9等图形API。 但是，这样好的功能有一些缺点。 例如，当DrawCall使用新材质时，有很多工作要做。 因此，基本上，场景中使用的材质越多，则需要更多的CPU来设置GPU数据。
Standard Unity rendering workflow
标准Unity渲染工作流程
During the inner render loop, when a new Material is detected, the CPU collects all properties and sets up different constant buffers in the GPU memory. The number of GPU buffers depends on how the Shader declares its CBUFFERs.
在内部渲染循环中，当检测到新材质时，CPU会收集所有属性并在GPU内存中设置不同的常量缓冲区。 GPU缓冲区的数量取决于Shader如何声明其CBUFFER。
SRP Batcher如何工作 (How SRP Batcher works)
When we made the SRP technology, we had to rewrite some low-level engine parts. We saw a great opportunity to natively integrate some new paradigms, such as GPU data persistence. We aimed to speed up the general case where a Scene uses a lot of different Materials, but very few Shader variants.
当我们采用SRP技术时，我们不得不重写一些底层引擎部件。 我们看到了一个很好的机会，可以原生地集成一些新的范例，例如GPU数据持久性。 我们旨在加快场景使用大量不同材质但着色器变体很少的一般情况。
Now, low-level render loops can make material data persistent in the GPU memory. If the Material content does not change, there is no need to set up and upload the buffer to the GPU. Plus, we use a dedicated code path to quickly update Built-in engine properties in a large GPU buffer. Now the new flow chart looks like:
现在，低级渲染循环可以使材质数据持久保存在GPU内存中。 如果Material内容不变，则无需设置缓冲区并将其上传到GPU。 另外，我们使用专用的代码路径来快速更新大型GPU缓冲区中的内置引擎属性。 现在，新流程图如下所示：
SRP Batcher rendering workflow.
SRP Batcher渲染工作流程。
Here, the CPU is only handling the built-in engine properties, labeled object matrix transform. All Materials have persistent CBUFFERs located in the GPU memory, which are ready to use. To sum up, the speedup comes from two different things:
在这里，CPU仅处理标记为对象矩阵转换的内置引擎属性。 所有材料在GPU内存中都有持久的CBUFFER，可以随时使用。 综上所述，加速来自两个不同的方面：
- Each material content is now persistent in GPU memory 每种材料内容现在都可以持久保存在GPU内存中
- A dedicated code is managing a large “per object” GPU CBUFFER 专用代码正在管理大型“每个对象” GPU CBUFFER
如何启用SRP Batcher (How to enable SRP Batcher)
Your project must be using either the Lightweight Render Pipeline (LWRP), the High Definition Render Pipeline (HDRP), or your own custom SRP. To activate the SRP Batcher in HDRP or LWRP, just use the checkbox in the SRP Asset Inspector.
您的项目必须使用轻量级渲染管道(LWRP)，高清晰度渲染管道(HDRP)或您自己的自定义SRP。 要在HDRP或LWRP中**SRP批处理程序，只需使用SRP资产检查器中的复选框即可。
If you want to enable/disable SRP Batcher at runtime, to benchmark performance benefits, you can also toggle this global variable using C# code:
如果要在运行时启用/禁用SRP Batcher，以基准测试性能优势，还可以使用C＃代码切换此全局变量：
|
1
|
GraphicsSettings.useScriptableRenderPipelineBatching = true;
|
|
1
|
GraphicsSettings . useScriptableRenderPipelineBatching = true ;
|
SRP Batcher兼容性 (SRP Batcher compatibility)
For an object to be rendered through the SRP Batcher code path, there are two requirements:
对于要通过SRP Batcher代码路径呈现的对象，有两个要求：
- The object must be in a mesh. It cannot be a particle or a skinned mesh. 该对象必须在网格中。 它不能是粒子或蒙皮的网格。
- You must use a Shader that is compatible with the SRP Batcher. All Lit and Unlit Shaders in HDRP and LWRP fit this requirement. 您必须使用与SRP Batcher兼容的着色器。 HDRP和LWRP中的所有亮和不亮着色器均符合此要求。
For a Shader to be compatible with SRP:
若要使着色器与SRP兼容：
- All built-in engine properties must be declared in a single CBUFFER named “UnityPerDraw”. For example, unity_ObjectToWorld, or unity_SHAr. 所有内置引擎属性必须在一个名为“ UnityPerDraw”的CBUFFER中声明。 例如，unity_ObjectToWorld或unity_SHAr。
- All Material properties must be declared in a single CBUFFER named “UnityPerMaterial”. 所有材料属性必须在一个名为“ UnityPerMaterial”的CBUFFER中声明。
You can see the compatibility status of a Shader in the Inspector panel. This compatibility section is only displayed if your Project is SRP based.
您可以在“检查器”面板中查看着色器的兼容性状态。 仅当您的项目基于SRP时，才显示此兼容性部分。
In any given Scene, some objects are SRP Batcher compatible, some are not. But the Scene is still rendered properly. Compatible objects will use SRP Batcher code path, and others still use the standard SRP code path.
在任何给定场景中，有些对象与SRP Batcher兼容，有些则不兼容。 但是场景仍然可以正确渲染。 兼容的对象将使用SRP Batcher代码路径，而其他对象仍将使用标准SRP代码路径。
剖析的艺术 (The Art of profiling)
SRPBatcherProfiler.cs (SRPBatcherProfiler.cs)
If you want to measure the speed increase with SRP Batcher in your specific Scene, you could use the SRPBatcherProfiler.cs C# script. Just add the script in your Scene. When this script is running, you can toggle the overlay display using F8 key. You can also turn SRP Batcher ON and OFF during play using F9 key. If you enable the overlay in PLAY mode (F8) you should see a lot of useful information:
如果要在特定场景中使用SRP Batcher来测量速度增加，则可以使用SRPBatcherProfiler.cs C＃脚本。 只需将脚本添加到场景中即可。 运行此脚本时，可以使用F8键切换覆盖显示。 您也可以在播放过程中使用F9键打开和关闭SRP Batcher。 如果在“播放”模式(F8)中启用了覆盖，您应该会看到很多有用的信息：
Here, all time is measured in milliseconds (ms). Those time measurements show the CPU spent in Unity SRP rendering loops.
在这里，所有时间均以毫秒(ms)为单位。 这些时间测量结果显示了在Unity SRP渲染循环中花费的CPU。
NOTE: timing means cumulated time of all “RenderLoop.Draw” and “Shadows.Draw” markers called during a frame, whatever the thread owner. When you see “1.31ms SRP Batcher code path”, maybe 0.31ms is spent on main thread, and 1ms is spread over all of the graphic jobs.
注意：计时表示 在帧期间调用 的所有“ RenderLoop.Draw”和“ Shadows .Draw ”标记的累计时间 ，无论线程所有者如何。 当您看到“ 1.31ms SRP Batcher代码路径”时，可能在主线程 上花费了0.31ms ，而 在所有图形作业 上花费了 1ms 。
叠加信息 (Overlay information)
In this table, you can see a description of each setting in the Overlay visible in PLAY mode, from top to bottom:
在此表中，您可以从上到下查看在“播放”模式下可见的“叠加”中每个设置的说明：
NOTE: We hesitate to add FPS at the bottom of the overlay because you should be very careful about FPS metrics when optimizing. First, FPS is not linear, so seeing FPS increase by 20% didn’t tell you immediately how much you optimized your scene. Second, FPS is global over the frame. FPS (or global frame timing) depends on many other things than rendering, like C# gameplay, Physics, Culling, etc.
注意：我们会犹豫是否要在叠加层的底部添加FPS，因为在优化时您应非常注意FPS指标。 首先，FPS不是线性的，因此看到FPS增加20％并不能立即告诉您优化场景的程度。 其次，FPS在整个框架内都是全球性的。 FPS(或全局帧定时)取决于渲染以外的许多其他因素，例如C＃游戏玩法，物理，剔除等。
You can get SRPBatcherProfiler.cs from a SRP Batcher project template on GitHub.
您可以从GitHub上的SRP Batcher项目模板获取SRPBatcherProfiler.cs。
各种场景基准 (Various scenes benchmark)
Here are some Unity scenes shots with SRP Batcher OFF and ON to see the speed up in various situations.
这是一些在SRP Batcher处于OFF和ON状态的Unity场景拍摄，以查看在各种情况下的加速情况。
Book of the Dead, HDRP, PlayStation 4. x1.47 speed up. Please note that FPS doesn’t change, because this scene is GPU bound. You get 12ms left to do other things on the CPU side. Speed up is almost the same on PC.
Book of the Dead ，HDRP，PlayStation4。x1.47加快了速度。 请注意，FPS不会更改，因为此场景受GPU约束。 您还有12ms的时间可以在CPU端执行其他操作。 速度在PC上几乎相同。
FPS Sample, HDRP, PC DirectX 11. X1.23 speed up. Please note there is still 1.67ms going to the standard code path because of SRP Batcher incompatibility. In this case, skinned meshes and a few particles rendered using Material Property Blocks.
FPS示例 ，HDRP，PC DirectX11。X1.23加快了速度。 请注意，由于SRP Batcher不兼容，到标准代码路径还有1.67毫秒。 在这种情况下，使用材质属性块渲染蒙皮的网格和一些粒子。
Boat Attack, LWRP, PlayStation 4. Speed up x2.13.
划船攻击 ，LWRP，PlayStation4。加速x2.13。
支持平台 (Supported Platforms)
SRP Batcher is working on almost all platforms. Here is a table showing platform and minimal Unity version required. Unity 2019.2 is currently in open alpha.
SRP Batcher在几乎所有平台上都可以使用。 下表显示了所需的平台和最低Unity版本。 Unity 2019.2当前处于公开alpha状态 。
关于VR的一些话 (Some words about VR)
SRP Batcher fast code path is supported in VR, only with “SinglePassInstanced” mode. Enabling VR won’t add any CPU time ( thanks to SinglePassInstanced mode )
VR仅在“ SinglePassInstanced”模式下支持SRP Batcher快速代码路径。 启用VR不会增加任何CPU时间(感谢SinglePassInstanced模式)
常见问题 (Common questions)
How do I know I’m using SRP Batcher the best way possible?
我怎么知道我以最佳方式使用SRP Batcher？
Use SRPBatcherProfiler.cs, and first check that SRP Batcher is ON. Then, look at “Standard code path” timing. This should be close to 0, and all timing should be spent in “SRP Batcher code path”. Sometimes, it’s normal that some time is spent in the standard code path if your scene is using a few skinned meshes or particles. Check out our SRP Batcher Benchmark project on GitHub.
使用SRPBatcherProfiler.cs，然后首先检查SRP Batcher是否已打开。 然后，查看“标准代码路径”时序。 该值应接近于0，并且所有时序都应在“ SRP Batcher代码路径”中使用。 有时，如果您的场景使用了一些蒙皮的网格物体或粒子，则在标准代码路径中花费一些时间是正常的。 在GitHub上 查看我们的 SRP Batcher Benchmark项目 。
SRPBatcherProfiler shows similar timing regardless of SRP Batcher is ON or OFF. Why?
不管SRP Batcher处于ON还是OFF状态，SRPBatcherProfiler都会显示类似的时序。 为什么？
First, you should check that almost all rendering time goes through the new code path (see above). If it does, and the numbers are still similar, then look at the “flush” number. This “flush” number should decrease a lot when the SRP Batcher is ON. As a rule of thumb, divided by 10 is really nice, by 2 is almost good. If the flush count does not decrease a lot, it means you still have a lot of Shader variants. Try to reduce the number of Shader variants. If you did a lot of different Shaders, try to make a “uber” one with more parameters. Having tons of different material parameters is then free.
首先，您应该检查几乎所有渲染时间都经过新的代码路径(请参见上文)。 如果是这样，并且数字仍然相似，则查看“冲洗”数字。 当SRP Batcher打开时，该“冲洗”编号应减少很多。 根据经验，除以10确实是很好，除以2几乎是好的。 如果刷新计数没有减少很多，则意味着您仍然有很多Shader变体。 尝试减少Shader变体的数量。 如果您做了很多不同的着色器，请尝试使用更多参数制作一个“超级”着色器。 这样就无需再拥有大量不同的材料参数。
Global FPS didn’t change when I enabled the SRP Batcher. Why?
启用SRP批处理程序时，全局FPS不变。 为什么？
Check the two questions above. If SRPBatcherProfiler shows that “CPU Rendering time” is twice as fast, and the FPS did not change, then the CPU rendering part is not your bottleneck. It does not mean you’re not CPU bound – instead, maybe you’re using too much C# gameplay or too many physics elements. Anyway, if “CPU Rendering time” is twice as fast, it’s still positive. You probably noticed on the top video that even with 3.5x speedup, the scene is still at 60FPS. That’s because we have VSYNC turned ON. SRP Batcher really saved 6.8ms on the CPU side. Those milliseconds could be used for another task. It can also just save some battery life on mobile.
检查上面的两个问题。 如果SRPBatcherProfiler显示“ CPU渲染时间”快两倍，并且FPS不变，则CPU渲染部分不是您的瓶颈。 这并不意味着您不受CPU的束缚，而是可能使用了太多的C＃游戏玩法或太多的物理元素。 无论如何，如果“ CPU渲染时间”快一倍，那还是不错的。 您可能已经在顶部视频中注意到，即使以3.5倍的加速速度，场景仍然保持60FPS的速度。 那是因为我们已将VSYNC打开。 SRP Batcher确实在CPU端节省了6.8ms。 这些毫秒可以用于其他任务。 它还可以节省移动设备的电池寿命。
如何检查SRP Batcher效率 (How to check SRP Batcher efficiency)
It’s important to understand what is a “batch” in SRP Batcher context. Traditionally, people tend to reduce the number of DrawCall to optimize the CPU rendering cost. The real reason for that is the engine has to set up a lot of things before issuing the draw. And the real CPU cost comes from that setup, not from the GPU DrawCall itself (that is just some bytes to push in the GPU command buffer). SRP Batcher doesn’t reduce the number of DrawCalls. It just reduces the GPU setup cost between DrawCalls.
重要的是要了解SRP Batcher上下文中的“批次”。 传统上，人们倾向于减少DrawCall的数量以优化CPU渲染成本。 这样做的真正原因是引擎在发出抽签之前必须进行很多设置。 真正的CPU成本来自该设置，而不是来自GPU DrawCall本身(这只是要放入GPU命令缓冲区的一些字节)。 SRP Batcher不会减少DrawCall的数量。 它只是降低了DrawCall之间的GPU设置成本。
You can see that on the following workflow:
您可以在以下工作流程中看到这一点：
On the left is the standard SRP rendering loop. On the right is the SRP Batcher loop. In SRP Batcher context, a “batch” is just a sequence of “Bind”, “Draw”, “Bind”, Draw”… GPU commands.
左侧是标准SRP渲染循环。 右边是SRP Batcher循环。 在SRP批处理程序上下文中，“批处理”只是“绑定”，“绘制”，“绑定”，“绘制”…GPU命令的序列。
In standard SRP, the slow SetShaderPass is called for each new material. In SRP Batcher context, the SetShaderPass is called for each new shader variant.
在标准SRP中，对于每种新材料都调用慢速SetShaderPass。 在SRP Batcher上下文中，将为每个新的着色器变体调用SetShaderPass。
To get maximum performance, you need to keep those batches as large as possible. So you need to avoid any shader variant change, but you can use any number of different Materials if they’re using the same shader.
为了获得最佳性能，您需要使这些批次尽可能大。 因此，您需要避免任何着色器变体更改，但是如果它们使用相同的着色器，则可以使用任意数量的不同材质。
You can use Unity Frame Debugger to look at the SRP Batcher “batches” length. Each batch is an event in frame debugger called “SRP Batch”, as you can see here:
您可以使用Unity Frame Debugger查看SRP Batcher的“批次”长度。 每个批次都是帧调试器中称为“ SRP Batch”的事件，如您在此处看到的：
See the SRP Batch event on the left. See also the size of the batch, which is the number of Draw Calls (109 here). That’s a pretty efficient batch. You also see the reason why the previous batch had been broken (“Node use different shader keywords”). It means the shader keywords used for that batch are different than the keywords in the previous batch. It means that the shader variant has changed, and we have to break the batch.
请参阅左侧的SRP Batch事件。 另请参阅批处理的大小，即绘图调用的数量(此处为109)。 这是一个非常有效的批处理。 您还将看到上一个批次被破坏的原因(“节点使用不同的着色器关键字”)。 这意味着用于该批次的着色器关键字不同于先前批次中的关键字。 这意味着着色器变体已更改，我们必须中断该批处理。
In some scenes, some batch size could be really low, like this one:
在某些情况下，某些批次的大小可能会非常低，例如：
Batch size is only 2. It probably means you have too many different shader variants. If you’re creating your own SRP, try to write generic “uber” shader with minimum keywords. You don’t have to worry about how many material parameters you put in the “property” section.
批处理大小仅为2。这可能意味着您有太多不同的着色器变体。 如果要创建自己的SRP，请尝试使用最少的关键字编写通用的“超级”着色器。 您不必担心在“属性”部分中输入了多少材料参数。
NOTE: SRP Batcher information in Frame Debugger requires Unity 2018.3 or higher.
注意：Frame Debugger中的SRP Batcher信息需要Unity 2018.3或更高版本。
使用兼容的着色器编写自己的SRP (Write your own SRP with compatible shader)
Note: This section is made for advanced users writing their own Scriptable Render Loop and shader library. LWRP or HDRP users can skip this section, as all shaders we provide are already SRP Batcher compatible.
注意：本部分适用于高级用户，他们编写了自己的Scriptable Render Loop和着色器库。 LWRP或HDRP用户可以跳过此部分，因为我们提供的所有着色器已经与SRP Batcher兼容。
If you’re writing your own render loop, your shaders have to follow some rules in order to go through the SRP Batcher code path.
如果要编写自己的渲染循环，则着色器必须遵循一些规则才能通过SRP Batcher代码路径。
“每种材料”变量 (“Per Material” variables)
First, all “per material” data should be declared in a single CBUFFER named “UnityPerMaterial”. What is “per material” data? Typically all variables you declared in the “shader property” section. That is all variables that your artist can tweak using the material GUI inspector. For instance, let’s look at a simple shader like:
首先，所有“每种材料”数据都应在一个名为“ UnityPerMaterial”的CBUFFER中声明。 什么是“每材料”数据？ 通常，您在“着色器属性”部分中声明的所有变量。 那就是艺术家可以使用材质GUI检查器调整的所有变量。 例如，让我们看一个简单的着色器，例如：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
|
Properties
{
_Color1 ("Color 1", Color) = (1,1,1,1)
_Color2 ("Color 2", Color) = (1,1,1,1)
}
float4 _Color1;
float4 _Color2;
|
|
1
2
3
4
5
6
7
8
9
10
11
12
13
|
Properties
{
_Color1 ( "Color 1" , Color ) = ( 1 , 1 , 1 , 1 )
_Color2 ( "Color 2" , Color ) = ( 1 , 1 , 1 , 1 )
}
float4 _Color1 ;
float4 _Color2 ;
|
If you compile this shader, the shader inspector panel will show you:
如果编译此着色器，则着色器检查器面板将显示以下内容：
To fix that, just declare all your “per material” data like that:
要解决此问题，只需声明所有“按物料”数据，如下所示：
|
1
2
3
4
5
6
7
|
CBUFFER_START(UnityPerMaterial)
float4 _Color1;
float4 _Color2;
CBUFFER_END
|
|
1
2
3
4
5
6
7
|
CBUFFER_START ( UnityPerMaterial )
float4 _Color1 ;
float4 _Color2 ;
CBUFFER_END
|
“每个对象”变量 (“Per Object” variables)
SRP Batcher also needs a very special CBUFFER named “UnityPerDraw”. This CBUFFER should contain all Unity built-in engine variables.
SRP Batcher还需要一个非常特殊的CBUFFER，名称为“ UnityPerDraw”。 该CBUFFER应该包含所有Unity内置引擎变量。
The variable declaration order inside of “UnityPerDraw” CBUFFER is also important. All variables should respect some layout we call “Block Feature”. For instance, the “Space Position block feature” should contain all those variables, in that order:
“ UnityPerDraw” CBUFFER内部的变量声明顺序也很重要。 所有变量都应遵循我们称为“块功能”的某些布局。 例如，“空间位置块功能”应按以下顺序包含所有这些变量：
|
1
2
3
4
5
6
7
|
float4x4 unity_ObjectToWorld;
float4x4 unity_WorldToObject;
float4 unity_LODFade;
float4 unity_WorldTransformParams;
|
|
1
2
3
4
5
6
7
|
float4x4 unity_ObjectToWorld ;
float4x4 unity_WorldToObject ;
float4 unity_LODFade ;
float4 unity_WorldTransformParams ;
|
You don’t have to declare some of these block features if you don’t need them. All built-in engine variables in “UnityPerDraw” should be float4 or float4x4. On mobile, people may want to use real4 ( 16 bits encoded floating point value) to save some GPU bandwidth. Not all UnityPerDraw variables could use “real4”. Please refer to the “Could be real4” column.
如果不需要它们，则不必声明其中的某些块功能。 “ UnityPerDraw”中的所有内置引擎变量应为float4或float4x4。 在移动设备上，人们可能想使用real4(16位编码的浮点值)来节省一些GPU带宽。 并非所有UnityPerDraw变量都可以使用“ real4”。 请参考“可能是真实的”一栏。
Here is a table describing all possible block features you could use in the “UnityPerDraw” CBUFFER:
下表描述了可以在“ UnityPerDraw” CBUFFER中使用的所有可能的块功能：
NOTE: If one of the variables of one feature block is declared as real4 ( half ), then all other potential variables of that feature block should also be declared as real4.
注意：如果将一个功能块的变量之一声明为real4(half)，则该功能块的所有其他潜在变量也应声明为real4。
HINT 1: always check the compatibility status of a new shader in the inspector. We check several potential errors ( UnityPerDraw layout declaration, etc ) and display why it’s not compatible.
提示1：始终在检查器中检查新着色器的兼容性状态。 我们检查了几个潜在的错误(UnityPerDraw布局声明等)，并显示为什么不兼容。
HINT 2: When writing your own SRP shader you can refer to LWRP or HDRP package to look at their UnityPerDraw CBUFFER declaration for inspiration.
提示2：在编写自己的SRP着色器时，可以参考LWRP或HDRP包以查看其UnityPerDraw CBUFFER声明以获取灵感。
未来 (Future)
We still continue to improve SRP Batcher by increasing batch size in some rendering passes (especially Shadow and Depth passes).
我们仍然通过在某些渲染过程(尤其是“阴影”和“深度”过程)中增加批量大小来继续改进SRP Batcher。
We’re also working on adding automatic GPU instancing usage with SRP Batcher. We started with new DOTS renderer used in our MegaCity demo. The speedup in the Unity editor is quite impressive, going from 10 to 50 FPS.
我们还在努力通过SRP Batcher添加自动GPU实例化用法。 我们从 在 MegaCity演示中 使用的 新 DOTS 渲染器 开始 。 Unity编辑器中的加速比令人印象深刻，从10到50 FPS。
MegaCity in-editor with SRP Batcher & DOTS renderer. The difference in performance is so huge that even global frame rate speeds up by a factor of five.
具有SRP Batcher和DOTS渲染器的MegaCity in-editor。 性能上的差异如此之大，以至于全局帧速率也提高了五倍。
NOTE: To be precise, this massive speedup when enabling the SRP Batcher is editor only, due to editor currently not using Graphics Jobs. Speedup in Standalone player mode is something like x2.
注意：确切地说，由于编辑器当前未使用“图形作业”，因此启用SRP Batcher时的这种巨大加速仅是编辑器。 独立播放器模式下的加速类似于x2。
MegaCity in Editor. If you could play the video at 60hz you would feel the speed up when enabling SRP Batcher.
编辑器中的MegaCity。 如果您可以60hz的速度播放视频，则启用SRP Batcher时会感觉速度有所提高。
NOTE: SRP Batcher with DOTS renderer is still experimental and in active development.
注意：带有DOTS渲染器的SRP Batcher仍在试验中，并且正在积极开发中。
翻译自: https://blogs.unity3d.com/2019/02/28/srp-batcher-speed-up-your-rendering/
srp batcher