gfxrecon-replay: add runtime FPS output

[infapi00]

More than a issue per-se, this is a enhancement suggestion. I could even try to do it myself, but before I would like to know if maintainers find this suggestion reasonable or not.

Commit ee2b86a0 added a FPS output after the replay finished. In order to compute it, it gets the initial timestamp before running the application, and after it. But this time would include the initialization time for the first frame, that usually consumes more time.

I noted that when I found that for some (short) replays I was getting a FPS worse that the real application, when I was expecting better values (as gfx-replay doesn't need to handle user input, AI, etc).

As a reference, this are some values for some replays I have been using for the Raspberry 4. The "mesa overlay avg fps", was computed using the Mesa overlay, that it is a Vulkan layer included on most of the Mesa drivers [1]:

RBDOOM-3-BFG [2]

• gfxrecon avg fps: 9.323337
• mesa overlay avg fps: 13.386148648648648

quake3e: [3]

• gfxrecon avg fps: 61.612574
• mesa overlay avg fps: 62.01526315789474

ue4 shooter demo [4]

• gfxrecon avg fps: 10.494706
• mesa overlay avg fps: 13.985679012345681

The difference is bigger with more complex traces, where the initialization time is bigger.

Note that Im not suggesting to change how FPS is currently computed, as I think the current value is also interesting.

[1] https://gitlab.freedesktop.org/mesa/mesa/tree/master/src/vulkan/overlay-layer

[2] https://github.com/RobertBeckebans/RBDOOM-3-BFG/

[3] https://github.com/ec-/Quake3e

[4] https://docs.unrealengine.com/en-US/Resources/SampleGames/ShooterGame/index.html

[dustin-lunarg]

This seems reasonable to me.

For the current behavior, I think we may also want to make an adjustment for trimmed files such that the initialization performed before the first frame is measured separately. We could report the time elapsed for the initialization, and then report an average FPS for the replay that does not include the first frame initialization time.

[davidd-lunarg]

PR #514 adds additional timings to the final replay output, including FPS computed with and without state load time for trimmed capture files. @infapi00 does the new output help your use case?

Example output with trimmed capture file:

Load time:   9.169655 seconds
Replay time: 13.695819 seconds
Total time:  22.865880 seconds
Replay FPS:  36.580507 fps, 13.695819 seconds, 501 frames, framerange 500-1000
Total FPS:   21.910375 fps, 22.865880 seconds, 501 frames, framerange 500-1000

Example output with complete (not trimmed) capture file:

Total time:  31.102714 seconds
Total FPS:   33.148233 fps, 31.102714 seconds, 1031 frames, framerange 1-1031

[infapi00]

Hi, thanks for working on it

@infapi00 does the new output help your use case?

Yes, that output is what I was looking for, but just a question, why it is not possible to get the "Replay FPS" with complete (not trimmed) capture files?

[davidd-lunarg]

As it is in the PR, the replay time adjusts for the trimmed state load time. For non-trimmed files, there is no trim state to load, so total FPS and replay FPS are the same. Were the files you provided timing for trimmed or complete captures?

The PR has been updated so the FPS are labelled consistently:

Example output with trimmed capture file:

Load time:  1.435010 seconds
Total time: 7.576557 seconds
Replay FPS: 285.107319 fps, 6.141547 seconds, 1751 frames, framerange 250-2000

Example output with complete (not trimmed) capture file:

Total time: 6.758087 seconds
Replay FPS: 254.361922 fps, 6.758087 seconds, 1719 frames, framerange 1-1719

[infapi00]

As it is in the PR, the replay time adjusts for the trimmed state load time. For non-trimmed files, there is no trim state to load, so total FPS and replay FPS are the same.

Ok, I was asking as I assumed that there were some loading even for non-trimmed files. Thanks for the explanation.

Were the files you provided timing for trimmed or complete captures?

Most of them were trimmed, but I also have a complete capture.

In any case, as I mentioned that output for trimmed captures was what I was looking for. Thanks for working on it.

[davidd-lunarg]

No problem. PR #514 has now been merged to dev.

[dustin-lunarg]

Closed with #514