Interpreting CPU/GPU Numbers from DCS and OXRTK Overlays

[Maddaawg]

Can I get some help interpreting these numbers? All done on solo in VR.

OXRTK
80 FPS (Q3 is set at 80fps)
App CPU 1.8-1.9
Rdr CPU 5.6
App GPU 11.7ms
VRAM 5.4 (48%)

DCS
CPU Bound in Red
Frame Time 0-100 80fps
Bright Green line near the bottom but no numbers
Dull Green line below above. 
Both lines are 99% steady with only a small peak a couple times when stressing the AC and then a small yellow peak on the lower line.
Under Advance
CPU 1.4 - 1.5
Frame Time moving rapidly between 11 -12

 

Is there any way to output this to a log file vs staring at them and trying to write the numbers down in VR?

I'm not having any issues but eventually want to upgrade and need to figure that out, especially since I may go with a Pimax Crystal Light soon.

 

[edmuss]

Roughly from memory...

AppCPU is the time taken for the CPU to render the frame in milliseconds, however since the advent of MT this is no longer a reliable metric for performance as the CPU part of the render thread is running on multiple cores.  On ST it could be read as a hard number to guage if you were CPU limited on the render thread.  I think RdrCPU is a better metric but I seem to recall that this still doesn't give a whole and accurate picture.
AppGPU is the time taken for the GPU to render the frame in milliseconds.  1000 / 11.7ms = 85 fps so you have 5fps (0.8ms) headroom at 80Hz refresh.
VRAM is the actual VRAM in usage, not in allocation.

CPU bound in red indicates that your CPU is bottlenecking on the main thread, this is the logic thread which is still (to the best of my knowledge) single threaded and handles stuff like AI and simulation.  On ST this was the be all and end that would drag your fps into the dirt, now with MT the threads are seperated so there is less performance impact.
I don't think the DCS frametime is as helpful as the toolkit one as as it just shows 1000/FPS, not the actual render time so you can't judge available overhead.
Top line (white) is the GPU frametime, bottom line (green) is the CPU frametime, I don't see a dull green line, although it may be hidden in with the brighter green line (assuming there is a dull green for main thread and a bright green for render thread?).

Openxr toolkit can log statistics to CSV, have a trawl through the menus and it should be in there, it might be buried in advanced mode.

I would say that you may be wanting to upgrade the GPU at least to run a crystal light at 72Hz refresh, if I disable eyetracking in the aero (same resolution) then I get 50-55fps compared to >90fps with the eyetracking.  Obviously that is without fixed foveated render, however I think the uplift is only around 10-15fps depending on how much you want to pixellate the periperal vision.  I am running quite aggressive foveated settings though and the eye tracking hides this, you won't achieve the same uplift without eyetracking without murdering the visual quality.

However a GPU upgrade would probably be bottlenecked by the CPU though, the fact you're running in red CPU bound main thread now is not encouraging, especially as to run quadviews will increase your CPU load due to having to render 4 views instead of the normal 2.

Edited June 12, 2024 by edmuss

[speed-of-heat]

you can log with a command line to the companion app 

Run "C:\Program Files\OpenXR-Toolkit\companion.exe" -record-stats toggle

or where ever it is installed

[Maddaawg]

14 hours ago, edmuss said:

Top line (white) is the GPU frametime

 

Funny thing is you don't see the duller green line, but I don't see the white line.

[edmuss]

Weird, I wonder if the line changes from white to green depending on some settings?

A wiki for the DCS performance metrics chart would have solved so many questions on this.

[Digitalvole]

Does one combine the app and rdr cpu frame time to get the total cpu frame time? 

[edmuss]

I don't think so, I'm pretty sure that appCPU is no longer a valid metric for DCS.  I think the graphlines should give you a rough indication of where things are though, as mentioned above, I see a white line for GPU at 11ms and a green line for CPU at around 3-4ms (guessing); the graph is 0-100ms to give a judge of scale, although running it at 0-40ms would give more detail.

[Maddaawg]

On 6/13/2024 at 12:49 AM, edmuss said:

Weird, I wonder if the line changes from white to green depending on some settings?

A wiki for the DCS performance metrics chart would have solved so many questions on this.

I finally saw the white line when I changed some settings and did some maneuvering, it was under the bright green line. I saw a video on YT with the same dull green line too.

[edmuss]

I had a closer look at the graph last night, if my memory and assumptions serves me right: -

White = frame - GPU
Green = simulation - CPU
Yellow = present - CPU
Blue = submit frame - CPU

Yellow and blue lines are pretty much identical and almost zero, they could very feasibly be overlaid and show as a dull green.

If your white GPU line was hidden behind your green CPU line then that doesn't bode well for the CPU unfortnately, I think essentially you're borderline hard CPU bound so if you were to run quadviews, your CPU frametime would increase, the GPU frametime would decrease but would then be waiting for the CPU to feed it data.

Of course you could install, test and configure quadviews now (you don't need eye tracking) to see if you gain any benefit, I suspect that it may be worse if anything.  I think your priority needs to be a faster CPU though

edit: corrected the naming of the colours.

Edited June 14, 2024 by edmuss

[Maddaawg]

7 hours ago, edmuss said:

I had a closer look at the graph last night, if my memory and assumptions serves me right: -

White = render frametime - GPU
Green = render frametime - CPU
Yellow = simulation frametime - CPU
Blue = present frametime - CPU

Yellow and blue lines are pretty much identical and almost zero, they could very feasibly be overlaid and show as a dull green.

If your white GPU line was hidden behind your green CPU line then that doesn't bode well for the CPU unfortnately, I think essentially you're borderline hard CPU bound so if you were to run quadviews, your CPU frametime would increase, the GPU frametime would decrease but would then be waiting for the CPU to feed it data.

Of course you could install, test and configure quadviews now (you don't need eye tracking) to see if you gain any benefit, I suspect that it may be worse if anything.  I think your priority needs to be a faster CPU though

And what is the top window white line for?

[edmuss]

The top window is purely fps, doesn't show you much apart from a couple of seconds history so you can see if the performance is trending up or down.

I updated my post above to correct the names, had misremembered.  I'm presuming that the simulation, present and submit times are all CPU and the frame is the GPU.

[Digitalvole]

On 6/13/2024 at 10:32 PM, edmuss said:

I don't think so, I'm pretty sure that appCPU is no longer a valid metric for DCS.  I think the graphlines should give you a rough indication of where things are though, as mentioned above, I see a white line for GPU at 11ms and a green line for CPU at around 3-4ms (guessing); the graph is 0-100ms to give a judge of scale, although running it at 0-40ms would give more detail.

God I have a terrible memory! Thanks for that, I’d assumed you added them up. Good to know. I need to find out how to see these graphs, only ones I can find are in the ODT hud overlays. I shall investigate further.