Understanding FPS info?

[Atlas]

When looking at the FPS info displayed in BMS, there is FPS, Sim, Ren, Mem, Cmd, Cycle, Draw, etc. on there. Are these terms explained somewhere in the BMS documentation or forum?

I’d just like to better understand these numbers and how it relates to display settings or hardware adjustments.

Thanks!

[airtex2019]

(Disclaimer: we reserve the right to change and evolve these… this is the best of my knowledge as of 4.37.4)

FPS => is just 1000/milliseconds … time measured from frame to frame (from prior D3D Present() call to latest Present() call)

Sim rate/time => this is the “main loop” thread, which does everything from processing input events, networking events, moving things around (physics, collision-detection) and telling the Render thread what to draw, and where. This metric is the clock-time required for the simloop-thread to complete one frame of work.

Ren rate/time => this is “render loop” thread, which takes the queue of what-to-draw instructions from the Sim loop and transmits them to Direct3D. This metric is the clock-time required for the render-thread to complete one frame of work.

(Visualize: an assembly-line with 4 stations… simloop, then render-thread, then GPU paints the frame, then it’s transmitted over a cable to the monitor)

Cmds => number of D3D draw instructions … a rough measure of “relative load” on the Ren thread and GPU to paint that frame. You’ll see this number go way up, as you fly near airbases, cities, front-line combat, etc.

Mem => this is not total RAM or VRAM, just the special pool of memory used for the D3D draw commands, above.

Sim/Ren Cycle => this is a bit of misnomer… to me “cycle time” implies a full frame-to-frame time measurement – but in this case it’s more like a stopwatch, measuring start-of-work to end-of-work.

Sim-Cap => time-delay from the built-in FPS limiter

Sim-Draw => time spent formulating draw instructions for the Ren thread

Ren-Exec => time spent transmitting the draw instructions to D3D

Ren-Prsnt => time spent inside the D3D Present() call … this API call tells D3D “ok we’re done with this frame, tell nvidia driver to start doing its thing” … delays here could be due to v-sync, or 2nd/3rd party FPS limiters which plug in at this layer, or it could mean GPU is the bottleneck and D3D has to wait for a backbuffer to free up

Sim-WaitRen => time spent waiting on the Render thread (these 2 threads run in parallel, but are interlocked with one another – again visualize the assembly-line metaphor … the line can only move as fast as its slowest station)

Ren-WaitSim => time spent waiting on the SimLoop thread (see above)

Note neither of these “wait” times necessarily means you’re CPU- or GPU-bound… it’s just one CPU thread waiting on another CPU thread.

But in the typical case (without triple-buffering or v-sync or fps-limiters) if your GPU is the weakest link, you may see the Ren thread spending significant time in Prsnt and the Sim thread blocked waiting for the Ren thread.

That’s all I know ottomh, the others tend to not be significant factors… things like RTT-export and background threadpool jobs.

[Tomcattwo]

Great explanation, @airtex2019, but that’s gonna make some peoples’ heads explode 🤯 🤯 🤯 🤯 !!!

@Atlas , you asked for it
Regards,

[eVhWolfgang]

[Atlas]

@airtex2019
Much appreciated sir! And am I correct that this info does not exist in the current PDF manuals?

@Tomcattwo
Best to learn something new!

[Atlas]

Surprisingly, frametime doesn’t seem to be on there?

Let me see if I understand the basics at least:

• FPS - higher is better
• Frametime - wherever it may be, lower is better and big frametime spikes can be seen as stuttering or a not-smooth visual experience
• Sim - lower is better??
• Ren - lower is better??
• CMD - higher means more load on GPU, not necessarily bad or good
• Cycle - lower is better
• Mem - @airtex2019 you’ve not mentioned this? RAM usage? VRAM?
• et al - lower is better

Interesting how the FPS display for a monitor seems to be different from the FPS display for VR (OpenXR in the case of the above screenshot).

Basically, I would like to be able to compare screenshots and somewhat understand what’s going on, with emphasis on the VR side of things as I feel that this is where most of the testing will be done going forwards.

[airtex2019]

@Atlas when I say “frametime” – it’s not labeled as such – I’m referring to these numbers which are (1000/fps)

[airtex2019]

@Atlas said in Understanding FPS info?:

Mem - @airtex2019 you’ve not mentioned this?

tbh idk. obvs we use a lot more (RAM and VRAM) than that.

probably just the pool-based allocator for the draw commands … I think you see this number go up/down directionally with the number of Cmds

[Atlas]

@airtex2019
I see, thanks! And did I get the basics right about higher/lower being better?

[airtex2019]

@Atlas
frames-per-second => higher is better
seconds-per-frame => lower is better

they are the same metric – just one is inverse of the other. make sense?

[Atlas]

@airtex2019
Sorry, which one is “seconds per frame”??

[airtex2019]

@Atlas “ms” means milliseconds – 1/1000th of a second

so eg. “24.96 ms” means 0.02496 seconds-per-frame

1/0.02496 == 40.1 frames-per-second

[Atlas]

@airtex2019
Oh, you mean fps vs frametime, yeah, I got that. I thought you were referring to another named metric.

Thanks!

[airtex2019]

I updated my first reply above, to better explain why the top-line FPS metric doesn’t exactly match either Sim or Ren.

The top-line FPS metric is not a stopwatch on the Sim or Ren threads – it is a frame-to-frame pace time, the way FrameView/PresentMon and Afterburner/RivaTuner etc all record and report FPS.

(In most cases, it should be very close to the Ren thread metric… but it won’t be exactly the same.)

[POLARIS1]

@airtex2019

To simplify all terms and make them usable I would appreciate a simple set of data:
Which set of values for all BMS FPS measured constitutes good, mediocre and low.

[Atlas]

@airtex2019
So on my VR screenshot, FPS is 45.1, Ren is 59.8
There are quite a few Cmd calls as I’m in the BenchmarkTE on the runway.
The Prsnt, WaitSim, and Res numbers are all low meaning the GPU isn’t really waiting on much.

Any ideas why the Ren is higher than FPS?

@POLARIS1
At the moment, I am really only concentrating on FPS, Sim, and Ren, as well as the ms readings on them. Higher FPS/Sim/Ren is good and this will show up as low ms readings, but what I’m watching out for is no spikes in the ms readings — maybe a habit from DCS and watching how the frametime spikes causes microstutters.

I would be interested if @airtex2019 can highlight any other metrics to pay attention to, especially on the VR screenshot as I’ll be doing tests in VR going forward and interstingly enough, the FPS window in VR has different metrics compared to the 2D one.

@POLARIS1 said in Understanding FPS info?:

Which set of values for all BMS FPS measured constitutes good, mediocre and low.

I guess just for FPS, good will be anything above 30 really, especially since this is the Benchmark TE.
25-30 would be mid, anything below 25 especially if you go below 20 may be considered low.
I’m sure someone would correct me here if I’m wrong.

[airtex2019]

@Atlas said in Understanding FPS info?:

interstingly enough, the FPS window in VR has different metrics compared to the 2D one.

it’s not that interesting … just lack of screen space for the full row - the SimAndOTWCycleAndDeps is a rollup (sum) of all the numbers on the Sim line, except for WaitRen which is the only important one to keep eye on.

Any ideas why the Ren is higher than FPS?

Ren is a “stopwatch” measuring time within a frame – from the start of work to end of work. (Visualize: a car doing a quarter-mile drag strip)

The top-line FPS number is more like a “lap time” clock – measuring time from frame to frame, at the same line of code in the loop. (Visualize: a car doing full laps around a track)

Because of the way the Ren and Sim theads interlock with one another, there can be 1-2 milliseconds of difference between those two metrics… resulting in FPS clock slower than Ren.

The real explanation for that is super technical and has to do with the OS thread-scheduler. And I think this thread may have shined a light on how that can be improved… so, as always, thanks!

[Atlas]

@airtex2019
I think I need to do a few more laps to wrap my head around this. Just finished taking my baseline screenshots this evening so maybe looking at more numbers will make more sense.

As always, thanks for your input!