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.
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.
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…)
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).
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.
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.
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?
Hi, Just sharing my experience. Had everything running great in VR with CptLucky8 suggestions, then made the mistake of trying nVidia driver 461.09 with Steam linux 1.14 and EVERYthing went to H**L. Horrible stuttering in VR and screen mode… Basically unplayable. I have been reading all the complaints on this forum about how bad things could be and was grateful I had never had such terrible experiences, but 461.09 showed how bad it could be. Also, I don’t know if related, after I updated Nvidiia driver, rebooted and started FS2020 it made me reinstall the last update. Thought that was the problem, but after doing a clean install of 457.30, everything back to normal.
Hi @CptLucky8 i @CptLucky
Could you please provide any more info on this setting? Following your guide and using the linux driver for the index i can now average 47fps on my 3070 10thgen i7 with everything on high/ultra and the Index HMD set to 120hz. It plays so great now its amazing. Airliners a a litter stuttery but I usually only fly light aircraft anyway.
I am finding that the scale of the cockpit is well off using this driver but I cant find this exact config file in the location you mentioned. I did find one with a similar name that had a bunch of resolution settings and refresh rate but i could not see a line for the ipd offset.
Thank again for all your amazing info on this forum.
I’m updating the OP from time to time not only when I’m making new suggestions, but also in keeping a wish list of bugs and features you can vote on. If you don’t happen to revisit the OP from time to time, here is the current list.