What is the point of SRP Batcher if it sucks?

I placed 10k cubes with standard HDRP/Lit material and I got:

- SRP batcher enabled, material GPU instancing disabled: 37fps, 26K+ Batches, Saved by batching 0.

- SRP batcher disabled, material GPU instancing enabled: 60fps, 150 batches, Saved by batching 26K.

Anyone?

 

Are those from the editor or in a build?

 

From editor.

 

I have tested again with a stand alone build:
- SRP batcher 72-75 fps
- GPU Instancing 115-120 fps
SRP batcher sucks big time!

 

Try creating 5~ materials, and assigning them to 5 different types of cubes with different colors, but they all use the same shader (lit)
And then copy paste all 5 cubes until there's a very large amount rendered on screen with shadows.

Try SRP with and without in build, I'm interested in results
ideally use profiler to get exact GPU performance

 

I have just tested stand alone build. Results above.

 

SRP batcher benefit is when you have many different materials using the same shader, hence my suggestion

 

Yes, I checked the documentation and got the idea, but GPU instancing is just a lot faster. I did test SRP batcher with one material and with many materials and same shader. Whatever I do srp batcher loses with gpu instancing. Problem is that shader graph doesn't support per object instance data, what I need in my project, and manual shader hacking to support it is a tedious process. I am just wondering if it is not a deal breaker for this pipeline and what is a point of developing this srp snail. Thanks anyway.

 

The strength of the SRP Batcher is that you don’t have to care about batching all that much and it performs much better than built in draw calls did.

But obviously, if you make a test case tailor made for instancing, instancing is going to win. SRP Batcher is less restrictive than instancing though.

 

Never trust or rely on something default without digging deeper.

I found and enabled the option "Overwrite Property Declaration->Shader Declaration->Hybrid Per Instance" inside shader graph and to my surprise it works with material property blocks, so per object instance data can be used with shader graph. I am leaving this info for people who have the same problem. I assigned diferent colors to all the cubes in the scene with this code:

Code (CSharp):

1. MeshRenderer renderer = GetComponent<MeshRenderer>();
2. MaterialPropertyBlock block = new MaterialPropertyBlock();
3. block.SetColor("_Color", new Color(Random.Range(0.0f, 1.0f), Random.Range(0.0f, 1.0f), Random.Range(0.0f, 1.0f)));
4. renderer.SetPropertyBlock(block);
5.  

There are 10k cubes drawing with per instance data with very good performance comparing to srp batcher.

 

My honest experience with the SRP batcher is that it is between "meh and good enough"

1) In the best possible scenario, it provides slightly better performance than dynamic batching

2) But in almost all game environment scenario, GPU instancing is just superior.

then why SRP batcher?

It is automatic in HDRP and I just don't bother turning it off...

Not to say that it has no place in HDRP. It is useful in many scenarios. Just that it is not "the best solution ever." Nor was it designed to replace instancing. A good dynamic, automated batcher. But I did expect it to perform better and it did not.

Also, the good side to GPU instancing -> no Gameobject and that much simpler and faster.

 

I was very confused about it. Documentation makes you think that it is superior to other rendering techniques. To disable srp batcher I had to switch to debug mode in the inspector and there is a checkbox to do it. Or you can disable it from code. I think gpu instancing should be the default one and the option to use per instance data should not be hidden in the shader graph.

Is there maybe a better way of disabling srp batcher? There are too many setting in the HDRp scattered around..

 

Hello,
Thank you for the tip!

Could you elaborate a bit on how you managed to get the different colours to render for the 10k cubes? For instance, could you share the whole code you used in your example and your shader graph?

I know it should be simple enough but I cannot manage to reproduce your example...

I've used material property blocks before and I have no problem rendering what I want with custom shaders. But, even though I found the option you mentioned ("Overwrite Property Declaration->Shader Declaration->Hybrid Per Instance") my cubes don't change color. Instead, they keep the default color set in the Shader Graph editor.
But, strangely, the Color property of the material attached to my cubes is correctly updated but they still don't change color (see the image below).


I use Unity 2020.3.12f1, URP 10.5.1, Shader Graph is also 10.5.1.

And the code I used to instantiate my cubes:

Code (CSharp):

1. public GameObject refprefab;
2.     // Start is called before the first frame update
3.     void Start()
4.     {
5.         MaterialPropertyBlock props = new MaterialPropertyBlock();
6.         MeshRenderer renderer;
7.  
8.         for (int i = -100; i < 100; i++)
9.         {
10.             for (int j = -100; j < 100; j++)
11.             {
12.                 GameObject go = Instantiate(refprefab, new Vector3(i , 0f, j ), Quaternion.identity);
13.  
14.                 float r = Random.Range(0.0f, 1.0f);
15.                 float g = Random.Range(0.0f, 1.0f);
16.                 float b = Random.Range(0.0f, 1.0f);
17.  
18.                 renderer = go.GetComponent<MeshRenderer>();
19.                 props.SetColor("_Color", new Color(r, g, b));
20.  
21.                 renderer.SetPropertyBlock(props);
22.             }
23.         }
24.     }

The code above works if use a basic URP Unlit shader that I edited to accept Material Property Blocks instead of SRP batching.

Thank you in advance!

 

Wait...are we getting to a verdict where SRP batcher is definitely inferior?

I will try post results in the next few days during my optimization pass...

 

Hm... I'd rather say it's another illustration of "different problems, different solutions".
After all, in the doc (https://docs.unity3d.com/Manual/SRPBatcher.html#how-the-srp-batcher-works) they say at the very beginning:
"The SRP Batcher reduces the CPU time Unity requires to prepare and dispatch draw calls for materials that use the same shader variant."
And, later, in the section entitled "Intentionally removing SRP Batcher compatibility for GameObjects", they admit that:
"If you want to render many identical meshes with the exact same material, GPU instancing can be more efficient than the SRP Batcher"

Thus, if the doc is completely accurate, for the SRP batcher the restriction is on the "same shader variant" whereas for GPU instantiation it is "identical meshes with the exact same material".

So, in the trivial benchmark situation where you render a lot of cubes, GPU instanciation ends up being faster. But I'm pretty sure we could find a threshold where it's not true anymore. And, in that case, the SRP batcher still has the advantage to do the btaching work for you without the MaterialPropertyBlock boilerplate (albeit quite small).

Meaning that having both runing to handle rendering of different groups of GameObjects is probably what everybody ends up with...?

 

In my experiments, although only executed in Editor, it shows always a bit more performance if I disable SRP Batcher (1-2 tenth of ms). It's a VR application with a huge variety of materials and meshes. Have not done tests in build yet.

 

SRP batcher also reduces draw cost with different meshes, different textures but same shader.
It may be advantageous to material GPU instancing in some use case.

 

Here you go. Shader, material and the code. If you have everything set up correctly and it doesn't work, then probably it is another case of URP and HDRP pipelines incompatibility and the mess which is present everywhere in Unity (the reason I am already switching to Unreal Engine). What is more you can't disable SRP batcher in a clean way in options. I think most of the games use some kind of modularity - many instanced meshes with parametrised materials - so GPU instancing should be a default choice.

Code (CSharp):

1. public class BatchTest : MonoBehaviour
2. {
3.     void OnEnable()
4.     {
5.         MeshRenderer renderer = GetComponent<MeshRenderer>();
6.         MaterialPropertyBlock block = new MaterialPropertyBlock();
7.         block.SetColor("_Color", new Color(Random.Range(0.0f, 1.0f), Random.Range(0.0f, 1.0f), Random.Range(0.0f, 1.0f)));
8.         renderer.SetPropertyBlock(block);
9.     }
10. }

 

Yes, that is what the doc says according to Unity. But, in my experience, I don't think I recall a case where SRP batcher was more performant and it seems like pretty much everyone feels the same way. Hence, while theoretically SRP batcher has its place, I was trying to see if "SRP batcher has no place" in real world applications and whether that statement is wrong in any way. I mean, turning on/off SRP batcher is easy but if it has no real world performance benefit, then maybe we should start leaning towards a fully GPU instancing based method as a community. Unity can either respond by improving the SRP batcher or leaving it behind and working on something more practical.

Either way, I thought it might benefit everyone if we can actually get to the bottom of this SRP batcher thing...I turned mine off last night...and it seems to be doing better...and started thinking if the batcher is actually a useful thing.

 

Thank you very much for sharing!

Unfortunatly I've just spent the last 3hrs trying to get it to work within blank new projects and it still doesn't...
After setting the Color via MPB the cubes render to black whatever I do. I have no idea what could be different between your project and mine. That's a shame: being able to use Shader Graph with GPU instantiation sounded quite appealing!

Just checking, what are your Unity and package versions?

 

Unity 2020.3.27, HDRP 10.8.1, Shader Graph 10.8.1

 

For drawing many instances of the same mesh with the same material, instancing will always win.

There's nothing magical behind SRP batcher, it's merely a Unity solution for an Unity problem: needlessly re-setting identical render states and shader parameters between draw calls which use the same shader. It only reduces the cost of individual draw calls because Unity had them more expensive than they should be to begin with.

But even if you reduce the state change costs to a bare minimum (like changing only the object matrix), you cannot avoid the base cost of issuing a draw call to the GPU driver. That's why the entire industry has been moving to GPU-driven pipelines: you cannot feasibly render tens/hundreds of thousands objects in a modern looking game with plain old DX9-era draw calls.

However, mobile GPUs have been much slower in supporting things like instancing and compute shaders reliably, so I suppose they are the main targets behind SRP batcher.

 

Thank you again @Mariusz-Born7 I got it to run.

I know this is slightly off topic from the main question of this thread, but here is a summary to enable Material Property Block from shaders built with Shader Graph:

• First, this does not work with Unity 2020.3.12f1, URP 10.5.1 or HDRP 10.5.1, Shader Graph 10.5.1. It does work with Unity 2020.3.27f1, URP 10.8.1 and HDRP 10.8.1, Shader Graph 10.8.1
• Here is the code of instanciation of my cubes that I attached to a trivial Game Object in the scene:
  
  Code (CSharp):

  1. public class SpawnCrowd : MonoBehaviour
  2. {
  3.     public GameObject refprefab;
  4.  
  5.     void Start()
  6.     {
  7.  
  8.         for (int i = -50; i < 50; i++)
  9.         {
  10.             for (int j = 1; j < 26; j++)
  11.             {
  12.                 Instantiate(refprefab, new Vector3(i * 0.25f, 0.5f, j * 0.25f), Quaternion.identity);
  13.             }
  14.         }
  15.     }
  16. }
• Here is the code to set the color that I attached to my prefab cube:
  
  Code (CSharp):

  1. public class RandomColor : MonoBehaviour
  2. {
  3.     void OnEnable()
  4.     {
  5.         MeshRenderer renderer = GetComponent<MeshRenderer>();
  6.         MaterialPropertyBlock block = new MaterialPropertyBlock();
  7.         block.SetVector("_Color", GetRandomColor());
  8.         renderer.SetPropertyBlock(block);
  9.     }
  10.  
  11.     static Color GetRandomColor()
  12.     {
  13.         return Color.HSVToRGB(Random.value, 1, .9f);
  14.     }
  15. }
• Here is a screenshot using URP 10.8.1 (2500 cubes ->10 batches and 1965 saved by batching):
• Here is a screenshot using HDRP 10.8.1 (2500 cubes -> 121 batches and 11 839 saved by batching)

• I think it's worth mentioning that I'm investigating this for my VR project targeting the Oculus Quest 2 (so Mobile build) and it also worked once I upgraded to URP 10.8.1. Here is a screenshot of the scene with 2500 cubes as well as a screenshot of the profiler I attached to it via dev build: Although 2500 cubes is pretty much the upper limit since rendering takes 8.15ms out of your budget.

That will be all for me, I got what I was looking for: the flexibility of Shader Graph with Material Property Blocks in URP
Thank you again @Mariusz-Born7 for the tip on overriding the property declaration in Shader Graph.

 

@LittleCoinCoin @Mariusz-Born7

At first when I found this thread I was incredibly happy.
I am super interested in getting to know how you achieved using the property blocks in URP. It would make my life sooo much easier. Following the rough guide by littlecoincoin I can not reproduce your results.
Unity 2022.1.4f1, URP 13.1.8
RandomColor breaks batching for me immediately and entirely. 2500 Batches rendered, none through srp batcher (the saved batches reported by the stats window are solely shadow draw calls).
As far as I know Hybrid Per Instance is a feature used in the DOTS hybrid renderer but I might be wrong there...



(If unity had gotten prop blocks to work with urp wouldn't this be mentioned somewhere in huge letters? but apparently .. it kind off is there but it is using another way of batching which is not the constant buffer way the srp batcher uses? would that basically mean gpu instancing which should be super fast?!)

(https://docs.unity3d.com/2022.1/Documentation/Manual/render-pipelines-feature-comparison.html)

"Note that this is not compatible with SRP Batcher. Using this in the Universal Render Pipeline (URP), High Definition Render Pipeline (HDRP) or a custom render pipeline based on the Scriptable Render Pipeline (SRP) will likely result in a drop in performance."
(https://docs.unity3d.com/ScriptReference/MaterialPropertyBlock.html)


looking forward to hearing from anyone about this.

 

SRP batcher and GPU instancing are two different things. GPU instancing breaks srp batcher, so if you want to render with gpu instancing, you should disable srp batcher, at least in HDRP.




or from code:

Code (CSharp):

1. GraphicsSettings.useScriptableRenderPipelineBatching = false;

 

Yes I am aware of that. Okay but that probably means I missunderstood what you were going for. What your setup above achieves is using shadergraph with gpu instancing. It is not about using property blocks with the srp batcher?

 

Generally this thread is about SRP Batcher vs GPU instancing. We have proved here that gpu instancing is much more performant when you want to draw thousands of meshes. Unity forces you to use srp batcher which is much slower then gpu instancing. It discouarges you from using gpu instancing in the docs, what in my opinion, is wrong. And yes, the problem was also how to use gpu instancing with shader graph. I switched from built-in render pipeline to SRP and I wanted to switch from hand written shaders to shader graph too, but I couldn't find a way to enable gpu instancing. I think that property blocks work only with gpu instancing.

 

okay thanks for the clarification.
Then I am less surprised though, the advantage of srp batcher is clearly in it's flexibility (different textures, different properties, different mesher, same shader is the necessity and well not per object properties -.-), this makes it easier as a shoot and forget solution.
While gpu instancing has harder constrains (same mesh for example) but obviously better performance.

 

I got a tiny question regarding that sentence.
I did a few tests last year rendering around 20-30 thousand objects using srp batcher and instancing. The set consisted of few different low poly meshes and a unique tint color for each object.
Instancing was extremely fast obviously and got better the fewer different meshes were involved. At first the instancing batches got split by sorting but forced to different queue ids this setup was very optimized.
The SRP Batcher version of that experiment created unique instances of the assigned material and assigned a random value to the color property. Not as fast as instancing sure, but still rendered very fast, so fast the usability advantage was probably worth the extra few miliseconds.
BUT this creates another full material instance which should create a noticable memory and or scene size penalty?
AND that unity version back then didn't have material instance variants so there was no good interface to keep the newly instanciated materials synced on a few properties while overwriting others and that was a major issue back then.

Property blocks were super useful because they allowed for a lightweight way of overwriting a material partially, without much hassle and management of another material instance. I guess material variants pose a reasonable way of replacing property blocks in a SRP context but its certainly not as convienent.
Are these thoughts correct or am I missing a major drawback, are that many material instances usually a problem?

 

late to party. with real life game models, it is always having different meshes and materials.

gpu instancing will not work because of different meshes and different materials.

material property block will have minimum impact because even with same shader, different material properties will still not batch.

srp does the magic. as long as they all use the same shader, most things will batch up. and we are free to use material instances.

a scene from a project:

before srp batching:

after srp batching:

 

sure srp batcher is pretty great at reducing the impact of the draw calls but remember that they are not actually batched into one. With super low poly scenes like yours I prefer using a reasonable amount of static batching plus srp batching for maximum efficiency

This is very helpful for analyzing srp draw calls as well
https://github.com/Unity-Technologi...b/master/Assets/Scripts/SRPBatcherProfiler.cs

 

thanks for the reply. we are well aware of static batching and baking is always better than runtime batching. But all things (except the ground) in the scene is runtime destructible so we cannot use static.

also as much as the look may imply, they are not “low polygon” enough in view of the dynamic batcher (900 attributes)

 

oh well I did not expect that
In that case obviously static batching isn't much of an option you are right. Except maybe drawing all undestroyed building as static first and replacing them on destruction with their shattered version which then falls apart (and has to be drawn srp batched dynamic), but that is already overoptimizing in advance I guess.

Just after I replied to your post on an unrelated search I found this btw: https://issuetracker.unity3d.com/is...on-with-shader-graph-when-batching-is-enabled

So maybe relying on static batching at all is not really a reliable thing for the future anyway.
I have never tested this either but I would think dynamic batching performs worse that srp batching in most cases as well.

 

"you" as in who exactly? Yes the using MPBs breaks SRP batcher, I interpreted one of the earlier post wrong and thought someone had gotten both to work at the same time and was surprised by that because I only know the breaking case too.

 

but ... people ...

when, on God's earth, would hou need to render 10k cubes ???

Pretty much 99.99 percent of games in existance would benefit from srp batching that allows texture swaps.

just enable GPU instancing if you need trees, or copy/paste structures ...

and even then, are you really THAT lazy to sacrifice your world's variety that now suffers from repetition?

I really don't get the hate ... srp batcher is yet another powerful tool at our disposal, alongside dinamic batching and gpu instancing.

 

I feel like I am taking crazy pills reading this forum thread. People have no idea how games are built, but are doing suboptimal performance tests and bad mouthing it. No offence but you are skewing the numbers for no apparent reason.

A proper test would include hundreds if not thousand different meshes and materials using the same shader but different textures and values.

I managed to get the Switch to run my game on 60fps thanks the to the SRP Batcher with hundreds of different materials and meshes in view. Games usually have hundreds of similar materials that can use the same shader which will benefit a lot from the nature of the SRP Batcher. Usually you just change the textures and tweak shader variables which should be placed within the CBUFFER to make the right impact.

That said there are a lot of bad stuff in Unity not using the SRP Batcher properly, like most of the renderers does not support it at all which sucks. (only Mesh and skinned mesh renderers support it) And the sprite renderers are pretty bad at utilizing it.

I converted a lot of the renderers(line, spriteshape, sprite) to my own systems that updates a mesh renderer instead.

I feel bad for the people making the SRP Batcher for having to read these kind of unthankful threads.


Great work on the SRP batcher Unity!
But please make it support more renderers and make it easier to write your own shaders instead of relaying on the shader graph.

Edit: Though I guess this is the HDRP forum so maybe me using the URP I am in the wrong forum... I ended up here by googling a "SRP not compatible" shader "error". "srp batcher material property is found in anoher cbuffer" lmao

 

I will stand firm in my opinion that SRP sucks, and what is more, general rendering performance of Unity sucks. I know how games are built, but I will not smart off. The tests given here are just the simplest ones. I tested everything on the real project I am working on. In Unity I was able to achive 25 fps in mesh heavy areas and SRP Batcher's stats were the worst. Next I moved my project to Unreal. It took me over three months to recreate all models with better quality in order to use Nanite and Lumen. I also rewritten the entire code in C++. Results - constant 60 fps and much better look.

After all that effort, as a final test, I converted my scene in Unity to new ECS bullsh*t sub scene and rendering perfomance stayed at the same poor level. Unity is not able to process thousands of objects. It is bad designed. Without ECS every LOD or compound collider is a GameObject, what adds up and degradate performance. After converting to ECS, in my case, I didn't notice any performance boost. But I don't care anymore, because Unreal can render millions of instances without hassle.

 

ECS and DOTS aren't even needed to render 1000k objects.

SRP benefit is in reducing the GPU usage by increasing CPU initial time for batching, that is now standardized across all devices.

You trade maximum performance ( thing built-in still provides) for compatibility and reliability.

It feels like you are just using the wrong tool for the job ... if Unreal Engine has tech that makes what you do performant, then use that. Unity devs will gladly tell you the same, and wish you the best probably!☝️

Finally, FPS =\= Power consumption.

There are legitimate reasons to cap or even handycap the performance of a game.

Think of BloodBorne and the fact they managed to avoid so many headaches by capping the game at 30, making physics and frame-rate drops less of an issue.

Ah, and of course, another important thing js that wisely Unity balanced USABILITY with PERFORMANCE.

Just take a look at Playcanvas and Unreal Engine.

Despite both of them being better on paper, the former is too painful to use, while the latter will explode in your face unless you have a supercomputer ...

In fact, you can see a trend of both wealthy people that choose that engine end up commissioning the game to another instead of doing it themselves

 

People keep making S*** up. URP was supposed to be a cleaner meaner faster alternative, while built-in had more features.

It's also a lot less compatible with stuff than built-in. I would be more positive towards newer Unity features if people didn't make up stuff constantly as to what the purpose of the new features are.

 

Dealing with life expecting what " it was supposed to be " is peak immaturity.

Deal with what SRP is ... an alternative infrastructure to tackle real dev-life problems.

It personally increased my productivity 2 fold to be conservative.

Again, if you only target high-end hardware, you won't feel the benefit ... as it is not built for those platform specifically.

 

Cool.

 

And I mainly write this because there ARE INDEED things Unity does absolutely wrong. Countless!

But the URP/HDRP/SRP change was one of the best thing they did to be honest.

 

This thread keep showing on top Google results with lots of misinformation.

Just giving my 2 cents, because lots of guys here don't know how to test/use SRP batcher or simply isn't the use case for their project.


Tested on Unity 2022.3.0 URP, i5 9600KF, RTX 3060 using SRPBatcherProfiler.cs

SRP batcher improved my loop draw CPU time from 12 ms to 3 ms on my GTA-like game, which is an urban environment, so it uses lots of different meshes and materials, not possible to be improved by GPU instancing, but it will be used for props. That is simple. And lowering CPU time is extremely important in a game like mine where there will be a lot of NPCs etc.

And yes, my map is already optimized with knowledge of chunks, texture atlas etc. There are also dynamic objects that will be interacted with by gameplay, so it's a more real-dev test than spawning 10k cubes.

Don't jump to conclusions about other people's tests, do the tests yourself on your own projects, if something exists, it's because there is use for it, maybe it's for your project, maybe is not.

 

What are you comparing? SRP batcher vs no batching at all (no static batching?), no instancing, no nothing?

The original post is comparing SRP Batcher vs instancing and instancing wins, which kinda makes sense since instancing is more limiting in what it can apply on.

3ms is still quite a lot, for what I'm assuming is a mostly static city, I would have expected better from the SRP Batcher if you're optimising for it.

 

Be fantastic to see comparison projects stats and screenshots for this. ;-)