I thank you for your kind words! I’m glad it is helping!!
How do you manually enable VRSS?
I thank you for your kind words! I’m glad it is helping!!
How do you manually enable VRSS?
Thank you, I’m reluctant to run any such ‘tool’ as-admin and I might pass over this trick. If there is any other one already using this tool and willing to try out and report, please, let us know!
I tried already in the past with some other games. Unfortunately it seems not to be working with the new Nvidia drivers (starting with 445). I think they made some changes in the drivers to avoid that trick.
@banfy211, have you tried this with a newer version of Nvidia inspector?
I gave it a valiant attempt yesterday to enable VRSS for MSFS 2020. I desperately want to get clear cockpit graphics (text) at a scaling that is low enough that I get less stuttering. I was hoping that VRSS was the answer.
I ran into a sort of “catch-22” problem. If I used the latest drivers then Nvidia Inspector (new version) did not show the required fields to be edited. Also, regardless of the driver version, I believe it is impossible to create a profile for MSFS 2020 due to the protected/encrypted nature of the executable (running the Microsoft Store version).
If I went to an older driver, then Nvidia Inspector would show the required fields and I could edit them, but only globally, since the issue mentioned above prevented me from making a Flight Simulator-specific profile.
BUT, while the newer drivers have a MSFS 2020 profile in Nvidia Control Panel, the older drivers do not. Thus the “catch-22”…I either use old drivers and can edit the settings with Nvidia Inspector but not set up a profile in Nvidia Control Panel or I use newer drivers and can set up a profile in Nvidia Control panel but cannot enable VRSS via Nvidia Inspector.
I tried setting VRSS to adaptive globally in both Nvidia Inspector and in Nvidia Control Panel but this had no effect.
Otherwise I’ve posted this in another thread but it makes sense to duplicate it here:
I’m also currently trying other system/nvidia settings combinations on my system trying to spot any outlier which has the most impact, and I’m doing the same with FS2020 settings. For the later, there are settings which are really impactful and others nearly inconsequential.
“My VR Settings” is more about finding the balance for smooth performance with good graphics for a pilot perspective (for example I would never reduce anisotropic for this reason). However with latest SteamVR, latest FS2020, and lots of VR flying hours in FS2020 now, I find the best approach is saturating the GPU to a certain limits which makes it stick most of the time at 30fps (with 90Hz refresh rate) or 40fps (with 80Hz refresh rate). This strategy gives me the chance to boost a lot of settings like resolution for the best visuals, while keeping a stable 30fps and reducing the annoying stutters in VR (these are uncomfortable because there is no Variable Refresh Rate). I’ll post my findings in “My VR Settings” discussion once I’m comfortable with all these tests.
NB: my system is mostly GPU bound but FS2020 threading is sometimes overloading the CPU which brings down the GPU.
I’ve just added the following in the 2nd post:
I’ve been further exploring optimization opportunities since my last update and I’ll update my settings screenshots and some comments. In short, instead of trying to get the highest fps, I’ve approach the settings differently in trying to get the smoothest fps so that I can eliminate most of the stutters (unrelated to juddering). Therefore since my last update I’ve been trying to stay as much as possible locked to 30fps while making sure there is not CPU/GPU sync hiccup intervening and dropping the fps further.
In effect, I’ve discovered there is a fps-locking feature with FS2020 which is limiting the fps to an integer divisor of the Valve Index refresh rate (for example at 90Hz it locks to 45, 30 or 22.7fps). I was even using this to my advantage when for example I was able to push 42fps, in setting SteamVR to 80Hz in order to lock to 40fps, otherwise it would lock to 30 only.
In approaching the settings to get a smooth 30fps instead of a constantly alternating 22.7/30/45 fps depending on the context, I’ve noted it is perceivably still smooth enough in most conditions. Of course at 30fps don’t wish you’d also get smooth updates when looking 90 deg to the side during takeoff close to the ground.
The best part of this is in order to achieve the goal of locking in to 30fps you have to ‘saturate’ the GPU so that you’re heavily GPU limited. This is good because it means you can raise your visuals and have a better looking view! Beware, not all settings play nice with this strategy and here is a short list of my findings for you to try out if you want until I update my post in the coming days:
NVidia CPL Threaded Optimization must be ON (not AUTO). It helps a lot reducing the GPU/CPU sync slowdowns/spikes I can monitor clearly with fpsVr.
I don’t see much performance difference if any between NVidia CPL Texture performance and the other Trilinear optimizations, therefore I’m favoring Quality now (until I also cross check against “My 4K Settings”).
I’ve disabled GPU Scheduling also for now. I’m not sure it gives any advantage yet and today’s tests were giving better results overall. It is quite subjective at this stage though.
Render Scaling is better 100% or 70% (this is CPU/GPU dependent). When using any other value I can see the CPU taking a lot of processing time, constantly, whereas with 100% for example it is freeing the CPU for other things. I’ll therefore probably just keep the ‘legibility’ option which is using 100% TAA and adjusting render resolution in SteamVR instead. NB: for my 30fps goal, I also use 100% render scaling in SteamVR and I get a very nice and sharp picture!
Ambiant Occlusion, even if LOW, seems to be causing a lot of CPU activity when close to the ground mostly. It is bad to have stutters on short final and in many of my tests, I can get rid of most of these with AO to OFF.
I suspect the fps-lock feature I’ve mentioned above is either FS2020 hard coded or OpenXR (I never noticed such behavior in other games but I might have not paid much attention either). Although I could select 80hz or 90hz with update 6 and choose whether I’d prefer getting 40fps or 30fps, with update 7 I find anything other than 90hz is causing a lot of CPU/GPU sync issues (red spikes in fpsVr). It depends on the load of course and therefore it depends on the aircraft you’re flying and location.
With these I can raise some important settings (SteamVR 100%, TAA 100%, Terrain LOD 100%, Buildings High, Trees High, Clouds Medium) and get a smooth flight over Los Angeles with lots of clouds and multiplayer aircraft around me. There are even times I can push clouds to HIGH and this is really looking good considering it is rendering 2x2016x2240 pixels!
However I still can’t enable motion smoothing in SteamVR because it is creating too much wobbling at 30fps. So although I can see juddering (this is what makes you see the image de-doubling when looking to the side for example) I’m fine because most of the time I’m flying I’m not making constant aerobatics figures either.
I hope this will give you some additional opportunities on your hardware, and I’ll update my screenshots and the explanations with them in the coming days!
I have enough CptLucky screenshots on my phone now to make a separate dedicated album lol
I thank you for your kind words and I’m glad this is helping!
With regards to the confusing meaning of Render Scaling…When I set the render scaling to 100% I see the following with dev Mode enabled for my Reverb G2:
Post : 3164x3092
I assume the post resolution is for 1 eye correct?
@fulatoro These are always resolutions for 1 eye usually. The issue is the G2 is reporting too high a value for the OpenXR “recommended view configuration size”. People have been complaining about this when using the G2 in SteamVR and HP is supposedly investigating it (these are values stored in the HMD non-volatile memory most likely and can be changed)
NB: I’m further explaining the reasons for the G2 higher recommended resolution here:
WMR Scaling and Dev Tools - Some Explanations
Nevertheless, what counts with my experiments with the Valve Index is looking at the W x H numbers final image will be viewed at, and this can differ from the W x H the image is rendered to. It can differ because it is changed in SteamVR SS resolution, and it can also differ because of the FS2020 render scaling:
|.||Reverb G2||Valve Index||Notes|
|FS2020 Render||2214 x 2162 (TAA 70%)||1800 x 2004 (TAA 100%)||Steam SS 80% for Index|
|Send to OpenXR||3164 x 3092||2016 x 2240||Enlarge to OXR/SteanVR 100% (Recommended res.)|
|Process Image||3164 x 3092||2016 x 2240||Distort image for HMD lenses|
|Display Image||2160 x 2160||1440 x 1600||HMD native screen res.|
NB: It is expected rendering to a larger resolution because the image is distorted to compensate the lens curvature and in doing so, the center region is enlarged and the outer regions shrink (like a fisheye effect). If the rendering was to the native resolution, center would appear blurrier in the HMD. At 80% SS in SteamVR it is still good enough to me in the Index but it is clearer at SteamVR 100% in any case. Also, the simulator has to render to a higher resolution than native, especially with the Valve Index because not all the panel pixels are in view due to the lens shape and the position of the screens in the HMD. This is why headsets also have a ‘lens mask’ which is used to save drawing pixels in these areas (the mask you see reported displaying 1/4 of the screen size - a bug - for people with Oculus headsets with FS2020). You can see these masks in the most comprehensive database I’ve found about this here: HMD Geometry Database | Collected geometry data from some commercially available VR headsets.
Having said this, what I’ve noted and experimented with is using TAA is causing the CPU to work a lot more and it is inducing as a consequence CPU/GPU sync problems. It is amazing because I get more fps at TAA 100% than TAA 80% for example just because of this overhead. But this effect is most likely due to something else I’ll try documenting today along with my update: my settings are setting FS2020 near the vertex processing limit and this is what is responsible for most cases of stutters when trying to make the CPU doing more. I believe I found 1 major opportunity to make a better VR experience (not necessarily more fps but less to no stutters) now that I’ve identified this bottleneck (or at least what appears to be a bottleneck). More about this later!
Interesting. That’s mean we, Oculus Users, will see an improvement when they will use correctly the pencil mask AFAIK (E.g. 14,7% less pixels to render for CV1).
yes, but per my latest findings, mostly if you’re pixel shader bound (lots of processing per pixel). However if you’re mostly vertex shader bound (lots of geometry displaying) it won’t change much.
Thank you for the detailed response. Very educational. I have limited by RS to 70% without noticing much difference in the image quality but now I get much smoother experience with FPS between 33-38FPS for GA and about 30 for airliners. More than enough.
It does seem however that with a render scale of 70 there is more cpu bottleneck (Mainthread) whereas going to 100% shows limited by GPU but also leads to a drop in frame… I have to say that despite the drop in frames it is still smooth. Just did a flight from EGLL in the 787… Notoriously bad combination but despite frames of 22-23 FPS on the ground and 26-28 in the air it was as totally acceptable experience.
Thank you for sharing your experience, this is helpful!
I’ve not redacted my update yet but here are a few discoveries which might help you experimenting in the meantime:
a) if you enable Win10 Hardware Accelerated GPU Scheduling, you’ll most likely have every other frame dropped (as seen in fpsVr and visually). In order to cure this you have to launch Steam Client first (not SteamVR). It might just be my system but this seems consistent.
b) On the system I’m using for FS2020 (see discussion link above), I always get the least stutters (due mostly to RAM<->VRAM transfers and/or CPU/GPU sync) in using:
These are all working together in addition to balancing FS2020 settings to reach a certain goal. Changing any of these give lesser results.
I’ll detail the changes in the settings and the rationale behind in an update post most likely tomorrow.
Update: I’ve been doing a few more tests and flights and as a matter of fact there is a lot of inconsistencies from day to day (without any new program/service/update installed/config changed). Therefore I’m not even sure what gave me solid 30fps with most at 100% is really viable overall.
I’m currently trying to further tweak and compare and my next step will be trying to use an event analyzer in order to dive in the inner world of the rendered frames and try to see if there is anything unusual which could either be zendesk or documented here.
In the meantime, I still consistently get every other frame dropped every time I use Win10 Hardware Accelerated GPU Scheduling AND Steam Client is not launched. Here is a typical trace from SteamVR 1.15.12 when this is happening:
Tue Nov 24 2020 13:49:38.350 - Transitioning XrSession from XR_SESSION_STATE_READY to XR_SESSION_STATE_SYNCHRONIZED Tue Nov 24 2020 13:49:38.350 - Transitioning XrSession from XR_SESSION_STATE_SYNCHRONIZED to XR_SESSION_STATE_VISIBLE Tue Nov 24 2020 13:49:38.350 - Transitioning XrSession from XR_SESSION_STATE_VISIBLE to XR_SESSION_STATE_FOCUSED Tue Nov 24 2020 13:49:38.384 - Application submitted two left scene textures for a single frame! Tue Nov 24 2020 13:49:38.384 - ComposeLayerProjection: failed to submit view 0 Tue Nov 24 2020 13:49:38.384 - Application submitted two right scene textures for a single frame! Tue Nov 24 2020 13:49:38.384 - ComposeLayerProjection: failed to submit view 1 Tue Nov 24 2020 13:49:38.767 - Created shared texture 'Scene create D3D11, 0' 1800x2004 (1 mips) Tue Nov 24 2020 13:49:38.767 - Created shared texture 'Scene create D3D11, 0' 1800x2004 (1 mips) Tue Nov 24 2020 13:49:38.773 - Created shared texture 'Scene create D3D11, 0' 1800x2004 (1 mips) Tue Nov 24 2020 13:49:38.773 - Created shared texture 'Scene create D3D11, 1' 1800x2004 (1 mips) Tue Nov 24 2020 13:49:38.773 - Created shared texture 'Scene create D3D11, 1' 1800x2004 (1 mips) Tue Nov 24 2020 13:49:38.773 - Created shared texture 'Scene create D3D11, 1' 1800x2004 (1 mips) Tue Nov 24 2020 13:49:39.003 - ComposeLayerProjection: failed to submit view 0 Tue Nov 24 2020 13:49:39.003 - ComposeLayerProjection: failed to submit view 1 Tue Nov 24 2020 13:49:39.476 - ComposeLayerProjection: failed to submit view 0 Tue Nov 24 2020 13:49:39.476 - ComposeLayerProjection: failed to submit view 1 Tue Nov 24 2020 13:49:39.586 - ComposeLayerProjection: failed to submit view 0 Tue Nov 24 2020 13:49:39.586 - ComposeLayerProjection: failed to submit view 1 Tue Nov 24 2020 13:49:39.806 - ComposeLayerProjection: failed to submit view 0 Tue Nov 24 2020 13:49:39.807 - ComposeLayerProjection: failed to submit view 1 Tue Nov 24 2020 13:49:40.190 - ComposeLayerProjection: failed to submit view 0 Tue Nov 24 2020 13:49:40.419 - ComposeLayerProjection: failed to submit view 0 Tue Nov 24 2020 13:49:40.419 - ComposeLayerProjection: failed to submit view 1 Tue Nov 24 2020 13:49:40.492 - ComposeLayerProjection: failed to submit view 0 Tue Nov 24 2020 13:49:40.492 - ComposeLayerProjection: failed to submit view 1 Tue Nov 24 2020 13:49:40.762 - ComposeLayerProjection: failed to submit view 0 ... Tue Nov 24 2020 13:50:32.958 - ComposeLayerProjection: failed to submit view 0 Tue Nov 24 2020 13:50:32.958 - ComposeLayerProjection: failed to submit view 1 Tue Nov 24 2020 13:50:33.070 - ComposeLayerProjection: failed to submit view 0 Tue Nov 24 2020 13:50:33.070 - ComposeLayerProjection: failed to submit view 1 Tue Nov 24 2020 13:50:33.109 - Transitioning XrSession from XR_SESSION_STATE_FOCUSED to XR_SESSION_STATE_VISIBLE Tue Nov 24 2020 13:50:33.109 - Transitioning XrSession from XR_SESSION_STATE_VISIBLE to XR_SESSION_STATE_SYNCHRONIZED Tue Nov 24 2020 13:50:33.109 - Transitioning XrSession from XR_SESSION_STATE_SYNCHRONIZED to XR_SESSION_STATE_STOPPING Tue Nov 24 2020 13:50:33.109 - Transitioning XrSession from XR_SESSION_STATE_STOPPING to XR_SESSION_STATE_IDLE Tue Nov 24 2020 13:50:33.109 - Transitioning XrSession from XR_SESSION_STATE_IDLE to XR_SESSION_STATE_EXITING
Just wanted to quickly jump on and thank you for your hard work in putting this together.
I had a 3 hour group flight last night in the new Reverb G2 with settings very much based on your guide here and it was simply outstanding.
I needed to get to the magic 30fps for the WMR OpenXR Motion Smoothing to work well, so set nvidia control panel frame rate to 31 and basically followed your settings apart from that (I’m using a 1080Ti so comparable to your 2070S with a bit more VRAM).
The sim seemed to be nicely locked at 30fps with barely a flicker and the WMR Motion Smoothing did an amazing job (much better than the previous Rift S with Oculus ASW I have to say)
Anyway, back to my original point - thank you again, this guide/suggestions thread has really helped me to get a smooth in-flight experience
Thank you for your kind words! I’m glad this is helping you getting a better experience!
I wish SteamVR had as nice a motion smoothing as WMR so that I can enjoy it more on the Valve Index while waiting for the G2 pre-order
I’ll try your suggestion limiting the fps in the NVidia CPL and see how it goes, especially how it goes in the fpsVr timeline. In effect, I know there is an issue in VR with the NVidia drivers released after 446.14* causing intermittent fps drops / latency spikes, and NVidia is now aware of this but their last comment a few days ago was they’ve not found the cause yet. I’ve try 446.14 again and in comparison I don’t get any significant change from 457.30.
The main issues I’m looking at right now are:
This leads me to believing there is another issue here which is either FS2020/OpenXR related or SteamVR/OpenXR rooted.
It might be FS2020 is hardcoding 90/4, 90/3, 90/2 fps since update 7 without consideration for the HMD capabilities (80,90,120,144 for the Index) because WMR HMD are all 60hz/90hz only. It might also be a bug in the SteamVR OpenXR implementation since they’ve corrected in a very recent update an OpenXR timing related bug.
*this was the last driver pre-Win10 2004 before introducing Hardware Assisted GPU Scheduling - aka HAGS
For those wondering what this NVidia driver problem is all about, here is a link to the relevant discussion:
TL;DR: in VR only, every drivers since 451.48 (reported) or at least since 446.14* are causing frame drops and stutters in any VR games. I’m not sure this is SteamVR related only or broader.
*this was the last driver pre-Win10 2004 before introducing Hardware Assisted GPU Scheduling - aka HAGS
A couple days ago there was a HP Reverb AMA on Reddit with the following news about this NVidia driver bug:
Another suggestion, which worked for me to get some addon fps - I’m using Process Lasso
app that you can utilize your CPU usage - running apps, like FS2020 CPU priority - set it high or realtime as well as VR compositor.