Editor Stats acting up

[RedBiltong]

Hey guys,

I’ve noticed something really weird with the Unity 5 Beta12. For some odd reason, I get double (or triple) draw calls and triangles in the editor stats (see the below screenshot)

Above is Unity 5b12 with standard shader with no texture and below is Unity4 with bumped diffuse no texture. Check the attached screenshots for more detail. Is this meant to be normal?

Here are my specs
Unity5 b12
ATI 7950
Win 7

[sui0528]

And the draw call count and saved by batching count are not correct. I have do batching, in U4 the statistics is correct, But In U5, they are wrong.

[RedBiltong]

I am wondering if this is due to the new standard shader or so…it really makes the whole system not worthy when statistics are not giving off correct figures…

[sui0528]

I dont think so, the new standard shader is not used in my scene, and even it does, the statistics is wrong. I use U5 b12, but the bug is still there.

[RedBiltong]

still getting the same stats on U5b13

[sui0528]

Why? If the stats is wrong, how can I figure out the performance of my game?

[PiAnkh]

I have seen the same thing. I have a mesh that fulfills the conditions for dynamic batching. In U4 it worked fine and each new instance of the mesh increased the number of “draw calls saved by batching” but did not increase the actual draw call count. In U5 with the same mesh, each instance increases the number of draw calls by one and the number of draw calls saved by 2. Very strange behaviour. Perhaps the implementation of dynamic batching has changed or perhaps it is as simple as sui0528 says and the stats are broken.

A comment from the Unity team would be very welcome!!

[JohannesL]

tl;dr: The stats are, while technically correct, quite misleading, and are fixed in b14.

Static batching works quite differently in 5.0 than it did in 4.5, and it now generates a lot more draw calls, but super-fast ones. The stats weren’t updated to reflect this, that has only recently been done in b14.

For the technical details, let me paste an email that was sent to the beta mailing list:

_A bit of background:_The goal of the static batching is to regroup as many meshes in less buffers to get better performance, rendering giant meshes instead of a lot of small meshes which is inefficient.
The tricky part is how to handle the rendering of these big meshes using frustum culling. If only few triangles of a big mesh are visible, then submitting that entire big mesh to the GPU is a massive GPU overhead.

4.6 and 5.0 have very different solutions for handling interaction of static batching with frustum culling:- In Unity 4.6, for each frame we would regenerate the index buffer to build a list of the sub-meshes to render in a single draw call. This implied transferring a significant amount of data (the entire index buffer) per frame which explains why static batching was not always the best approach to use.

• In Unity 5.0, we build only once the index buffer on start and we submit a draw call for each sub mesh of that big mesh for each visible sub mesh.

A possible reaction could be: “but a draw call is expensive”. It’s not. Using a synthetic test we can see that it’s possible to submit 800 000 draws per frame at 60Hz on NVIDIA Kepler, 300 000 on AMD Southern Islands for example. The expensive part is to change the resources accessed by the GPU between draw calls because it triggers a graphics driver validation each time. Using 5.0 approach, we only loop on the same resources to render different ranges of these resources. Effectively we execute a series of fast draw calls for each staticcally batched mesh.

Currently, the Unity 5.0 stats window reflects what we do:
Draw calls: %d Saved by batching %d

Where “draw calls” is the effective number of draw call we submit to the GPU and “Saved by batching” only reflect the number of “draw calls” saved by dynamic batching while in 4.6 it also included the number of “draw calls” saved by static batching but this is not longer the case. It’s confusing considering Unity legacy. Also, the current stat window doesn’t reflect the effect of static batching anymore. It seems that dynamic batching has a benefit but static batching doesn’t while actually static batching should always have a great benefit in 5.0 over dynamic batching. Finally, “draw calls” is a wrong unit to think about optimization in 5.0 in the sense that reducing the number of draw call per frame doesn’t mean greater performance and actually it could mean the contrary.

I hope this brought some clarification:)

[PiAnkh]

Thanks JohannesL. That helps a lot !!!

[sui0528]

Thanks JohannesL. But want to know further than you talked about the DP is not important in the NVIDIA & AMD GPU, how about the mobile GPU, the POWERVR, the adreno, the mali?

[sui0528]

And I will be very happy if you can tell that the DP buget on mobile device.