FSR3 Frame Generation and GPU Busy metric?

[velocity7]

See images attached below, GPU busy metric suddenly shows an "improvement" when frame generation is active, which I highly doubt is actually happening. Most likely needs investigation to confirm this is actual behavior internally.

Personally, I expected GPU busy to remain at 13 ms for both samples, while frame time ends up lower than GPU busy. It sounds confusing, but would have made more sense for this scenario.

[JeffersonMontgomery-Intel]

Currently, PresentMon isn't able to distinguish between app-rendered frames and driver-generated frames. I suspect what is happening is that they are getting averaged together and, because generated frames have lower GPU cost, the overall per-frame GPU cost is lower.

We're working on better support for this case in the future.

It's also possible there's something else going on. I can take a closer look but it would help if you can provide a ETL capture as described here: https://github.com/GameTechDev/PresentMon/blob/main/CONTRIBUTING.md#if-there-is-something-wrong-with-the-data-presentmon-is-reporting ?

[velocity7]

@JeffersonMontgomery-Intel I can't upload 7z to GitHub, so I've linked it here instead.

EDIT: Removed link as Jefferson has the ETL file now.

[JeffersonMontgomery-Intel]

Thanks, downloaded it and looks good. I'll take a closer look.

[AlexUnwinder]

FSR3 frametime is also confusing most of users. AMD documented that their frame generation implementation may present generated frames immediately before real ones:

https://gpuopen.com/fsr3-in-games-technical-details/

So "extremely short frame" - "long frame" - "extremely short frame" - "long frame" pattern and jigsaw/zig-zag is expected to be observed on raw present-to-present timing graphs and averaged present-to-present timings are expected to be lower. Also, if you try to display raw value with some fixed refresh interval, most of time you'll display timing for extremely short frames.