The release notes of 2018.2b1 mention this:
More info on what this is?
2 Likes
I have not been able to find documentation for this feature - how it works, what breaks batching, what are the limitations etc. Iâve googled around but have only found announcement posts (SRP Batcher is released!) but nothing technical. Anyone have any links?
There isnât really anything at this point. Iâve found that as of 18.3 Shaders, if viewed in the Inspector will show âSRP Batcher Compatibleâ or a reason why it is incompatible, most commonly that the Constant Buffers must be uniform across all Passes/Variants. In my tests Iâve seen some differences in between SRP Batcher On/Off but cannot discern what exactly has changed.
Hope we get some more info soon. It seems really powerful. I have a scene with a bunch of different materials with different properties. It seems that as long as they are the same shader, and use the same keywords, they can be batched together. Very very cool.
It would be cool if this could somehow be done on a per shader pass basis as well. For example, whether my workflow is metallic or specular, the shadow caster pass will look the same! The shadow pass doesnt care about these keywords. Yet the SRP batching breaks when rendering shadows if my materials have 2 different workflow modes active. Maybe if the shader pass exposed some metadata regarding which keywords âit containsâ, so when Unity is rendering the shadows the SRP Batcher will see that the 2 materials have different keywords, buuuut the keywords that are different arenât used in the shadow pass, so they could be batched together anyway!
Recently came across this now again. There is:
But yeah⊠not very helpful.
Anyone knows yet what this is doing under the hood?
Hi! We should communicate about SRP batcher. Blog post is coming soon. I can give you some information here.
Basically âSRP batcherâ is a generic name for âSRP dedicated c++ rendering inner loopâ. In standard Unity, setting a new material is quite CPU consuming. Worst case scenario would be a scene with 1000 meshes, each one use its own material (for instance with diffuse texture and albedo color change)
With SRP batcher, changing material is way faster than before ( because material data are now persistent in GPU ). You just have to use same shader, but you can have any number of materials. In the previous case ( 1000 meshes with 1000 different material), the CPU speedup factor is about 5 times! ( measured on âRenderLoop.Drawâ and âShadowLoop.Drawâ CPU profiling labels)
If you want to play with and do some test on your own project, you could use that nice profiler script. Press F8 to toggle profiling information on screen, and press F9 to toggle ON/OFF SRP batcher.
Feel free to ask questions about SRP batcher here.
4099828â358759âMiniProfiler.zip (1.71 KB)
6 Likes
Thatâs great! Thanks Arnaud. Sounds like the exact thing I need for our use case.
Is there any special care we need to take in the shader? Just make sure everything is in a constant buffer or?
are you writing your own SRP or use existing LWRP or HDRP? there are some rules to respect in your shader to be SRP batcher compatible. If you donât respect the rule, the object is still properly rendered, using the standard unity rendering code path. When you look in the shader inspector in a SRP based project, you can see a line âSRP batcher: Compatible or Nor compatibleâ with a reason why itâs not compatible.
But basically, unity âbuilt-inâ vars should be located in a CBUFFER named âUnityPerDrawâ ( you can have a look in LWRP or HDRP). You should use the same for your own SRP
Most important, all your âmaterialâ vars should be located in a CBUFFER called âUnityPerMaterialâ. ( so all vars declared in the shader property section should be in âUnityPerMaterialâ CBUFFER
Again, shader inspector with âSRP batcher compatibilityâ hint is really usefull to see what is wrong in the shader to be SRP batcher compatible
1 Like
Makes sense! Thatâs very doable. Itâs a custom SRP (itâs for Manifold Garden, quite stylized rendering).
Weâre shamefully on 2017.4 still, but this might be a good pish to migrate, will do some perf tests for some of our levels soon.
Thanks again!
I just looked at a âManifold Gardenâ trailer video, looks nice. Btw seems to be really monochromatic. I guess you donât have so many different materials in that kind of scene right? Less you have material, less will be the SRP batcher speedup.
Manifold Garden is quite awesome! are you guys using a custom SRP or one of the ones we provide?
Ah thanks! Itâs been so long in dev that SRP wasnât really an option. However, at some point we made our own shadow mapping system since the legacy pipe requires rendering the scene twice for cascades. That kept giving us headaches so⊠finally converted our hacked together pipe into an SRP now 
Definitely cleaned our code up tons, will compare perf properly somtime
The SRP batcher should be perfect indeed. The world wrapping means we can end up with quite a few draw calls despite combining as many objects as we can & instance rendering.
Hi @arnaud-carre and @phil_lira , I am just wondering if SRP Batcher actual works in 2018.x releases?
Only SRP 5.x release has SRP Batcher options available, so does it mean SRP Batcher is only for 2019.x releases?
(Also I canât seem to find the âSRP Batcher Compatibleâ wording in inspector, I must be missing somethingâŠ)
SRP batcher has been released in 2018.3, but âSRP Batcher Compatibleâ wording is 2019.1. ( be carefull the wording is active only if youâre using a SRP project)
About enabling the batcher, even if SRP didnât expose the âSRP batcherâ flag, you can activate it using script ( use miniprofiler.cs script provided in this thread)
1 Like
Hi I just tested your mini profiler script, very helpful!
It seems useScriptableRenderPipelineBatching is not set to true by default? Is it still in preview on 2018.3?
Hi, useScriptableRenderPipelineBatching is true by default in 2019.1 but should work correctly in 2018.3 too
1 Like
Current SRP Batcher has issues with large meshes that contain more than one submesh/material (apparently only reproduced with DX11 so far). Just mentioning it here in case others stumble on the same thing. Issue report here if people want to follow it:
For non-technical people out there, Unity defaults to 32-bit vertex index buffer for meshes with >65k vertices, otherwise it uses 16-bit indices for it and that still works with submeshes using the SRP batcher. You can also manually force a bigger mesh to use 16-bit indexing and Unity will then split your mesh into smaller chunks so they can fit into that buffer.
2 Likes
thanks for reporting. The issue has been fixed in our current code base ( so 2019.2 ). Issue only affect dx11, SRP batcher with 32bits indexed mesh used in additional sub-meshes. ( so currently if you have a 32bits mesh without any additional submesh, everything should be ok).
1 Like
Oh cool, so next question really is, will the fix be backported to 2019.1?