Are Graphics.DrawMeshInstanced or Graphics.DrawProcedural or other draw methods SRP Batching* Compatible?

I have multiple meshes which are with same shader but different materials. These are rendered through instancing via Graphics.DrawProcedural method.

As the calls are done in Update, I expect them not immediately pushed for drawing. So, wondering if they are queued, and considered internally by the SRP batcher or not.

The reason for worrying if they are SRP batched or not is because, I need to decide on a workflow where I need to make a texture atlas with a single material or have multiple materials with same shader so that it reduces the setpass calls which are considerably more expensive compared to draw calls.

AFAIK these calls are not going through batching.
You can use the Frame Debugger to double-check this.

Yes, DrawMeshInstanced is SRP-compatible, but it bypasses the SRP Batcher and doesn’t benefit from its optimizations. The SRP Batcher can handle many different materials efficiently as long as they share the same SRP-Batcher-compatible shader. But it doesn’t support Material Property Blocks.

If you need custom properties per object (e.g., different colors for each instance), GPU instancing can actually be slower than SRP Batcher, which handles such variations more efficiently by minimizing state changes.

For scenes with high instancing potential, you could also consider the GPU Resident Drawer for non-DOTS projects (Unity 6) or BatchRendererGroup (BRG) if you’re using ECS/DOTS. Both might offer better scalability and performance by leveraging GPU-side processing.

I did a quick test with DrawPrimitives and DrawMeshInstanced. While the shader is SRP Compatible(in inspector), Frame debugger shows “Node is not SRP Compatible”.

I will do more tests and get back with an update.

Surprising to know SRP Batcher leads compared to GPU instancing!

Haven’t tried resident drawer yet but not sure if its fits my usecase.

I have to render thousands of small objects so tried first with creating GraphicBuffers (StructuredBuffers) for passing vertex and triangle data. While it worked fine, found the bottleneck is in GPU (cpu stalls waiting for gpu to finish). I’m guessing this could be due to memory access, so now trying to write data to textures and drop GraphicBuffers.

I see resident drawer expects mesh component, so may be right for bigger meshes.