Official 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.

 

Hi there, thanks for the detailed update! Curious as to whether being unable to capture GPU timing states from WebGL targets is likely to ever be possible? Is it just an inherent limitation from way in which it's run in browser?

 

The example code on the blog doesnt compile.

Code (CSharp):

1. static PerformanceBottleneck DetermineBottleneck(FrameTimeSample s)
2.  

FrameTimeSample Doesnt exist.

 

How can one get gpu frame time on directx 11 in 2021 lts? Dx12 is not in a usable state on PC, and without it I see no way to dynamically tune performance.

 

I'll add one more question here for clarification:
FTM only works in 2022.1.0a13 and later versions, ok. But 2021.3 still has the flag in Player Settings to enable Frame Timing Stats gathering (and the FrameTimingManager API that returns nothing of value...). Will enabling this setting cause overhead even though FTM API isn't even usable in 2021.3? If so, I feel like this is a pretty big flaw in 2021.3 and the option should be removed and forced off.

 

The screen at the bottom of the post looks like what I want. However, where do I find it?

 

FrameTimingManager still not working for me.
windows, dx11. neither editor nor on a build. (dev build).
enabled frame time stats.
updated unity to latest 2021.3.18f

still the same.
FrameTimingManager.GetLatestTimings(...) always returns 0 and does not give any data.

Even the FrameTimingsHUDDisplay sample does not work. same issue.

note that SystemInfo.supportsGpuRecorder returns true.

also tried the ProfilerRecorder:
GPURecorder = ProfilerRecorder.StartNew(ProfilerCategory.Internal, "GPU Frame Time (ms)", 100, ProfilerRecorderOptions.GpuRecorder| ProfilerRecorderOptions.SumAllSamplesInFrame);

its always Invalid and returns 0 values.

when i open the profiler i see GPU and CPU timings. its just that i want to view them like a FPS counter in realtime in game.

Am i doing something wrong? is the FrameTimingManager removed/disabled for dx 11 in 2021.3.18f?
if so which version should i downgrade to have it working?

 

As stated above by @antonk-unity : FrameTimingManager only produces usable data in Unity 2022.1.0a13 and later versions.

Unity 2021.3.x seems to be some kind of forgotten child that has the API exposed but doesn't know what to do with it

 

Hi what happened to FullFrameTime? This is a property used in the blogpost, but this doesnt appear to be available anymore?

 

Sorry my bad, the blogpost uses `FullFrameTime`. What is the newer equivalent? I'm unsure how to upgrade the bottleneck detection you posted on the blog.

 

Is this available in 2021.3? When I try:
if (FrameTimingManager.GetCpuTimerFrequency() == 0 || FrameTimingManager.GetGpuTimerFrequency() == 0)

In 2021.3 / HDRP / OpenXR its always 0. I was hoping to enable DSR.

 

So basically Dynamic Resolution Scaling is not possible in 2021.3?

 

I'm seeing this weird behavior on Android.
In an empty test scene, the average GPU frame time remains roughly around 3.5ms at any FPS below 60 (I tested 5, 10, 15, 20 & 30). At 60 FPS, the GPU frame time jumps up to 10ms.

Could it be device specific? I tested it on a different Samsung device as well and the behavior was very similar but a bit delayed.

Unity 23.1.2f1 - Graphics API Vulkan

 

That makes a lot of sense. This actually explains why the newer device took some time before thermal throttling the GPU.
Thank you. I will profile with Arm Mobile Studio (and other tools mentioned in ultimate profiling guide) for a more detailed analysis if the need arises.

 

I might be being really stupid, but on DX11/DX12, the frametiming stuff works wonderfully in editor, but not in a Windows build. I ticked the box under Player settings. Why is everything coming back as 0? 2022.3.3f1.

 

Google shows this page for many GPU profiling queries. Can you please elaborate on how to open this window, or at least point to a page that explains it?

 

Is it possible to get the gpuFrameTime on Quest 2 using OpenGLES3 and OpenXR?

This post might hint that it's not supported yet?

 

Can somebody help me understand the values a bit better. I have tested a build on a Samsung S10 (OpenGLES3). It's running at 60fps. Frame time is 16ms, as expected. CPU time is 11ms which is understandable. GPU frame time is reported as 20ms. How can that be explained? As far as I understood this thread, only Metal could potentially report a higher GPU time than general frame time. Am I missing something? (2022.2.17, URP 14.0.7)

 

If it's only available in 2022 why is it in the documentation for 2021. With examples. This is just wasting people's time.

 

If you're on Unity 2021, what options do you have for getting GPU frame timings?