My 2070 SUPER VR settings and suggestions (Index - SteamVR) 🟢

Found it. For some reason my library was not showing all the items in it including SteamVR . That option was not selected to show it. Once I selected that I found the SteamVR app and was able to use BETAs to roll back to 1.14, I will let you know how it helps.

1 Like

Wow. rolled back to Steam VR 1.14 and used your settings (and then up-ed many to ULTRA since I am on a 3080 with 10850k and 32 GB ram and it is running so smoothly , Haven’t figured out how to see FPS on index, but feels really high,
I still am having trouble in that if I go out of VR mode into PC mode, Everything slows down and I get <10 fps and can’t go back without restarting everything.
Thanks for your help rolling back to 1.14

1 Like

Is there any courageous pilot wanting to try and let us know how does NVidia 461.09 is working in VR?

NVIDIA DRIVERS GeForce Game Ready Driver WHQL 461.09

I plan on trying it later tonight. Probably in 3 or 4 hrs.

1 Like

I gave the driver a go but didn’t really notice much of a difference. I think the main issue lies within Steam VR beta. I get perfect performance on the Linux version no matter which driver I use. The only bummer is the scale of everything is off with that version making everything look too big. But I’m getting a constant 45FPS/90hz on the index in New Zealand with 457.30 in New Zealand no stutters at all.

1 Like

you can override the IPD easily in SteamVR though!

You can do this with fpsVr with the GUI, or, you can edit the config file:

C:\Program Files (x86)\Steam\config\steamvr.vrconfig

 "steamvr" : {
      "ipdOffset" : 0.002,

This tells SteamVR to add 2mm to the actual IPD value! (the equivalent of the ‘Bias’ value in my request here: [FEATURE REQUEST] Cockpit Size and World Scale in VR )

1 Like

Oh wow I wasn’t aware the ipd is what was causing that I’ll give that a shot thanks so much!

1 Like

It might be useful to start with reviewing what the ideal situation looks like (i.e. a an making framerate). Here is a capture taken from the SteamVR Frame Timing wiki:

This starts out at half rate (e.g. 45 fps on a 90Hz headset, Present count = 2) on the left side, and then transitions to making framerate (90 fps on a 90Hz headset, Present count = 1). Also note the red line goes from 1 where Present count = 2, down to 0 where Present count = 1. This indicates in the half-rate portion, that one of the rendered frames was presented “properly” and then the second time it was presented using reprojection. Once the app starts making framerate, that red line drops to zero. This is the ideal situation.

The reason that the app wasn’t making framerate to begin with can be explained by the cyan (Ready For Use) line. This started out at 2 which means it was taking more than a single frame for the images to finish rendering. This might be because it was simply rendering too much, or it might be because the app started rendering too late. In either case, the result is the same. This then starts to jump between 1 and 2 and finally settles on consistently finishing on time (value = 1).

You will notice, however, that it is still several frames before things drop to ideal (Present = 1, Reprojected = 0). This is explained by looking to the top “CPU” section of the graph. The cyan “Throttle (frames)” line there was at 1. That means the SteamVR runtime had detected the app wasn’t making framerate and started throttling it (i.e. dropped it to half rate). This only resolves itself once the SteamVR runtime sees that the app is consistently delivering frames and relaxes the throttling (value drops to zero).

Now let’s take a look at your first image (v1.14.16 on Runway):

Here we see the sim presenting each new frame three times (white = 3). This corresponds to an effective framerate of 30 fps (since your headset is running at 90Hz… 90 / 3 = 30). However, the red line is also at three, when we’d expect it to be two. This is because every single frame that was presented (i.e. displayed in the headset) had be predicted to the wrong future time and required reprojection to compensate.

If you look back to the “CPU” section, you’ll see that most frames have only been predicted 1 additional frame out even though we know the app is running at 1/3rd rate. Prediction in this version of SteamVR is totally bugged for OpenXR apps it appears. This is corroborated by the v1.15.11 patch notes:


What’s even more concerning is the cyan “Ready For Use” line which is hovering around 5 (+/-1). The app is rendering at 1/3rd rate, but it’s taking on average about 5 frames for each one to finish? How is that possible? I find it useful to draw a timeline here.

Because the app is pipelined (i.e. the next frame is being simulated while the current frame is being rendered), it can deliver new images in this case every three display intervals, while the latency on how long it takes to render (cpu + gpu) is closer to five display intervals.

If we look at the in-game stats, we see the Main Thread reporting ~22ms while the Render Thread is a little over 30ms, and the gpu is about 32ms.


Perhaps more concerning is that even though the images are finished rendering, they aren’t actually displayed (the green line “First Viewed”) for an additional frame. That makes me think something is particularly broken with v1.14.16’s implementation of OpenXR.

Normally, the only reason the green line would be higher than the cyan line is if the frame was over-predicted. OpenXR does not allow displaying images early. If an image is finished rendering earlier than it was predicted to, then the runtime is required to hold off displaying that image (and continue to use the previous image). However, we’ve already established that these frames are getting under predicted (the yellow line on the cpu graph). Digging in a bit further (I’ll spare you the details) this appears to be a bug in SteamVR related to the prediction being off. In any case, it’s not a situation you want to be in.

Interestingly, we also see this in your 1.15.16 capture:

My suggestion would be to try to get that cyan line down to 3. SteamVR doesn’t really handle running slower than that well. Step one would be to reduce your gpu usage. During take off, you’re already over the 33ms limit for running at 1/3rd rate, and that presumes your cpu is able to deliver frames within the “running start” time the runtime provides.


The red bars you see in the CPU portion of the SteamVR Frame Timing graph are labeled Late Start. This is a clue that your cpu isn’t able to deliver frames in time, and that red bar is showing how much time is eating into your gpu rendering time.

Hopefully that helps some.


I tried the new Nvidia driver. In SteamVR 1.15 there were noticeably more stutters than the 457.30 driver, however I was getting an ever so slightly higher framerate (avg. 32 vs. 30) and I think there was an improvement in visual fidelity. It seemed slightly sharper and less washed out in my Vive, but to be honest I am not 100% sure this wasn’t just a placebo affect.

I then tried the new driver with SteamVR 1.14, and there were close to zero stutters. Framerate seemed about the same, however the new annoyance in 1.14 is that reprojection rendering sometimes seems delayed. This is causing a very subtle but weird distortion in the cockpit, like a lensing effect, when I turn my head and look out then back in. I’m also briefly noticing black bars at the periphery of the image while turning. I should note that Motion Smoothing is off.

The awesome thing I’m finding with the new driver and SteamVR 1.14 is that in the C172 world scale is now perfect! It is slightly too small in 1.15. The interesting thing is that this also fixed a similar world scale issue in Elite Dangerous that I’ve lived with for years. I have to say the slight change in scale makes a huge difference in immersion.

Overall I would say that the jury is still out as to whether I’ll stay with this driver on 1.14 or go back to 457.30 on 1.15. I’ll have to live with it for a couple of days to see if the positives outweigh the negatives. Also, thanks for the post on the IPD setting in steamvr.vrconfig. I had no idea that it existed, and if I do revert to 1.15 I’m going to see if this fixes my world scale issues in that version.

1 Like

Thank you for all these details, it is indeed showing we’re all surfing on a moving target, not only FS2020 but also the SteamVR and NVidia drivers. It is sometimes like trying fitting a square shape in a disk hole…

On my end I continue using 1.14 with 457.30 for now, but I’ve been much more using the G2 than the Index lately, because I can at least with the same settings (even raising Terrain LOD back to 100%) use the G2+Reproj at 90fps/30hz in most areas and aircraft (with TAA 60 and OXRSS 65, about 1.55K x 1.55K rendering and 2.5K x 2.5K displaying), and sure enough it is making a difference.

But I do miss the immersion and robustness of the lighthouse tracking when I use the G2 and the difference is really dramatic, despite most claiming inside-out tracking has made huge progress (sure, when there is CPU and GPU left to handle it I’m sure it is fine, but in practice when all your resources are already sucked up by NVidia driver bugs and FS2020… Why can’t they just release the Index v2 with the G2 panels… argh…)


The night is busy!

Good news:
PSA: NVidia has found the root cause of stuttering and VR performance in their drivers!

And a new SteamVR release candidate:
SteamVR Beta Updated - 1.15.17

  • Reduced GPU memory usage.
  • Added workaround for very low framerates for some combinations of graphics cards and drivers.

Update on SteamVR 1.15.17:

I’ve tried it out with the Index only (not with the G2) and I find it is still much worst than linux_1.14, causing more stutters and not necessarily better fps either.

When reverting to 1.14 and while at it, I’ve tried also raising clouds, building, trees, vector data to ULTRA because some are reporting they get smoother VR experience on the Oculus at 18Hz in raising all to ULTRA. I’ve been doing this over an Hawaii island to try out with a lightweight scenery and I honestly can’t repro the
“smooth” experience with the Index on my test system in these conditions…

However I was quite astonished looking at the fps counter and seeing how fps were dropping asymptotically to 30fps while raising this or that setting to ULTRA one after the other until reaching the point of a violent drop below. This is expected because the rule in VR API implementation is most likely to lock the frame rate to an integer divisor of the headset refresh rate. However this also tells me my base settings which I tuned for 30fps in a dense photogrammetry region are delivering as expected too.

Nevertheless, I’m also running linux_1.14 at 120Hz with the Index now and this seems giving me a much better experience, like I’ve explained in another post above, because SteamVR is trying to re-reproject the rendered frame over an higher number of displayed frames in the headset and I find this reducing considerably the juddering (still there of course, but less annoying when moving the head in the cockpit).

1 Like

Hi, I finally got around to trying tab key in vr and nothing happened. Any ideas.

You might want to start the official “readme” publications?

Starting with:
[Read First] VR FAQ - Virtual Reality (VR) - Microsoft Flight Simulator Forums
How to activate VR in MSFS – Microsoft Flight Simulator Support (

Are you sure you didn’t bind TAB instead of CTRL+TAB to switch to VR for example? You might want to review all your key bindings for anything using TAB Otherwise you can file a bug report (zendesk) and/or VR > Bugs forum.

Look in: Options - General - VR Mode
The VR - Toolbar Toggle binding is displayed there.
Remember, you may need to click on the active flight sim window after initiating VR to get the window to respond to keyboard commands.

1 Like

Thanks. There was no key assigned to toggle the toolbar in settings. Once I assigned it it works fine. I thought posters were saying that tab was preassigned to toolbar and it wasn’t . Thanks for your help.


You’re welcome. :slight_smile:

First of all, I want to thank you for sharing all this info and knowledge of yours. Much appreciated!

I recently got a 3090 and finally, I’m able to test it out in VR mode in MSFS. Haven’t been able to launch the game since it was released in end Dec due to the issue described in this post.

Now when trying to find the best balance between smooth performance and good visuals, your posts on this topic is super helpful!

I have one question though straight away. You say the recommended Nvidia driver version in VR for 3090, 3080 and 20XX cards is 457.30. However, further down in your post, the minimum version required for the 3090 is listed as 457.38?

1 Like

Thank you for your kind words!

However I’m listing 456.38, not 457.38:

What NVidia Drivers are recommended for VR

1 Like

Clearly I need to read more carefully before going through the rest of your good stuff.

Thanks for opening my eyes :blush: