Update for Frame Timing Manager

[MartinTilo]

Not on all platforms via FrameTimingManager. There may be workarounds with costum heuristics and e.g. native plugins to get some platform specific counters to make up for the lack of FTM. I.e. not trivially and in general, no.

[shihab37]

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

[MartinTilo]

I feel like that’s not really a FrameTimingManager thing but something you should check out with a platform specific profiler, like one from your specific device’s GPU Manufacturer/Designer(e.g. Arm Mobile Studio), for more concrete confirmation, but: Mobile devices have a limited power budget and they have heat build-ups to consider. So the higher the FPS, the more power will be needed by both the CPU and the GPU and more of that at the same time, as there is less idle time on the CPU. The screen may also need extra power for that. All of that means that less power is available at any point in the frame time, more heat is building up and the device is likely to down-clock the GPU as a consequence

[shihab37]

@MartinTilo

Mobile devices have a limited power budget and they have heat build-ups to consider. So the higher the FPS, the more power will be needed by both the CPU and the GPU and more of that at the same time, as there is less idle time on the CPU. The screen may also need extra power for that. All of that means that less power is available at any point in the frame time, more heat is building up and the device is likely to down-clock the GPU as a consequence

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.

[djarcas]

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.

[morepixels]

@antonk-unity

FrameTimingManager

The FrameTimingManager enables you to capture and access frame timing data for multiple frames. Frame timing data includes timestamps for different phases of the frame and the duration of work done on the main and render threads. You can use this information to make adjustments to your application where performance is below your target level.

The FrameTimingManager isn’t enabled by default. To enable this feature, go to Edit > Project Settings > Player and enable the Frame Timing Stats checkbox.

Note: Enabling Frame Timing Manager has a noticeable performance impact.
Note that FrameTimingManager is a part of Dynamic Resolution feature and is required to be enabled for it to work.

What’s changed

• Added support for DirectX 11
• GPU time measurements now work in Editor too for most platforms
• Added Main Thread Central Processing Unit (CPU) Frame time
• Added Main Thread CPU Present Wait time
• Added Render Thread CPU Frame time
• Added First Submit timestamp
• Added Frame Start timestamp
• Exposed “CPU Total Frame Time” profiler counter
• Exposed “CPU Main Thread Frame Time” profiler counter
• Exposed “CPU Render Thread Frame Time” profiler counter
• Exposed “Graphics Processing Unit (GPU) Frame Time” profiler counter

More details on each added field are provided below in “Measurements” section.

Measurements
The FrameTimingManager measures a set of important time metrics of a frame, including the following:

• cpuFrameTime - the total CPU frame time calculated as the time between the ends of two frames, which includes all waiting time and overheads, in ms.
• cpuMainThreadFrameTime - the total time between the start of the frame and the time when the Main Thread finished the job, in ms.
• cpuRenderThreadFrameTime - The time between the start of the work on the Render Thread and when the Present() function was called, in ms.
• cpuMainThreadPresentWaitTime - The CPU time spent in waiting for Present() during the last frame, in ms
• gpuFrameTime - The GPU time for a given frame, in ms.
• frameStartTimestamp - The CPU clock time when the frame was started.
• firstSubmitTimestamp - The CPU clock time when the first job was submitted to the GPU.
• cpuTimePresentCalled - The CPU clock time at the point Present() was called for the current frame.
• cpuTimeFrameComplete - The CPU clock time at the point when the GPU finished rendering the frame and interrupted the CPU.

The following diagram explains how each measured time and timestamp maps to a frame.

Important notes:

• The FrameTimingManager produces results with a fixed delay of four frames because GPU timing results aren’t available immediately.
• Frame Timing Manager doesn’t guarantee that the GPU has time available. The GPU might fail to return results in time, or might fail to return any results at all. In these cases, the gpuFrameTime is reported as zero.
• On platforms that don’t allow GPU timestamping, Unity computes the FrameCompleteTime value rather than measure it. Unity computes FrameCompleteTime as FirstSubmitTimestamp + GPU Time. If the GPU fails to provide GPU time, FrameCompleteTime is automatically set to be equal to Present Timestamp.
• On GPUs which use tile-based deferred rendering architecture (such as mobile platforms), results are less precise because GPU execution is deferred and the execution of rendering phases might be done separately. The FrameTimingManager can only measure overall duration.

Profiler Counters
Instead of the FrameTimingManager C# API, you can read FrameTimingManager values using the ProfilerRecorder API. The benefit of the ProfilerRecorder API is that the FrameTimingManager measurements are only taken when you attach a recorder to the counter and you have control over potential overhead.

using Unity.Profiling;
using UnityEngine;

public class ExampleScript : MonoBehaviour
{
    string statsText;
    ProfilerRecorder mainThreadTimeRecorder;

    void OnEnable()
    {
        mainThreadTimeRecorder = ProfilerRecorder.StartNew(ProfilerCategory.Internal, "CPU Main Thread Frame Time");
    }

    void OnDisable()
    {
        mainThreadTimeRecorder.Dispose();
    }

    void Update()
    {
        var frameTime = mainThreadTimeRecorder.LastValue;
        // Your code logic here
    }
}

Setup
FrameTimingManager is available for Development and Release Unity players. In the Development player, the FrameTimingManager is always enabled.

In a Release player, you must enable the FrameTimingManager in the Player Settings. To do this, go to Edit > Project Settings > Player and enable the Frame Timing Stats checkbox.

Platform support

Metal
In some cases, under heavy load or GPU pipeline saturation, reported GPU Time might be bigger than the reported frame time while using the Metal API. For example, reported GPU time might be 40ms with stable 50fps with which you would expect GPU time can’t be higher than 20ms.

Why does it happen? The Metal API allows us to measure time at the beginning and end of command buffer execution, which in Unity case near matches frame boundaries. Since tile-based deferred rendering architecture GPUs execute rendering in phases (jobs) instead of doing it immediately, there might be a gap between the execution of different phases depending on GPU resource availability. For example, if the GPU is under a high load, there might be a gap when a job is passed from the Vertex queue to the Fragment queue inside the GPU. That results in the situation when jobs activity time (which defines the frame rate) and the total measured wall clock time are significantly different.

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?

[tcmicka]

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

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

[thomas-soba]

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)

[paulatwarp]

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

[paulatwarp]

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

[alexeyzakharov]

@paulatwarp

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

Sorry for this - as a part of Dynamic Resolution feature we only supported on 2021 iOS
, macOS and tvOS (Metal only), Android (Vulkan only), Windows Standalone (DirectX 12 only), and UWP (DirectX 12 only). We’ve extended support to almost all platforms it in 2022, but it required changes that could destabilize 2021, so we didn’t backport those changes to 2021.

@paulatwarp

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

One option you may be able to use depending on the platform is native graphics plugin API - https://docs.unity3d.com/2021.3/Documentation/Manual/NativePluginInterface.html
It should be possible to obtain the render device and use it to issue timestamps/timerqueries at a certain point of frame and collect later.

[paulatwarp]

It turns out it does work for my platform in 2021.3 , just not in the editor.

[Xaron]

Funny. For me it works in the editor and standalone development builds but NOT in standalone release builds.
Unity 2021.3.22f1

[MartinTilo]

@Xaron

Unity 2021.3.22f1

The improvements mentioned in this thread landed on 2022.1.0a14

@antonk-unity

Yes, unfortunately, it hasn’t made it to 2022.1.0a13 for some reason.
Any public alpha after that should have it available.

[Xaron]

Thank you! Understandable.

[peterc-neq]

Hi, I was wondering if you could help.

I am using Unity 2022.3.14f1.

I have a script that collects profiling data using ProfileRecorders with the Time Manager Manager enabled over 60 frames. However the data I am collecting seems quite inconsistent and it would be great to get some clarification on what I am seeing.

The stats I am collecting are :-

“CPU Total Frame Time”
“CPU Main Thread Frame Time”
“CPU Render Thread Frame Time”
“GPU Frame Time”
“Main Thread”
“PlayerLoop”

The problem I am seeing is that “CPU Total Frame Time”, “CPU Main Thread Frame Time”, “Main Thread” and “PlayerLoop” stats seem quite inconsistent, for example on one frame “CPU Total Frame Time” is the slower value where as on another “CPU Main Thread Frame Time” is slower and another the “PlayerLoop” stat is slower.

I would expect that there should be a stat that is consistently the slowest stat, that stat shows the time the whole frame takes on the CPU(including waiting for other threads to sync with the main thread).

Any information on this would be of great help.

[MartinTilo]

For others following along, the above has been answered in this thread .

[chrismarch_1]

This ProfilerRecorder returns zeroes in non-Development Build iOS players, but works fine in Development Build iOS players, and in Unity Editor regardless of the Development Build setting. I am intentionally not setting the project setting to enable the FrameTimingManager in all builds, as the only release builds we want it enabled in are internal.
“CPU Main Thread Frame Time” and “CPU Render Thread Frame Time” ProfilerRecorders do not have this inconsistency. (2022.3.23f1, URP 14.0.10)

m_gpuRecorder = ProfilerRecorder.StartNew(ProfilerCategory.Internal, "GPU Frame Time");

[MartinTilo]

@chrismarch_1 thanks to you we noticed the examples here and in the documentation have not been updated to reflect the fact that these counters don’t belong to the Internal category but to the Rendering one. That was a late change to the code when the examples were already written.

I’m not sure that’d fix your issue but I didn’t get to test that theory. I’m on PTO for the next week and didn’t want to leave you hanging for too long though. If you give that a try, please let me know if that worked

[detzt]

Are the stats from the Frame Timing Manager the same as those in the DisplayStats of the URP Rendering Debugger?

(The overlay you can open by double tapping with 3 fingers on mobile or pressing both controller sticks in, see Rendering Debugger reference | Universal RP | 17.0.3).