SRP Batcher does not exist to make your draw-call count look pretty. It exists to make those draw calls much cheaper on the CPU. If you still judge it by batch count alone, you can talk yourself out of a real win.
The brutal reality check: one draw call per material is expensive because Unity keeps pushing material data and GPU state changes over and over again. SRP Batcher changes that deal. It keeps material data around, reuses it, and cuts the CPU work needed to prepare the next draw. That is the metric that matters here.
Start here: open Frame Debugger. If you duplicate the same mesh and material a few times and see 4 batches but 1 SRP event, do not panic. That is the point. You may still have multiple draw calls, but Unity is barely changing GPU state between them, which is why the calls get cheap.
Check this first before you blame the feature: you need URP or HDRP, an SRP-batchable renderer, and no Material Property Blocks on the objects you expect to batch. If you write custom shaders, engine data must live in UnityPerDraw and your material properties in UnityPerMaterial. Miss that, and compatibility is gone.
First validation pass: use RenderDoc and the SRP Batcher Profiler script from Unity's benchmark project. Use F8 to show the overlay, F9 to flip SRP Batcher on and off, and watch the standard code path stat. Push that value toward zero. Then cut shader variants and unique materials, because that is where this stops being nice theory and starts saving render-thread time.
CEO/Producer translation: this is how you stop renderer optimization from turning into draw-call superstition and turn it into a measurable CPU-time decision.
The members-only module is the full step-by-step playbook: the RenderDoc/API-inspector readback, how Static Batching and GPU Instancing fit into the picture, when Material Property Blocks are useful because they break SRP Batcher, and how to profile the real win without GPU noise lying to you.
In this module:
Join to unlock the full module, audio, and resources.