EPC vs FPC vs Tick Timers

Hi, I’ve posted this question here (Understand Nsight report - Nsight Visual Studio Edition - NVIDIA Developer Forums) as well, but considering that didn’t update to top of list, figured I’d start a new question as well:

Based on the explanation of FPC and EPC, I’d imagine in a real world scenario the FPC number would be the correct number? However, if I use just tick timers (like D3D11Query) for e.g., some draw calls would have tick timer numbers equivalent to FPC while others would have times corresponding to EPC. I would imagine regular tick timers should always equal FPC. But summing all the times seem to be accurate for timers, but not for FPC. I guess my question is when do I trust what? EPC? FPC? regular tick timers?

Thanks

I’m also very interested by this topic.
It seems that Nsight is intended for people that wants to develop a feature like AO and be able to profile by iterate their code and see improvement. Therefor, being able to see the real timing of your frame isn’t clear at the moment. FPC seems to be their solution, but on our side we never get any success at using it (timing given are most of the time extremely off with huge gap between batches --see attached).

The Empty pipeline cost shown in the scrubber isn’t representing what a common user is expecting (a timing that fits the speed of your application). The contention and parallelism are not consider in EPC. It is good for itering on a specific feature, but not at a profiling stand of view.

I would like that the scrubber is able to show both EPC and something that represent the real timing of your GPU (If FPC is the answer, I would like to see it working.

Since two years that we’re using Nsight intensivly on our project, we never saw the frame timing to work. Always those big gaps and odd timing. For instance, when our application it stating that our GPU runs at 21ms, the frame timing in FPC is telling 98ms). Early in production we were using Unity engine and it was the same issue.

I suggest reading this post made by our technical programmer director, a few month ago: https://devtalk.nvidia.com/default/topic/871488/?comment=4656396

We love the mindset behing this tool. We’re just hoping that the profiling part of the tool becomes more obvious.

Regards

Joining file wasn’t working (it was on “scanning” state forever). Here is a pick. The FPC is speaking about 68ms while our frame was running at around 35ms.
We did lots and lots of captures at the same spot. Obviously values are changing a bit but remain in the same odd range… Sometime it shows crazy 120ms and over while our game was running at something around 40ms (GPU wasn’t spiking, using the command “stat raw” in ue4 we can see if the gpu is even or not). That glitch in the Frame Timing was there also when we were using Unity engine 4, 3 years before, so for us, the Frame Timing has been always broken and useless (unfortunately! because it is the real frame profiler). The big blank gaps can be easily spotted in this pic.

External Media

Here is a serialized frame that shows the issue (AYan password has been sent in your private msg)

[url]https://drive.google.com/open?id=0B7Sdp2LiO5WCeDU4eEdhanUtbnM[/url]

Here are both the frametimings and frameprofiler data:

[url]https://drive.google.com/open?id=0B7Sdp2LiO5WCYUljaW1PNHRvTms[/url]

Hello
I m also interested at getting a reliable FPC in the frame timings
Thanks