🎨 Lesson 2.4: Draw Calls & Batching — SRP Batcher, GPU Instancing & the GPU Resident Drawer

What a Draw Call Costs

A draw call is one command from the CPU to the GPU: "draw this mesh, with this state, now." On its own a draw call is cheap. The expensive part is the state change that usually comes with it — telling the GPU which shader, which textures, which material properties to use before the draw. Unity bundles that state setup into what the Profiler calls a SetPass call.

Every SetPass call means the CPU on the render thread has to bind a shader, upload constants, and swap textures — real work in the graphics driver. A scene of 2,000 objects each with its own material can mean 2,000 SetPass calls, and that's how a game becomes CPU-bound on the render thread (the exact symptom you learned to spot in Lesson 2.1: main/render threads packed, GPU sitting idle).

💡 It's a CPU problem, not a GPU one. Counter-intuitively, "too many draw calls" almost never means the GPU can't draw the triangles — modern GPUs eat millions of triangles for breakfast. It means the CPU can't describe them fast enough. Batching exists to reduce the CPU's talking, not the GPU's drawing.

The Idea of Batching

Batching is any technique that lets the CPU describe many objects with fewer, cheaper instructions — by grouping objects that share render state so the expensive state setup happens once instead of per object. Unity 6 / URP gives you three cooperating mechanisms, each suited to a different situation:

Here is the whole point of the lesson in one picture: the same eight objects submitted three ways. Watch the SetPass count collapse from left to right.

The SRP Batcher

The SRP Batcher is URP's default batching system, and it works differently from old-school batching. It doesn't merge meshes. Instead, it exploits a simple fact: the slow part of a SetPass call is re-uploading material data to the GPU. So the SRP Batcher keeps each material's shader constants in a persistent CBUFFER that lives on the GPU and doesn't get re-uploaded every frame. As long as consecutive objects use the same shader variant, the CPU skips the expensive material re-bind and just points the GPU at the right buffer offset — a much cheaper per-object cost.

The critical and often-misunderstood detail: the SRP Batcher batches by shader variant, not by material. A hundred objects using a hundred different materials that all share one shader still batch beautifully — they differ only in the values sitting in that persistent buffer. What breaks the batch is a different shader, because that forces a real state change.

You don't enable the SRP Batcher per object — it's on by default in the URP asset. Your job is to not break it: keep to compatible shaders, and prefer many materials sharing few shaders over many distinct shaders. This is the single biggest rendering-performance lever in a typical URP project, and it costs you nothing but discipline.

GPU Instancing

When you have lots of the same thing — 500 identical trees, a swarm of identical bullets, a field of grass — GPU Instancing beats even the SRP Batcher. It draws every copy of one mesh + one material in a single instanced draw call, handing the GPU an array of per-instance data (each copy's transform, and optionally colour or other properties) that the shader reads to place and tint each instance.

To use it in the traditional way: tick Enable GPU Instancing on the material, ensure every instance shares that mesh and material, and vary per-instance data through a MaterialPropertyBlock (which — importantly — does not create a new material instance and so doesn't break instancing). The most direct API is Graphics.RenderMeshInstanced / DrawMeshInstanced, where you supply the transforms yourself:

using UnityEngine;

public class InstancedField : MonoBehaviour
{
    [SerializeField] Mesh _mesh;
    [SerializeField] Material _material;   // "Enable GPU Instancing" ticked

    Matrix4x4[] _matrices = new Matrix4x4[1023]; // max 1023 per batch
    MaterialPropertyBlock _mpb;

    void Start()
    {
        _mpb = new MaterialPropertyBlock();
        var colors = new Vector4[1023];
        for (int i = 0; i < _matrices.Length; i++)
        {
            Vector3 pos = new Vector3(i % 32, 0, i / 32) * 1.5f;
            _matrices[i] = Matrix4x4.TRS(pos, Quaternion.identity, Vector3.one);
            colors[i] = Random.ColorHSV();
        }
        _mpb.SetVectorArray("_BaseColor", colors); // per-instance color, one buffer
    }

    void Update()
    {
        // One instanced draw for up to 1023 copies — not 1023 draw calls.
        var rp = new RenderParams(_material) { matProps = _mpb };
        Graphics.RenderMeshInstanced(rp, _mesh, 0, _matrices);
    }
}

Static & the Death of Dynamic Batching

Two older systems remain worth knowing:

• Static batching — for objects marked Static that never move, Unity pre-combines their meshes into a shared buffer at build/load time. They still need the same material to batch the draws, but the geometry is merged once so the CPU submits far fewer, larger draws. It trades memory (the combined mesh) for CPU time, and it's a solid win for immovable level geometry.
• Legacy dynamic batching — an old system that merged small moving meshes on the CPU every frame. It was always limited (roughly < 300 vertices, same material) and its per-frame CPU merging cost often exceeded the savings. In modern URP with the SRP Batcher and instancing doing a better job, dynamic batching is largely deprecated and off by default — you'll rarely, if ever, turn it on. Mention it only to recognize it in old projects and tutorials.

🔎 The modern hierarchy. Reach for tools in this order: keep shaders SRP-Batcher-compatible (free, broad), mark immovable geometry Static (cheap win), use GPU Instancing for many identical objects, and — new in Unity 6 — turn on the GPU Resident Drawer for large instanced/static worlds. Legacy dynamic batching sits at the bottom of the list, usually untouched.

The GPU Resident Drawer

Unity 6 introduces the GPU Resident Drawer, a GPU-driven rendering path that pushes the work of culling and draw submission off the CPU and onto the GPU. Instead of the CPU walking every renderer each frame to decide what's visible and issue draws, the GPU Resident Drawer uploads the scene's instance data once and lets the GPU cull and draw it — dramatically cutting the CPU render-thread cost for scenes with many static or instanced objects.

It's built on BatchRendererGroup (BRG), the low-level API that also powers Entities Graphics (the system that rendered the 25,600 entities you saw in the Module 4 gold lesson). BRG lets code hand the renderer big batches of instances with GPU-resident data; the GPU Resident Drawer is Unity wiring that API up automatically for your normal MeshRenderer-based scene.

You enable it in the URP Asset → Rendering → GPU Resident Drawer (set it to Instanced Drawing), with a companion setting for GPU occlusion culling. Objects must use SRP-Batcher-compatible shaders (there's the SRP Batcher again as the foundation) and be eligible (typically static or non-deforming). Turn it on for a dense scene and watch the Rendering module's CPU render cost fall as the GPU takes over the bookkeeping.

Diagnosing with the Frame Debugger

You can't optimize batching you can't see. Two tools tell you the truth:

• The Rendering profiler module (Lesson 2.1) gives you the running counts: SetPass calls, Draw calls, and Batches. Watch SetPass calls in particular — if it's in the thousands, you have a batching problem worth chasing.
• The Frame Debugger (Window → Analysis → Frame Debugger) is the microscope. Click Enable and it freezes a frame and lists every draw event in order, letting you step through them one at a time and watch the frame build up on screen. For each event it shows what was drawn, with which shader and material, and — crucially — why the previous batch broke ("Objects have different materials," "different shader keywords," and so on).

That "why the batch broke" text is gold. It turns batching from guesswork into a checklist: the Frame Debugger names the exact reason two objects didn't batch, you fix that reason (share the shader, use a property block instead of a material variant, mark it static), and you re-check the SetPass count. That loop — read the count, find the break, fix the cause, re-measure — is precisely the workflow you'll run in the Lesson 2.5 mini-project on the over-materialed stress scene.

Hands-on Challenge

Summary

🚀 What's Next?

You've now met every pillar of performance work in this module: measuring with the Profiler, hunting memory leaks, killing garbage, and collapsing draw calls. Time to use them together on something deliberately broken. In Lesson 2.5: Profiling & Fixing a Stress Scene, you'll profile a slow scene, find three concrete problems — per-frame allocations, hundreds of unbatched materials, and an expensive per-frame scene query — fix each, and re-measure with before/after numbers.