"SRP Batcher" in 2018.2

The SRP Batcher blog post shows a checkbox to enable/disable SRP Batching, but we've been unable to find that checkbox in the HDRP Asset's inspector. There is no Experiment tab. (Obviously, the blog post is old, so the UI/options may not be accurate anymore.)

We can deactivate SRP batching with F9, with the script the blog post provided, but we'd like the option to toggle it more permanently.

Is it that in recent versions of Unity/HDRP, the SRP Batcher is never meant to be deactivated, except to for debug purposes (like using F9)?

 

It's meant to be enabled by default now. You can still disable it via scripting API if you want.

 

If Sprite Renderer is not supported by SRP, what do Unity suggest to do about drawcall batching for Sprites rendering in URP. ( And URP 2D Renderer) ? What Shader do we have to use on URP for Sprite in order to benefit from any batching at all?

 

I was also curious about this recently and was researching my best options. In terms of drawcall batching it seems like using Sprite Atlas and some proper gpu instancing is still a good way to go. I edited a Shader Graph shader to include gpu instancing for a certain use case in my current URP sprite based game.

I was wondering if there had been any movement with Sprite support in the SRP Batcher or not now?

It may be that ECS will eventually be the way to go as well.

 

Use case for disabling it per material is a scene with a lot of trees foliage etc, seen a real use case scene hit the point where GPU instancing is way faster for those. The optimum situation is not that SRP batcher overall is faster, but allow easily to opt for GPU instancing for those outliers which can and do come up so we get best of both worlds.

So use SRP batcher for everything BUT the trees for which i would like to use GPU instancing for example.

 

It could be a sign that SRP Batcher does not batch calls. Double check this with Frame Debugger.
I've seen issues where batcher fails to batch together SpeedTree in URP, as well as my own SpeedTree shader for HDRP being "compatible" in shader inspector when in reality it is not.

For some reason SRP Batcher fails to batch materials which have multiple keywords set (even though those keywords are identical). I suspect that breaking down SpeedTree shader into multiple sub-shaders per leaves / fronds / branches would solve the issue.
Haven't investigated that yet as its a bit low-priority right now for me.

But, I've already submitted a bug report (Case 1309563) that hopefully will get this fixed.
(Or, atleast fix reason in inspector / frame debugger)

 

I did a full day (more like two) of testing with standalone profiler on a scene that has thousands of instances of trees foliage etc through the Unity terrain system. The results were rather unambiguous, The SRP batcher was working (and it doesn't actually batch anything but reduces the cost of each drawcall, hence why the batched metric doesn't work with it on stats window).

It's simply a matter of use case, we do use SRP Batcher because overall it is a much easier system to live by just by ticking it on and ensuring you just don't break SRP compatibility in your shaders. But when you really are pumping out thousands of meshes with very similar materials GPU instancing will win each and every time.

Hence why i remarked about the optimal situation being that i could easily just use a tickbox on whether to use SRP Batching or GPU instancing for a given material or even by shader.

 

Just wondering, what kind of trees have you used for the test?

I've figured out what's breaking SRP Batcher batching in (my) case of SpeedTrees - its submeshes.

Using separate renderers makes SRP batcher to batch correctly, but unfortunately SpeedTrees are designed to be imported as submeshes. So I assume you've used default trees, or other shader / tree?

Edit: Light probes also break batching. Yeah, instancing might be way better.

 

I appreciate the attempt at help but either i'm communicating unclearly or you misunderstood my post or both

SRP is working for the projects trees just fine (which are inhouse) i was merely commenting on the nature of the SRP Batcher which isn't really a batcher at all in the traditional sense it's a different approach to it. However as someone else already stated no single technique is a silver bullet for all use cases. What i'm lamenting here is that using two different methods at the same time has been limited artificially for no good reason where a project could very well want to use SRP batcher for 90% of their assets but Not for something that you spawn in the tens of thousands.

 

Haven't tried default trees, need to try it out someday. Been using SpeedTrees and those do not batch at all (because of submeshes) (I was wrong, see post below instead). Nature of SRP batcher doesn't matter in this case, since it just doesn't work for those draw calls.

Also, lighting probes prevent batching. Maybe I'll just dump all trees and go with something else. Fortunately game lore allows it.

 

@arnaud-carre
I am so sad that SpriteRenderer does not support SRP Batcher..
Any updates?

 

I wonder about this every day... we need official guide on how to go about achieving best possible drawcall optimization for : URP, URP 2DRenderer

 

So, it seems like I was wrong regarding submeshes, its the Tree component that breaks batching internally. It uses MaterialPropertyBlock for wind and such. Got this info from support:

So any "Tree" based tree will break SRP batching.

 

Agreeing with @JJRivers. Being able to easily pick one or the other approach would be nice. I did a quick test with 200k spheres using one tint color and another 200k using a different tint color for a total of 400k in the scene. With SRP enabled I see a render thread cost of 26ms. With SRP disabled the cost goes down to 17ms since those are prime candidates for instancing.

I'd expect SRP to win out with lots of diverse objects but being able to do instancing for select materials without globally disabling SRP would be very beneficial.

 

Have you tried to intentionally break SRP Batching by declaring a variable in the per-material buffer that isn't declared as a material property?

 

I'm a pretty junior developer myself still, i would be interested in how exactly to achieve that using shaders authored in Shader Graph if any such method exists?

Thanks in advance.

 

Don't think that would be possible in vanilla shadergraph, sorry.