Feedback Expose Statistics API

Update:
This is now possible in Unity 2020.2, thank you for implementing it!
https://unity.com/releases/2020-2/programmer-tools#profiler-updates

The Game View features the Statistics Overlay, which displays batches, triangle count, Shadow Casters, SetPass Calls and so on.

Spoiler: Screenshot

Having access to this information in a (development) build, outside editor, would be extremely useful.

I want to have this in a build, because we run performance tests, where the build is started in a special mode that loads every level, places the camera at specific positions, measures the performance and collects those results for me to look at.

It would be very useful to include the "Render Statistics" in this report as well, because this would allow us to automatically detect whether a specific part in the game issues too many SetPass Calls for example.

Having this information available in a development build is helpful for the QA- and Art-department as well.

I believe a build (in development mode) does track these statistics already, since if I attach a Profiler, I can see the Render Statistics.

Would it be possible to expose the "Render Statistics" to be accessible in a build. Basically everything that is displayed in the Game View Overlay exposed to the Profiler API for example, which already contains various "GetMemory" API's.

I asked this question a few years ago already (see here).

 

Hi Martin,

thanks for your answer! The following text describes how we used to worked in a previous company...

When starting a new project, we usually defined performance budgets via Trial&Error on a particular platform. Finding out how many Render-State changes, Vertices, and so on the hardware can handle before dropping under the frame-rate we have to achieve.

Then we had different automated performance tests, some of these were continuous integration performance tests.

For example, each level had several pre-defined camera positions. The performance test placed the camera at each of these points for a certain time-frame and moved the camera around, for example a slow 360° degree turn around the Y-axis within 30 seconds for a first-person shooter like game.

The test measured the CPU performance during the entire time. At end end of the test, we have a graph similar to the one in this post. The test in the linked post is from my hobby-project though, but the idea is the same, just a simpler implementation in my hobby-project.

If we could also measure other statistics beside "Framerate", it would allow us to automatically detect what's most likely the issue for the frame-rate drop in a certain camera view.

For example, if one of these camera positions drops below 30 fps and we detect there were 10x the amount of vertices than our budget allows, it immediately gives a clue where to look in order to fix it. This allows non-programmers to understand where to look for performance issues. Also simple things like "are we CPU or GPU bound" is really useful to have.

If the performance test generates a text like:
Level "Harbour" camera position "Region 4" (Rotation=0,54,0) dropped to 20 fps, pushing 10000000 vertices more than in our budget.

... can be understood by non-programmers as well, for example by level builders. Especially if he/she just worked in this area and the test runs after he/she pushed the changes, then after the test "failed" generates an email with this text and sends it to him/her or a selected group of people.

Because we couldn't generate this detailed information why a performance test failed, a programmer needed to investigate always.

EDIT: We also had a "performance overlay" in the game that we could activate at any time. It displayed CPU ms, Memory consumption, etc. Adding more detail to this would also allow situation like this:
Inhouse QA tests game. Comes into a region that drops to 10 fps. Checks Performance Overlay. See's 100000 Draw-Calls. Moves over to level design "Didn't you add more items to this region yesterday? Yes I did, looks great right? It sure does, but maybe you placed a little too many objects. I'll create you a ticket". It's also something that will move work away from a programmer.

I hope this clears things up, otherwise please let me.

Edit2: something like "gc allocs per frame" would be nice too.

 

I'm here looking for this as well. It would be extremely useful in VR, as I am constantly looking around a scene, taking the HMD off to look at the computer monitor to check the stats. Its current implementation is incredibly tedious for VR development.

 

@alexeyzakharov
Is this still on your list? I'm asking, because I brought it up about 2.5 years ago and at that time you replied "We had this in plans".

 

That's great news! Thanks for your reply!

 

Adding my vote to this, I was recently writing a custom SRP and would like to make runtime troubleshooting easier for our members, so far I only managed to extract active lights and reflection probe count from SRP.

I would love to see Drawcall, Shadow Caster, Renderer and even Tris count exposed in some ways.

 

I couldn't find information how I would get the "Draw Calls" for example. I found this:

ProfilerRecorder.StartNew(ProfilerCategory.Render, "SetPass Calls Count");

I wonder what the "SetPass Calls Count" is. The docs say "Profiler marker or counter name", but is this a hard-coded identifier that I use to retrieve the actual "set pass calls", or is it just a name I specify myself to display it in an UI for example?

I couldn't find a listing of all available "Profiler marker or counter name" items if that's a hard-coded identifier.

 

Probably because I was looking at the Scripting API documentation and not the manual.

OK, so the names are hard-coded id's basically. Can you add a static class that contains all the names? Using hard-coded strings everywhere is error prone from an usage point of view and having that class basically provides documentation for free through code-completion.

It also gets rid of the problem when you suddenly rename an internal string, which occurred multiple times with those hard-coded platform id's one has to pass to various texture import API's. It falls apart quite easily.

Code (CSharp):

1. static class ProfilerIds
2. {
3.     public const string drawCallsCount = "Draw Calls Count";
4.  
5.     // and so on...
6. }

 

It looks like this has landed in Unity 2020.2
https://unity.com/releases/2020-2/programmer-tools#profiler-updates

Thank you @alexeyzakharov @MartinTilo and the rest of the gang!

 

Is there a way to get the time taken by the render thread ?

 

Thanks