Thank you for all your efforts! It’s good to at least have a solid base line to start from. Currently I’m running a 3080, 8700@5ghz and 32 gig of Ram on a Quest 2(G2 on the way). My results have been mixed I’ve tried Steam Wireless and Oculus link. Time to start from scratch with your settings.
@Toekiller Thank you for your kind words! With this system you should be more comfortable than with a 2070S. Let us know if these suggestions are of any help on your system.
Please note though, there is a performance problem with all NVidia drivers lately. Some are reporting any driver since 451.48 included are causing stuttering and lag spikes and I’ve posted in this discussion some of my findings and mitigation. However I believe the issue is rooting way lower in the system into the new HAGS feature.
The latest driver pre-Win10 2004 (hence without HAGS mode) was 446.14:
I’ve tried these last weekend but I felt like it was overall giving less fps, but this might also be related to the SteamVR version which is causing a certain number of performance problems since 1.15.x
Unfortunately, this doesn’t seem to work with the HP reverb. SteamVR shuts down as soon as you go into VR mode and if you try and turn on SteamVR, it shuts down MSFS.
You might have missed something in the process. Another user is having great success with this:
Just responded to their post, will try to get clarification, thanks!
I tried a few things tonight and my results are as follows:
Changing the SteamVR openxr from WMR to Steam was a no-go for me, unfortunately. At 70/80 TAA and even only 100% SteamVR SS, the FPS was single digits. It was also very unstable and every time I exited VR, MSFS crashed. Switching back to the WMR Openxr immediately remedied both of those issues and I was back to my 23-39 fps in the airbus.
I tried rolling back to 457.30 and then re-installed the latest drivers; FPS was identical in both cases for me
Unfortunately, it seems I am going to be stuck in the 23-29 fps area for awhile with your recommended settings that include the 80 render. It is fine, as everything is clear and gameplay is smooth (most of the time). However, I am concerned that when we are finally able to use add-ons (such as navigraph and vatsim) that the toll, in the game’s current state, is going to be too much to have a good experience.
Thank you for sharing your tests and results.
I’ve been doing some more flying yesterday with the A320 over EDDF in trying to spot whether there would be something else to tackle. I’ve for example disabled PostProcess > Sharpen to see whether I’d gain more fps if everything is set to 100% (TAA + SS). It is marginally giving a little more and this was more noticeable to me when trying TAA70+SS150 where, although a little more blurry, it appeared smoother sometimes.
During the A320 @ EDDF test though, I’ve noticed something odd: in doing fast bank left/right, when looking outside the left, it was really nearly butter smooth always but when looking to the right, it was updating something like 10fps (no fpsVR, just from the look of it). This made me wondering what is the difference besides scenery so I turn 180 deg and again same thing.
It turns out when looking to the right you have a lot of EFIS in view whereas to the left there is none. And here came a surprise: changing the Gauge Update rate from Medium to Low exhibited even more stutters! changing it to high nearly eradicated these stutters and restored an even fps.
My understanding is this: in lowering the gauge refresh rate, FS2020 is rendering all EFIS at once say at 5Hz. This means it is rendering the whole 3D fine and every so often a burst of EFIS rendering intervenes and maybe because this is badly scheduling into the FS2020 task scheduler it is taking a whole lot more ms than the frame budget. The renderer is then waiting for the EFIS rendering completion until submitting a new frame to OpenXR and this is a missed (or more) frame(s). However when set to HIGH, the EFIS is constantly overbudgeting the frame time budget and the renderer is always missing every other frame mostly, with the result being you get a more even stream of frames. In effect, this would resemble this:
#: frame, E: EFIS, !: missed frame budget (= stutter), *: display LOW : 0, 1, 2, 3, E, !, 4, 5, 6, 7, E, !, !, 8, 9, 10, E, !, 11, ... VIEW: *, *, *, *, ., ., *, *, *, *, ., ., ., *, *, *, ., ., * HIGH: 0, E, !, 1, E, !, 2, E, !, 3, E, !, 4, E, !, 5, ... VIEW: *, ., ., *, ., ., *, ., ., *, ., ., *, ., ., *, .,
This explains to me why you always get better performance with analogue cockpits in general because there is less load due to rendering using the Coherant GT tech (see my comments below), but what matters most in VR is constant fps rather than high fps as we can see FS2020 is fluid enough at 30fps in VR as long as there is no stutters.
In choosing Coherant GT for gauge logic and display, FS2020 is having a capable universal solution for UI which is scriptable and easy to deal with for creating new gauges more easily but this makes me wondering this is not as well impairing the performance we can really get out of the AAA rendering engine Asobo has created: Coherent GT - create stunning game UI faster and easier than ever
For example the way I’d do implement EFIS rendering would be using a round-robbin fashion so that you’d only refresh 1 screen at a time, not the whole 6 in burst in the A320. This would spread out the load over multiple frames and would be unnoticeable from the user. In LOW, it would be 1 at a time, in MED it would be 2 at a time and in HIGH 3 at a time with ULTRA all at once. The problem is I’m not sure the Coherant GT tech would permit them doing so easily or even if the JS code they’ve built upon Coherant GT and serving as the foundation block of all other gauges and systems is even coded with this kind of optimizations in mind.
I’m not much concerned with the ability to use add-ons, but I doubt the implementation from being able to offer much more than this and I hope I’ll be proven wrong. For airliners, Asobo is focusing much exclusivity to a single 3rd party vendor for the time being who is most likely concerned to offering the first airliner to the market place, and Asobo is using this vendor expertise as their main, if not sole, source of knowledge about what it is needed in the gauge and system SDK. I’m certain all add-ons will be as capable as their airliner, both for its good and its bad, no more no less either. Kind of a “we believe every vendors is doing like them, because they’re doing this for a long time and selling a lot, therefore, this is how all other vendors must and should do their aircraft”.
Having said this, I’m about to test the 446.14 again and see what it gives though. This is unrelated to Coherant GT limitations I’d like to really see whether the NVidia VR only stutter bug in more recent drivers is really that much of a problem with FS2020 now that I can reduce the simulator stutters with a HIGH gauge refresh rate.
This is an update since yesterday. I’ve now tested 446.14 again and there was not a massive increase in fps in VR an pretty much the same stutters overall, therefore, I’ve reverted back to 457.30 (HAGS OFF, Game Mode OFF - I’ll need to make a few more flight with both ON and compare again)
However I’ve further tested out different situations with Gauge Refresh HIGH and in general I get smoother, albeit slightly lower, fps. Everything for now is pointing to the EFIS screens refreshing once in a while in burst, and when they do, they take so much CPU the render is skipping frames and causing stutters. However when set to HIGH there are more or less constantly updating and although they are taking more CPU per sec on average (more frequent updates) the renderer is more constant in presenting its views to the HMD (this resemble the pattern I’ve posted above).
All my tests are indicating there is a direct relation to the EFIS rendering resolution to the overall stutters. Furthermore the EFIS screen resolution depends on the Post Process resolution (the SteamVR SS value) and not on the Render Scale resolution (the TAA Render Scale value) I believe this is a bug in VR. In effect, in 2D it seems to depend on the TAA Render Scale only. This means for now you only get two choices:
- Lower EFIS rendering resources to increase fps.
use TAA < 100% and SS > 100% giving good scenery/cockpit with blurriness on the EFIS.
- Crispier EFIS rendering visuals.
use TAA = 100% and SS <= 100% giving sharp EFIS drawings but blurry scenery/cockpit.
I’m even wondering if Coherant GT rendering (EFIS) is really hardware accelerated. In effect, when it is updating in burst the most affected graph is the CPU. This could mean the CPU is busy drawing the texture which will get updated to the video card, otherwise it is hardware accelerated and rendering on the video card but in this case I’m wondering why is the CPU is so much used when they are updating.
Please note in my flights where I was changing SteamVR SS and TAA Render Res I was trying to keep similar effective resolutions (close to 2K x 2K) but it is mostly when I was having the best EFIS legibility (TAA 100) I was having more stutters unless reducing SteamVR SS so much.
As a matter of fact, today I’ve tried pushing this further: SteamVR SS 200% and TAA 70% (or 60% depending). I can tell you outside view was stunning with lots of details, and the 200/60 combo was still giving me enough legibility (just at the limit when using 60%) flying over EDDF in the A320.
Nevertheless there was really not much stutters and it was overall a good experience fps wise. This is to me confirming the EFIS drawing technology is really taxing the resource much more than expected and the more you can reduce their impact the better.
this will conclude my tests today and I’ll wrap this all up:
- Glass Cockpit Refresh Rate is the main source of stutters (see my 2 posts above for details)
- My test system (9700K + 2070S) is perfectly capable rendering VR in 3K x 3K with SteamVR at 30fps (see below)
- HAGS is killing VR with NVidia 457.30 and SteamVR 1.14.15.
So let’s be quick and to the point: I’ve just had the 2 best flights I’ve ever had in FS2020 VR tonight!
You can try this too in doing this:
- Disable HAGS and reboot (mandatory)
- Disable Game Mode
- Use my FS2020 settings
- Set Terrain LOD to 50% (didn’t try 100% tonight)
- Set Glass Cockpit Refresh Rate to HIGH
- Set all VR Traffic sliders to 10% except Road Vehicles to 50%
- Set SteamVR Super Sampling to 220% and FS2020 TAA to 60% and Motion Smoothing disabled.
|FS2020||SteamVR||Render Res.||Post Process Res.||Comments|
|TAA 60%||SS 220%||1792 x 1992||2988 x 3320||breathtaking visuals and crisp EFIS|
This is massive pixel amount (see table) giving lots of details in the scenery and ground textures. EFIS are nearly as legible as the TAA100/SS80 I was recommending before, and are better than with TAA70/SS150. But that’s not all: I get smoother and more regular fps with 60/220 now that I’ve set gauge refresh rate high and HAGS off.
I’ve been flying around KSNA with the DA40NG and the Scattered Clouds preset with online multiplayer and this was just great, both daylight and night. I’ve also been flying around EDDF with the A320 and the same clouds preset but there I just needed to lower Volumetric Clouds to LOW in order to get similar smoothness.
Here is a screenshot at KSNA I couldn’t help sharing:
NB: I know 30fps seems quite low but my experience shows what matters most is not the “best fps” but the “stutter free fps” instead, and a constant 30fps with no stutters feels really good in FS2020. This looks even better than this screenshot in the Index headset!
NB: although it was the smoothest experience I’ve got, I didn’t measure with fpsVr (because it seems these tools are inducing some stuttering in the recent NVidia drivers). It was only a “feeling” and therefore it is also subjective, but after flying so many hours comparing settings and visuals I can assure you this is not placebo on my system. The only stutters remaining were the ones most likely from the NVidia drivers. With the A320 I could see from time to time a stutter every 1 sec, like clockwork, otherwise some other times it was most likely loading something. Otherwise there is still perceptible stuttering when turning, more or less varying in frequency, and I’m starting to suspect the EFIS code refreshing in the background and causing this (especially the navigation logic JS code shared among nearly all gauges).
Please let me know if this is also giving good results for you!
Thinking outside the flight sim envelope!
Bad performance? Increase settings, I like it.
I went back to High on glass cockpit refresh rate, and it seems the judders are less looking out left on 787 / A320 / CJ4 / G36.
G1 on WMR / 9900ks @5.0 / 2080S hybrid / 32GB
update: I’ll be posting a My 2070 SUPER VR settings and suggestions (Reverb G2) in the coming days!
I have a Reverb G1, should I run it with SteamVR or just wmr?
You might want to review this discussion instead:
Don’t set location of OpenXR runtime with the registry, use OpenXR Loader Specs instead - Virtual Reality (VR) / General - Microsoft Flight Simulator Forums
I just checked and mine is set to the right wmr location, but wmr doesn’t have a SS option like steamvr, performance is quite poor with a 2070s and reverb g1, will wait for your suggested settings.
Thank you! Have a laptop with a 9750H and a RTX 2080 Max Q, Quest 2. Will let you know how it runs! I’ve been having some performance issues with the game but I dont care for them as this is a great sim.
Wow, can’t believe your settings!
I’ve got a RTX3080 with Rift S. Tried first with TAA 100% and SS 150% in Oculus-Tool. It was great but the wide view was not clear. Then i found your post and tried nearly your settings TAA70% and SS 220%. Now it’s unbelievable grat and clear!
Can you explain, why it’s such a huge difference?
Psuedoscience. All you need is latest drivers and in-game settings. Also mate with all respect this is longer than a novel, can’t you summarize?
Furthermore the EFIS screen resolution depends on the Post Process resolution (the SteamVR SS value) and not on the Render Scale resolution (the TAA Render Scale value) I believe this is a bug in VR. In effect, in 2D it seems to depend on the TAA Render Scale only.
The idea is to maximize the gain thanks to the superior CAS Shader. The performance gain (per displayed pixels) using TAA 60 (vs TAA 100) is higher with a higher Post-Process Res because the ratio between the CAS Shader process pixels vs the Rendering Shader pixels is higher and quadratic. In effect, it takes a tiny amount of pixel shader time to upscale the image whereas it can take 100 times more to rendering the same pixels at the upscale res.
Because the CAS Shader is in effect “creating details” it is compensating to some extent and you can counter-balance the loss with a certain ratio TAA/SS for a specific HMD panel resolution. With the Valve Index it is really doing wonders at these settings.
I’m preparing a similar discussion for the Reverb G2 and with it I’m torn between TAA60+SS100 (which is 3172x3100) and TAA110+SS50 (which is 2244x2192). In both cases I have stutter free 30fps, the former is a good overall balance, the later is sharper on EFIS (exactly the same type of cost/benefit I have with the Index)*
It will take you less time to read it all than me writing it up.
*this requires using the latest OpenXR Dev Tools in order to change the OpenXR “Recommended Resolution” to 50% (2244x2192). NB: this is what shows as Post-Processing Resolution in FS2020 fps window.
Thanks in advance! In a few days/weeks, when my Reverb G2 arrives, i will also try your settings you mentioned. Really good work!
Would this be the same as setting the new render scale in openxr dev tools to 50% or is that something different that nobody has really explored yet? (Reverb G2)