It seems to vary system to system. It killed performance for me on a 2060, but I’ve known other people that have the opposite experience on other builds. I haven’t turned it back on to test since upgrading to a 3080, though.
As mentioned, HAGS seems to vary per individual system. I have always found there to be minimal difference ON vs. OFF but in general have experienced slightly smoother performance with it left ON.
I should preface by saying I am flying in VR using a Reverb G2 which is much more demanding than just flying 4k, so if you’re flying flatscreen you can likely bump these settings ups.
Render scaling I set at 100
Terrain level of details is 150 (200 if not in VR) This along with render scaling is the single biggest fps killer
Object LOD is 100 (I cannot notice any difference in VR raising this setting, objects pop in the same)
ULTRA SETTINGS
Off screen terrain pre caching (any lower and you will get vegetation pop in when looking around)
Terrain Vector data (has no impact on performance that I can detect)
Texture resolution ( this uses memory and the 3090 has plenty so keep ultra)
Texture synthesis (no visible impact on performance so keep at ultra)
HIGH SETTINGS
Buildings
Trees
Bushes
Clouds
Water
Reflections
Windshield Effects
MEDIUM (shadows produce shimmer in VR so lowering them gives me better visuals)
Contact Shadows medium
Shadow maps I024
Terrain shadows 512
Ambient Occlusion I turn off completely, waste of frames
As I fly in VR I set my fps to 32 and use motion reprojection to get to 90 fps simulated. As long as MR locks at 30 I get no artifacting at all once I’m flying, I also use the propeller mod on flightsim.to
If flying flatscreen I lock at 58 as I use a 70 inch 4k 60hz TV, but I am only flying VR these days.
Thanks to MR giving really good results in VR nowadays I subjectively experience a smooth 90fps sim with no stutter any more.
My setup is
10850k
32 GB 3200mhz ram
3090
1 TD Windows Nvme drive
Sim on secondary 2 TB Nvme drive
Reverb G2 VR headset
4 Likes
Are you sure you were actually CPU limited, and not just that it was a false ‘limited by main thread’ report?
The thread below discusses this in relation to using OpenXR in VR. I only fly in VR so don’t know how it works without, but mbucchia who is extremely knowledgeable gave some great explanations in this thead. I’ll copy and paste some of his discussion below the link. Basically the CPU main thread actually includes the waiting time for the GPU to finish executing the computational work that CPU instructs, so the CPU is sitting idle but reports limited by main thread. I do not claim to understand any of this myself I have to say!
I think you are reading the statistics incorrectly. I was just discussing this with @RomanDesign by PM, but I will explain it here too.
You can use the OpenXR “Display frame timing overlay” (see Developer Tools) in order to confirm everything I am about to say below.
The stats in the OpenXR overlay will show you 3 lines:
App Cpu/Gpu ← This is the workload of FS
Pre Cpu/Gpu ← This will always read 0 for now because the game does not submit depth buffers
Post Cpu/Gpu ← This is the workload of the OpenXR runtime, in this case the Motion Reprojection.
Based on the numbers @RomanDesign shared with me, it appears that App Cpu is basically just a little bit more than what the other overlays calls “RdrThread”, here 13.4ms. These values are directly reflecting the amount of CPU time used to submit the work to the GPU.
So if you look at your values here, we have RdrThread being 13.4ms, and OpenXR App Cpu was about ~15ms. This number is the CPU utilization for rendering a frame in the game.. Now 15ms, that is technically low enough to drive up to 60 FPS. Yes 60 FPS.
Now you look at the App Gpu number. This number matches the GPU time you also see in the other overlay. In your case, here, you see 27.4ms. This duration is low enough to drive ~37 FPS.
So very clearly, you look at those 2 numbers above:
- CPU can drive 60 FPS
- GPU can drive 37 FPS
You take the smallest one out of the 2. This is the GPU one. You are GPU-bound.
Q:
Nope. You can go look at the statistics I mentioned yourself. Post Cpu/Gpu, on my machine at least, is reading less than 1ms on CPU (so basically nothing) and 4-5mis on the GPU.
Q: OK so what the heck is this “Limited by MainThread”?
I cannot answer than with certainty, because only the developers can. But I can give you a very reasonable guess and explanation.
The time shown as App Cpu is the duration between the game calling the “beginning of the frame” and the game submitting the frame, ie “finish of the frame”. This is the time the game is actively busy doing computational work and writing commands to the GPU.
There is however, another step involved in this frame rendering process: the “waiting to begin the frame” step. The MainThread duration observed in the overlay is likely corresponding to the duration between the “waiting to begin the frame” and “finish of the frame”.. Yes, you just read it. Read it back. This MainThread timer is including the “waiting” phase. During that phase, well, nothing happens. The game just waits. It does not use extra CPU.
This is also why the MainThread time is reading ~30ms in your screenshot, because 30ms is about 30 FPS (there’s always a few milliseconds of overhead/gap here and there, so just ignore them).
Q: Now wait, why 30 FPS? Why not 37 FPS?
These questions are all answered by looking at the principle of reprojection. VR headsets are best driven at the same rate that their display supports. So for example with a 90Hz display, you want to send an image 90 times per second, and this timing must match when the display will start showing the image (the “scan out”). Why is that by the way? This is because it takes several milliseconds for a display to fully illuminate all the pixels making up the image. So when you want to reduce latency, you want to produce an image as close as possible to the beginning of scan out.
For reprojection to be able to match the display rate mentioned above, it is easiest to lock the app framerate to a rate that is divisible of the refresh rate. This is why for your 90Hz display, we will try to lock at 90 FPS, or 45 FPS, or 30 FPS, or 22.5 FPS. This way for each frame, we will either do (respectively) no reprojection, 2x reprojection, 3x reprojection or 4x reprojection.
Q: And also why waiting, this sounds stupid?
In order to lock onto the frame rate chosen above, we must throttle down the game. This means doing a wait. There are 2 paradigms when implementing a wait: 1) the so-called “active wait” or “busy loop” and 2) the sleep.
The 1) as its name indicates is actively using the CPU to perform the wait. Literally, the CPU core will be executing these instructions called NOP (No Operation) and check for the desired wait condition to be over. When doing that, nothing else runs on your CPU core, and the wattage/temperature will go up, because a busy loop is effectively using 100% of your CPU core. Active wait is bad, and typically not used in high-performance applications.
Option 2) is what OpenXR implements. When the game is waiting for the next frame to lock onto, the game thread performing the wait goes to sleep. When it sleeps, two things may happen:
- Another thread is executed, effectively allowing other tasks within the application or other programs on your system to run.
- If no other thread is eligible, the CPU core will go into a so-called halt state. In the halt state, the CPU core will not do anything, and this effectively lowers wattage and heat. This is what you sometimes sees referred to as the “idle thread”.
So for short, this wait between the RdrThread’s 15ms and the MainThrThread’s 30ms is 15ms of sleep, where either the game will decide to do something else (like downloading something, or doing physics, or audio) or the system will just go idle.
In all cases, you are not CPU-bound. Wait is good. Wait means you have headroom.
Q: Wut?
Limited by MainThread, in the circumstances described above, does not mean limited by how powerful your CPU is.
Here, Limited by MainThread is a reflection of the OpenXR runtime throttling down the game to lock onto an optimal Motion Reprojection rate. This optimal rate is determined by looking at both the CPU and GPU load. In the case reviewed above, the bottleneck is the GPU.
To quickly find out if you are truly CPU Limited, take a look at RdrThread and GPU time. The higher value of the two indicates whether your CPU (RdrThread is higher) or GPU (GPU time is higher) is the limiting factor.
2 Likes
You should give Open XR Toolkit a try, it’s a game changer for VR as it has FSR implemented:
And Ambient Occlusion is not a waste of FPS, especially if you fly low as it completely changes the buildings lighting/shadows from totally lit and meh to realistic and wow. 
512.95 latest drivers as of now.
Working fine, Windows 11, RTX 3080.
It does annoy me how it turns off my HDR every time i install a driver.
I already use the OpenXR toolkit, and I agreee FSR is better than NIS for sure.
I’ll give the ambient occlusion setting another look.
2 Likes
So I tried ambient occlusion, and I agree it does improve the shadows a bit. I tried low and medium, but I noticed my fps for MR was dropping below 30 which I hate as I want it locked to 30 fps to minimise artifacting.
Interestingly when I turned it off again though my fps was still dipping below the 30 fps lock. The last time I did my fps check was just before SU9 I think and it stayed at 30 fps locked the whole time.
I’ve updated the Nvidia driver since then as well so maybe it’s one of those factors.
It didnt’ noticeably affect my performance in a negative way but it still annoys me!
What level AO do you set? Off to low was more noticeable to me than low to medium and I didn’t try higher, so I might just stick it on low to get some AO without comprimising my performance too much.
My AO setting is on Ultra with a 5800x and a 3090 RTX (Quest 2).
1 Like
I just thought I’d mention to the group that I have been having many CTD’s of late and most of my flying has been in the PMDG 737. I’d sometimes have 2-3 CTD’s consecutively and that’s before I’m even in the cockpit.
I just realized this morning that I’ve not had a single CTD since the 512.95 update. Just sharing my personal experience is all, not making any claims of greatness.
2 Likes
I was hopefull myself, but last night 3 CTDs in 30 mins with 512.95
For me it all started with SU9…
You could attach an event log from the Windows event viewer … so you understand a little more.
With the previous version, I was seeing in the Event Viewer errors related to a Nvidia .dll, but now I am only seeing the 0xc0000005 error.
I tried lots of different solutions (including formating my PC twice and using a separated NVME to install MSFS).
Sometimes I am able to complete a 6 hours flight, sometimes I have a CTD in 10 mins.
It is less stable than when I was running with SU 8 (not CTDs at all).
Error code 0xc0000005 could be caused by various reasons in a Windows PC like bad or low RAM, malware infection, corrupt registry files, wrong hardware configuration, etc.
You could try this Tool especially option 6 and 7 in case you find any errors following 8, 9 and 10
Yeah, I used a few tools like this as well.
Today I updated my bios, and all the drivers.
I also connected my pc directly to the router using a cable!
So maybe today is the day?
I am using a brand new instalation of windows 11 that only has MSFS 2020.
Instalation of MSFS is in it’s own NVME (1TB PCIE 4.0)
Used DDU to reinstall the Nvidia driver.
Changed the page files, group policies, power settings for windows and GPU, disabled virtualization in bios, disabled SMT, running without a single mod, with rolling cache, without, with ai traffic and without, several different permutations of all the suggestions.
I eventually get the game running for 8 hours and everything is perfect, next time CTD while I am sitting in the cockpit loading a FLT PLN or whatever…
As I said before, never had this inconsistency with SU8…
I might end up eventually finding the issue, but before formatting last weekend I was playing Assetto Corsa Competizione and Automobilista 2 with VR and it works perfectly fine, so I would still believe that maybe MSFS could maybe be less finicky?
Have you made sure that your USB ports are not being put into power saving mode / going to sleep?
That is a guaranteed CTD sadly, ridiculous as it may seem. It can only be done reliably in Device Manager, changing the Power Management profile doesn’t work.
2 Likes
Hey!
Yes, I adjusted the power settings to not allow USB to sleep.
Said that, I had a 6 hours flight with Fenix A320 without a single issue…
Might want to check your network interface as well, windows was putting my eth0 to sleep on the longer flight.
1 Like
Ah, good one!
Adding to my list.
Thanks!
It could also be caused by the sim trying to access memory it shouldn’t. I play a lot of games, and I don’t have a single other game that crashes like this. I just finished 48 hours of Hardspace: Shipbreaker. 0 crashes. Black Skylands, 20 hours, 0 crashes. Star Control: Origins, 16 hours, 0 crashes. Ghost Recon: Breakpoint, ~200 hours, 0 crashes. Salt and Sacrifice, 38 hours, 0 crashes.
Asobo need to get a better handle on what their code is doing, and users messing around with USB drivers, or running memory diagnostics isn’t going to do that.
1 Like