Update for Frame Timing Manager

sold!

love the amount of low level detail here but, since you know the internals so well, what i'd like to see in the future is pre-chewed metrics in term of pressure. and ideally the total of these numbers = 1
.cpuPressure
.bandwidthPressure
.gpuFillratePressure
.gpuGeometryPressure

no point in scaling down the frame buffer if .gpuGeometryPressure is higher than .gpuFillratePressure
no point in throttling math heavy stuff if .bandwidthPressure is higher than .cpuPressure

 

* "Add FrameTimingManager support to the Advanced FPS Counter" issue AFPS-62 created *

 

Hey @antonk-unity, thanks for bringing such a powerful tooling to our hands!
I'm having a few questions about it.

Could you please share plans on releasing those, which Unity versions are going to get them, as I'm not seeing 'em in the current public alpha yet? ^^

Another question is those new counters' availability in the release builds: do we need to have Frame Timing Stats option enabled + active Camera with enabled Dynamic Resolution in scene in order to read those counters in release players?

And last one: is "CPU Main Thread Frame Time" or "CPU Total Frame Time" going to replace existing "Main Thread" ProfilerRecorder in the Internal Category, or they are calculated differently?

 

Thank you for the detailed reply, @antonk-unity !

That's great to know!
Do you have any plans on back porting it to the 2021 LTS by chance?

Thanks, that's what I hoped to hear ^^

Got it, now I see the difference.

Regarding "Render Thread" marker - it's good to know, I've seen it in the dev builds only, and the new CPU Render Thread counter looks much more interesting to me as it allows gathering data in release builds.

One more possibly confusing marker I've seen in Release builds is Camera.Render from the Render Category.
It's available in Release builds starting from the 2021.1.0f1, and now I wonder if it's something we could use as a fallback instead of Render Thread marker or instead of upcoming "CPU Render Thread Frame Time" counter if user didn't enable Frame Timing Stats option.

 

Totally understandable, but as plugin dev I'm sad about this %)

Got it, thanks!

I'm glad we can enable it at Runtime even if it was disabled in Player Settings, and I'd prefer to keep it so, as this reduces friction and allows straightforward usage scenarios.

Although, to make it more clear for everyone how and when it's used, I'd be glad to discuss these points:
1. Explicit API to activate FrameTimingManager from the code (API just duplicates setting in Player Settings)
2. Prevent FrameTimingManager from working if it wasn't explicitly activated either in Player Settings or through the API (i.e. you'll not get a valid recorder or will always get zero values for "CPU Render Thread Frame Time" and other FrameTimingManager counters unless you activate it through the Player Settings or API call).
3. Add log on FrameTimingManager activation (both when build starts with activated toggle in Player Settings and when explicitly activating it through the API) explaining this system is now active and do introduce overhead.
4. Keep all FrameTimingManager counters always visible in Sampler.GetNames() and ProfilerRecorderHandle.GetAvailable() regardless activation state.

 

Two tiny questions about this:

- will it require passing a

ProfilerRecorderOptions.GpuRecorder

option when starting or creating the

ProfilerRecorder

for this counter?

- will it have a

MarkerFlags.SampleGpu

set in the

ProfilerRecorderDescription.flags

?

Cheers!

 

Thanks, that's clear now.

Now I see how FrameTimingManager is going to make our lives easier =)
Thanks for the warn about FrameTime.GPU, seems to be something new in yet unreleased alpha / beta, as I'm not finding it in 2021.2.2 or 2022.1.0a13 among other available markers (even after 5+ frame delay).

From how I feel the concept, it seems ProfilerCounters are more stable and user-friendly rather than ProfilerMarkers and markers recording is somewhat more risky, kind of "low-level, only when you really know what you're doing".

 

It's here!

2022.1.0a15:

• Profiler: FrameTimingManager platform reach and frame timing information expanded.

 

Hey @antonk-unity ,

I've just gave a spin to the FrameTimingManager update and here is my feedback so far:

1. Yay, new juicy counters are available now in Editor, Dev and Release builds!



2. New counters work in release builds on my hardware, and I like the fact FTM initializes at runtime even with Frame Timing Stats option disabled, hope this "on-demand" initialization will stay or will be replaced with explicit API call to keep it available!

3. While tackling a bit with existing FrameTimingManager C# APIs I noticed it does capture all possible stats and there is no way to capture only few of them. Hence, I wonder if recording only few FTM counters using ProfilerRecorders still captures all possible stats under the hood, or it does captures only those which are recorded?

4. One more kind of confusing part: FTM C# APIs do not allow figuring out how many frames can be captured in the given environment.
From the docs for GetLatestTimings() numFrames argument: "This should be equal to or less than the maximum FrameTimings the platform can capture." but how to figure out how much platform can capture?
Without knowing maximum allowed frames to capture, it seems one of the common scenario would be just passing 1-element array to get the latest frame, so it could be worth adding GetLatestTiming() API to get only 1 last timing capture.

5. I'm seeing strangely high numbers when trying to record "CPU Total Frame Time" and "CPU Main Thread Frame Time" with ProfilerRecorderOptions.CollectOnlyOnCurrentThread option, like 150ms instead of usual 4-5. That seemed strange for me as I expected values from CollectOnlyOnCurrentThread recorder to be lower.

6. Just a minor possible confusion I've spotted: in my test scene, "CPU Main Thread Frame Time" counter and "CPU Render Thread Frame Time" do not match the Game View Stats panel "CPU main" and "render thread" timings and even showing kind of opposite =D



I'm guessing that's because those are calculated way too differently, but similar wording used for counters and stats panel could confuse at the first glance.

 

Thanks for making this clear, looking forward to any news on counters activation separation!

Thank you for the explanation, but it still sounds a bit clunky..

Following your comments, to capture averages from i.e. 100 frames I should:
1. Allocate array of the desired size (100) and pass it along with desired numFrames (100, again).
2. Take a look at how much array slots were actually filled and cap initial 100 value if necessary.
3. Resize initial array if 100 was capped to the lower value.

i.e.:

Code (CSharp):

1. FrameTiming[] reusableFramesData; // class field
2.  
3. void InitFramesData()
4. {
5.     var desiredFrames = 100;
6.     reusableFramesData = new FrameTiming[desiredFrames];
7.     FrameTimingManager.GetLatestTimings(desiredFrames, reusableFramesData);
8.  
9.     var actualFrames = GetFilledItemsCount(reusableFramesData);
10.     if (actualFrames < desiredFrames)
11.         Array.Resize(ref reusableFramesData, actualFrames);
12.  
13.     // can finally use / reuse reusableFramesData
14. }

What would be great to see is an API which just could return numFrames for the current platform, so this could be reduced to:

Code (CSharp):

1. FrameTiming[] reusableFramesData; // class field
2.  
3. void InitFramesData()
4. {
5.     var actualFrames = FrameTimingManager.GetMaxNumFrames();
6.     reusableFramesData = new FrameTiming[actualFrames];
7.     FrameTimingManager.GetLatestTimings(reusableFramesData); // overload with 1 argument, uses passed array size
8.  
9.     // can finally use / reuse reusableFramesData
10. }

Please let me know if I misunderstood something here %)

Sorry that was my bad as I passed

ProfilerRecorderOptions.CollectOnlyOnCurrentThread

instead of

ProfilerRecorderOptions.CollectOnlyOnCurrentThread | ProfilerRecorderOptions.Default

So it works just fine now!

Understood, but that opposite difference from the screenshot is constant, i.e. I always see higher value in FTM's "CPU Render Thread Frame Time" counter comparing to "render thread" from the stats' panel while running my test scene.

That's great to hear, it will eliminate any possible confusion.

 

Hi,
I am trying to take timestamps of frames being display and I thought about using FrameTiming.cpuTimeFrameComplete, it works fine on windows but, on oculus quest (1 and 2) it returns 0. I would like to know if it is a problem with all oculus headsets or in my code and if it will be fixed?
* The build for the oculus is an android build.

The code below attached to the main camera.

Code (CSharp):

1. using System.Collections;
2. using System.Collections.Generic;
3. using TMPro;
4. using UnityEngine;
5. using System.Text;
6.  
7. public class Timing : MonoBehaviour
8. {
9.     public TMP_Text screenText;
10.  
11.     FrameTiming[] frameTimings = new FrameTiming[1];
12.  
13.  
14.  
15.     uint m_frameCount = 0;
16.  
17.     const uint kNumFrameTimings = 2;
18.  
19.  
20.  
21.     // Update is called once per frame
22.     void Update()
23.     {
24.         ++m_frameCount;
25.         if (m_frameCount <= kNumFrameTimings)
26.         {
27.             return;
28.         }
29.         FrameTimingManager.CaptureFrameTimings();
30.         uint res = FrameTimingManager.GetLatestTimings(1, frameTimings);
31.         if (res < 1)
32.         {
33.             UnityEngine.Debug.LogErrorFormat("Skipping frame {0}, didn't get enough frame timings.",
34.                 m_frameCount);
35.             screenText.text = string.Format("error frame {0}",
36.             m_frameCount);
37.  
38.             return;
39.         }
40.  
41.  
42.         screenText.text = string.Format("cpu frame time: {0}\ncpu time frame complete: {1}\ncpu time present called: {2}\ngpu frame time: {3}\nheight scale: {4}\nsync interval: {5} \nwidth scale: {6}\n{7}\n{8}\n{9}\n{10}\n{11}",
43.             frameTimings[0].cpuFrameTime,
44.             frameTimings[0].cpuTimeFrameComplete,
45.             frameTimings[0].cpuTimePresentCalled,
46.             frameTimings[0].gpuFrameTime,
47.             frameTimings[0].heightScale,
48.             frameTimings[0].syncInterval,
49.             frameTimings[0].widthScale,
50.             frameTimings[0].cpuMainThreadFrameTime,
51.             frameTimings[0].cpuRenderThreadFrameTime,
52.             frameTimings[0].cpuMainThreadPresentWaitTime,
53.             frameTimings[0].frameStartTimestamp,
54.             frameTimings[0].firstSubmitTimestamp);
55.     }
56. }
57.  

In addition, is there a way to access the CPU clock time to compare the FrameTiming.cpuTimeFrameComplete with the current time?

 

Ah, that's clear now, thanks!

Still, if it's a low-hanging fruit under the hood (and already calculated or stored somewhere), it would be great to somehow figure out "the maximum FrameTimings the platform can capture" to allocate for FrameTiming[] not more than the platform can actually capture ^^

 

I am a simple man. I want to know the time taken to do work on the cpu (main + render thread) and the time spent by the gpu to present the frame. The end goal is to have a normalized quantity of whether the cpu or the gpu is performing better. How do I get this?

It has been said time and again, but the docs don't actually provide a good example of how to scale dynamic buffers with FrameTimingManager.

 

Hi,

there is a little confusion on our side. We use latest 2021.2, DX11 and the FrameTimeManager just returns zeros (tested on different PCs). Is this a 2022.x feature?

Best regards
Bennet

 

Thanks for the clarification. One further question: You wrote that enabling the Frame Time Manager costs performance. Even if it is not used in code? Is there any way to disable it at runtime? We'd just need it for our Dynamic Resolution system and if someone would disable Dynamic Res in our settings it'd be nice to disable the Frame Time Manager too.

 

Thanks for explanation! That sounds useful. Now we only have to wait for an official 2022.1 release.