Why does the drawcall numbers in framedebugger is different then numbers in RenderDoc?

Hello,

I am trying to get the exact drawcall numbers on my phone. I tried unity's framedebugger and Renderdoc. However, RenderDoc showed 160+ drawcalls and framedebugger only showed 63 drawcalls.

Which tools should I trust in?

 

RenderDoc is more accurate. You use urp or standard?

 

I use URP

 

Unity doesn’t count draw calls, it counts set pass calls. RenderDoc lists draw calls. The reason is draw calls aren’t always what’s expensive. For example static batches are combined into single big meshes, but each game object is still rendered individually via draw calls that only render the range of triangles that are that original mesh. This means you can enable or disable individual game objects, and Unity can sort and cull them for better rendering performance. But because it’s really just drawing the same mesh & material over and over each draw call isn’t expensive. What was expensive was setting the mesh and material to start with.

But RenderDoc shows each individual draw call.

 

Thank you, Is there any document can explain Static Batch in detail? From Unity's document, I just have a basic concept that Unity help us to create a big mesh. However, from what you said, "each game object is still rendered individually via draw calls that only render the range of triangles that are that original mesh". This part is like a black-box to me.

Also, from my expectation, Unity3d should sort renderer according to their materials to maximize the profit of static batching. However, I made some test and found Unity still prefer to render things close to camera first and sometimes it will break batching. It makes some sense on PC platform. But on mobile platform, due to the TBDR, overdraw is eliminiated signicificantly. Should I render things shared with same material to maximize the profit of static batching?

 

AFAIK Unity disables depth sorting for opaque objects on mobile GPUs that use TBDR. There are certainly other threads on the forum that actually complain about this and have implemented custom depth sorting because it can still be a performance benefit. Likely because the per tile coverage pass still suffers from “over shading” like performance slow downs in extreme cases.

That said, Unity breaks up static batches for all sorts of reasons. But unfortunately it is a black box. Unity does not document its C++ internals.