OpenXR Toolkit Tuning Guide (updated 21/02/23)

[edmuss]

The upscaler has given me about 15fps more at 150%, when I've tested it.

I don't think you're getting the GPU performance that you should be. Turn off reprojection entirely and see what appgpu frametimes and fps you're getting. Test in a free flight mission so you've not got CPU scripts dragging it down and see what you get. A10C free flight over Caucasus I get around 70 fps with 100% resolution on the G2, high textures, low/flat shadows abs no MSAA.

There are reports of AMD drivers since may last year breaking reprojection, could be that's your issue?

[A.F.]

edmuss,, could you explain how the fps and CPU data in OPRTK should be interpreted by me? Or a link to a page, maybe?

 

[edmuss]

Basically: -

appCPU = CPU time taken in ms to render the image

appGPU = GPU time taken in ms to render the image

postCPU = CPU time taken in ms for post processing (sharpening/colours/reprojection/FFR)

postGPU = GPU time taken in ms for post processing (sharpening/colours/reprojection/FFR)

If appGPU is less than appCPU then you are CPU bound and adjusting graphics options will make little difference to performance.

If appGPU is more than appCPU then you are GPU bound and adjusting graphics options will make more difference to performance.

When running without reprojection, postGPU is typically <0.5ms, with reprojection this is typically aroun 3-4ms (for my machine).

Working on the assumption that you are GPU bound (which is where you want to be) adjust your options to achieve the target frametime that you want, this should give the optimum image quality for the given performance.  Everyones VR experience is different so what works for me may not work for you.

When running reprojection your fps will always show as whichever refresh target it's running at (1/2, 1/3, 1/4 of refresh rate) but the appGPU frametimes will give a more accurate indication of performance.  Calculate you fps by using 1000/frametime, therefore 1000/11ms = 90fps, 1000/16ms = 60 fps, 1000/22ms = 45 fps.

When using reprojection you need to, at minimum, achieve the refresh target to keep it enabled, to do so both appGPU and postGPU should be combined and the result compared to the refresh target.  For example if you have 17ms appGPU and 3.5ms postGPU your total GPU frametime is 20.5ms; this is less than the 22ms for a 45Hz refresh target so reprojection will stay enabled.  With openxr toolkit the reprojection is able to step down to the next fraction of the headset refresh rate, this is 30Hz (and subsequently 22Hz) with a 90Hz headset refresh, this does mean that you can actually tune to achieve the 30Hz refresh target and you can wind the settings up.

[speed-of-heat]

@edmuss do you know of getting anyway to get the performance data to log to disk ? (accepted that may have some perf impact)

[A.F.]

vor 49 Minuten schrieb edmuss:

Basically: -

appCPU = ….

Many thanks for the detailed explanation!

[edmuss]

46 minutes ago, speed-of-heat said:

@edmuss do you know of getting anyway to get the performance data to log to disk ? (accepted that may have some perf impact)

Afraid I don't myself, @mbucchia is this something that is possible?

[mbucchia]

No there is no option. Don't get why people are obsessed with it at some point y'all have to forget the stats and play the game!!

[edmuss]

Because we want to see how badly our overpriced GPUs are working

[mbucchia]

2 hours ago, edmuss said:

Basically: -

appCPU = CPU time taken in ms to render the image

appGPU = GPU time taken in ms to render the image

postCPU = CPU time taken in ms for post processing (sharpening/colours/reprojection/FFR)

postGPU = GPU time taken in ms for post processing (sharpening/colours/reprojection/FFR)

You are mixing up a few things here.

OP asked about OpenXR Toolkit stats, which are explained here: https://mbucchia.github.io/OpenXR-Toolkit/overlay.html

You seem to be relating to the WMR overlay stats. There is no sharpening and colors processing there. Also there is no stat for FFR anywhere, since FFR doesn't really cost anything and is applied during processing (so it's effectively part of app stats). In the WMR overlay, pre/post are statistics of the OpenXR compositor, which in most cases will only include reprojection and some very small overhead for copying textures from a buffer to another, or things like MSAA resolve (that most apps do themselves anyway).

Edited August 4, 2022 by mbucchia

[speed-of-heat]

28 minutes ago, mbucchia said:

No there is no option. Don't get why people are obsessed with it at some point y'all have to forget the stats and play the game!!

actually its more to understand the impact of effects in game... so what are the performance impacts of clouds on high vs clouds on ultra  or MSAA or shadows or etc... 

[mbucchia]

16 minutes ago, speed-of-heat said:

actually its more to understand the impact of effects in game... so what are the performance impacts of clouds on high vs clouds on ultra  or MSAA or shadows or etc... 

You should be able to tell that by looking at the overlay in real time?

[speed-of-heat]

Not so much, as things like shadows change at distance etc... As do lods which effect performance and so on, you actually need to run the game for some time to get a realistic answer, for the impact.

You can get a "feel" for it, but for a more reliable comparison you need some data over time, run against a consistent scenario.

Edited August 4, 2022 by speed-of-heat

[edmuss]

1 hour ago, mbucchia said:

You are mixing up a few things here.

OP asked about OpenXR Toolkit stats, which are explained here: https://mbucchia.github.io/OpenXR-Toolkit/overlay.html

You seem to be relating to the WMR overlay stats. There is no sharpening and colors processing there. Also there is no stat for FFR anywhere, since FFR doesn't really cost anything and is applied during processing (so it's effectively part of app stats). In the WMR overlay, pre/post are statistics of the OpenXR compositor, which in most cases will only include reprojection and some very small overhead for copying textures from a buffer to another, or things like MSAA resolve (that most apps do themselves anyway).

 

Thanks for the clarification, you're right about mixing up the wmr/toolkit overlays. Would it be fair to assume that the toolkit overlay would give a more complete number on performance?

[mbucchia]

26 minutes ago, edmuss said:

Thanks for the clarification, you're right about mixing up the wmr/toolkit overlays. Would it be fair to assume that the toolkit overlay would give a more complete number on performance?

Not quite, OpenXR Toolkit overlay only has info on app + OpenXR Toolkit itself. Nothing about the OpenXR runtime (the pre/post in the WMR overlay). There is no capability in OpenXR to query general runtime statistics, hence impossible for the toolkit to include these metrics.

46 minutes ago, speed-of-heat said:

Not so much, as things like shadows change at distance etc... As do lods which effect performance and so on, you actually need to run the game for some time to get a realistic answer, for the impact.

You can get a "feel" for it, but for a more reliable comparison you need some data over time, run against a consistent scenario.

I have to disagree here, unless you are going to run exactly the same mission, assuming there is no randomness in the game (all clouds and objects are always at the same place), and your head always follows the exact same pattern of movement. That seems... unlikely. IMO giving this type of capability is allow people to compare apples to oranges and peaches to bananas. That's why I don't encourage it. The "feel" is all that matters, given that you will never be able to compare apples to apples, unless you use a professional benchmark (because these actually strive to be fully deterministic). Giving the whole CSV file thing is encouraging people to report differences and issues that aren't there.

If you are on WMR, and persist with this idea, you can use the ETL tracing (Troubleshooting for developers · microsoft/OpenXR-MixedReality Wiki (github.com)) and then write an ETL parser that will extract this information. We have such tool internally, but we only use it for scenarios that are deterministic as I described, because otherwise it provides more false information than it provides true information.

Performance & measurement is not a trivial problem that can be summarized to "look at FPS over time".

[speed-of-heat]

Actually that’s exactly what I do…  I use a fixed point of view with the helmet stabilised and then re-run the mission recording . I keep the mission simple to reduce the number of random variables etc…

 

in fpsvr I use an average of the cpu and gpu frame times and compare them between the individual changes.

Edited August 4, 2022 by speed-of-heat

[icecold951]

Open Composite doesn't appear to be working as of the current update.

[edmuss]

Working fine at my end? OB 2.7.16.28157.

[Sr.]

45 minutes ago, icecold951 said:

Open Composite doesn't appear to be working as of the current update.

reboot?

[icecold951]

Just now, Sr. said:

reboot?

Reboot, used the cleaning tool, redownloaded open composite, the works. Works in Steam VR, but it goes desktop under Open Composite. Are you getting it to work?

[icecold951]

23 minutes ago, edmuss said:

Working fine at my end? OB 2.7.16.28157.

Sounds like I might have to do a reinstall then....Anyone else?

[icecold951]

Complete uninstall, delete, reinstall, and same issue.

[icecold951]

Downloaded the .dll directly, rather than using the open composite. That works. For some reason the open composite tool is messed up in this. This is despite the sim being properly installed.

[mbucchia]

9 hours ago, speed-of-heat said:

Actually that’s exactly what I do…  I use a fixed point of view with the helmet stabilised and then re-run the mission recording . I keep the mission simple to reduce the number of random variables etc…

 

in fpsvr I use an average of the cpu and gpu frame times and compare them between the individual changes.

 

You want all this data only to reduce it to a global average that loses an incredible amount of data and its significance... you can average a higher FPS with constant stuttering (because the average literally acts as a low-pass filter). You can average a higher FPS with low dips that make the experience unplayable for several seconds. You can average a higher FPS because the game decided to spawn less entities (non-deterministic AI and game logic).

Higher average FPS does not mean better.

This is exactly what I mean with comparing apples to oranges and why I personally won't make the effort to put this data in everyone's hands. If I do that, I'm going to start receiving "bug" reports here and there because of people misusing the data.

I already get those every time I release new software. Version A was higher FPS than version B... and 95% of the time this is again because of user error, people not able to compare apple to apple or using the relevant input data correctly. 

I've literally had people tell me how there is a huge performance issue between OpenXR Toolkit 1.1.3 and 1.1.4 on their HP Reverb... yet the only change between the two is 1 line of code that is only used with Pimax headset...

These destroy the productivity of us developers, and I have no intention to shoot myself in the foot by offering this data (a loaded gun in the hands of every user)  

Edited August 5, 2022 by mbucchia

[speed-of-heat]

1 hour ago, mbucchia said:

You want all this data only to reduce it to a global average that loses an incredible amount of data and its significance... you can average a higher FPS with constant stuttering (because the average literally acts as a low-pass filter). You can average a higher FPS with low dips that make the experience unplayable for several seconds. You can average a higher FPS because the game decided to spawn less entities (non-deterministic AI and game logic).

Higher average FPS does not mean better.

This is exactly what I mean with comparing apples to oranges and why I personally won't make the effort to put this data in everyone's hands. If I do that, I'm going to start receiving "bug" reports here and there because of people misusing the data.

I already get those every time I release new software. Version A was higher FPS than version B... and 95% of the time this is again because of user error, people not able to compare apple to apple or using the relevant input data correctly. 

I've literally had people tell me how there is a huge performance issue between OpenXR Toolkit 1.1.3 and 1.1.4 on their HP Reverb... yet the only change between the two is 1 line of code that is only used with Pimax headset...

These destroy the productivity of us developers, and I have no intention to shoot myself in the foot by offering this data (a loaded gun in the hands of every user)  

 

The position is clear and I understand it and your reasoning.

Edited August 5, 2022 by speed-of-heat

[hannibal]

Question for you guys.. of the three

Would you go 4x MSAA or upscale via NIS openxr toolkit or upscale via FSR openxr toolkit?

My goal is higher fps with good visual..at the moment I like how 4X MSAA looks (no upscaling involved)