Smooth with no stutters in windowed mode.
4k, Ultra, Native, TAA, T LoD=600, O LoD=900.
64GB memory.
Still smooth with 16GB of memory used as a Ramdrive.
I didn’t know that!
My previous understanding was that Fullscreen and Windowed (with focus) should be the same, I didn’t realise Windows did some ‘behind-the-scenes’ things differently between the two. I thought that even when fullscreen, Windows still continued doing the other stuff out of sight.
MSFS2020 doesn’t ever play in ‘full screen mode’. What happens when you press ALT+Enter is it switches between windowed and borderless windowed mode not exclusive full screen mode of older/other games..
That’s a good point, unless Windows treats borderless-windowed like fullscreen it shouldn’t affect FPS for MSFS
Yes this is annoying.
Hi! One a qüestion. My pc is i9-12900ks, and 3080.
I would improve with a 4090 for VR? Thank’s
Remove ground stutters when I move my head left,right center
This is my life…. Amazing smooth and great fps, then the next day… boom studtters and poor fps…. No changes other than actual date…
For later Windows versions both modes are the same in terms of performance. Borderless window is now working as exclussive full screen as well but it needs to be the active window. I indeed have no degraded performance by playing games that support both modes when I select borderless window, and it has the advantage of allowing to click on other monitor without losing the main game window, which is something MSFS takes advantage of. True full screen does not allow it as mouse is captive on the main screen limits and you need to go to desktop or switch using ALT-Tab to operate mouse outside game. However it can be a problem in some situations as well, like the ones described in this topic, or when the mouse is going out of main window limits when you don´t want it. So depending on the game you may want to choose true full screen mode to trap mouse inside the main screen.
Cheers
Eric first you need to run the ‘dev mode’ in-game Show FPS tool and that will tell you if your framerate is CPU or GPU limited. I also have a 12900K (not sure about the s?) plus a 3090 GPU and STILL the tendency is for MSFS to make my game CPU limited. In that case getting a faster GPU will make no difference to the FRAMERATE/STUTTERS at all. This is the basic concept that the majority of gamer testers who just measure framerate while adjusting graphics settings totally fail to grasp. The situation is also confused because if the CPU is capping your framerate (not a good situation to be in) then upgrading your GPU does have absolutely marginal benefits in enabling you to increase some AA settings or whatever without reducing the framerate but IMHO this is largely irrelevant for the majority of people who have low framerate/stutters because of CPU limiting.
What I did, btw, was INCREASED my graphics settings (changed my left and right monitors to 4K) to increase the load on the GPU, until I became “limited by GPU”. This was actually a slightly LOWER framerate than the CPU cap (necessarily) but then there was less stuttering.
My suggestion is it’ll be the same for you in VR with your 12900K - first check the in-game Show FPS tool, and if you’re “limited by CPU” then try and improve that (mainly by disabling the AI traffic, and terrain/object LOD settings even down to 50, when you see an improvement you can edge it back up). If you can’t get MSFS away from “limited by CPU” then change strategy and try and improve your graphics quality settings to increase the graphics load (pretty much everything other than AI/LOD) until you’re “limited by GPU” as the frame-to-frame rendering will then be smoother.
If you are limited by GPU, sure, get a second job and replace that GPU.
Thanks for that. Most of it I knew but some was new.
just to clarify: NVidia DSR in the NVidia Control Panel an Render Scaling in MSFS both only increase the load on the GPU, right? So cranking that up should help me get GPU limited?
yes definitely, getting the sim to render across a larger ‘real’ pixel resolution is the main thing that drives the GPU as you suggest. It’s what I did moving from 1080p + 4k + 1080p to 3 x 4K. I was amazed to find that in my case it hardly reduced the framerate but it did enough to free up the CPU.
There are no magic settings because game scenery is so changing that you will always find a place where your optimal settings don´t work anymore. On the other hand you will be always limited by CPU or GPU. The graph shows which is of the two factors is worse than the other. The important info to read is the latency of the main thread and the GPU. If any of them is significantly higher than the other (for instance main thread is x2 the GPU one) there´s a relevant overload, a potential wrong configuration or just a limitation due to the density of the area or the design. However being limited by any of them, or even by the two can still produce a reasonable figure below 60 FPS.
When threads are below 16ms they can potentially produce a 60 FPS render (1/16 * 1000), if nothing else prevents it. The lower the value the higher the potential FPS and the other way around, following the same formula. However game currently runs a ton of tasks on main thread and that will most likely put you always on a CPU limited scenario, no matter what CPU you have, leading to stupid situations like GPU having less than 10 ms but main thread having 30 ms. That will put you on 30 FPS, that is what happens on ground at most big airports now, even if GPU could still render at 60 FPS.
In other cases the main thread just goes to 40ms without apparent reason and you see your RAM and VRAM usage is just at 50%. Everything works well on your HW and CPU/GPU usages are also normal. There a huge data dump is happening in one go. Again, another design problem as no system can handle 3 or 4 GB in one cycle (for instance the size of a CGL from a payware aiport being loaded). As that´s imposible the task starts to be queued into several frames, blocking the other pending tasks and leading you to 20 FPS for several seconds until that´s completed. But later on all pending tasks produce further delays (because they were also queued) until they complete, resulting in a giant bottleneck that can last even 10s. You can see how aircraft jumps or falls a bit as the physics are also having problems to be resolved in time. There´s simply nothing you can do to prevent it. The airport needs to load and that means loading it at full detail at some point and that will happen in one go if it has just one LOD as most third party ones, and the other tasks need also to be resolved because all run on the same main thread and there´s only one main thread.
The only real way to get rid of those permanent main thread limitations is to reduce TLOD below 100 so that scenery workload is so ridiculous than main thread can handle it, because all other things (weather, physics, sound, etc) are “mandatory to happen” at main thread, so to speak. But CPU is not the problem here, it´s the main thread design. It can´t go any faster because it’s a superlong list of scenery, physics, weather, ATC, traffic, etc that needs to be handled periodically. That´s simply too much to be repeated at every cycle or few cycles in the same thread. Anyway I don´t think reducing TLOD so much is a solution as the quality is really poor and you can see mountains or buildings as piramids at just 500m away in some cases. Traffic enabled will take 10 FPS itself, no matter the amount of AI. I don´t think disabling it is a solution either as you remove a relevant feature. But even in that case, with short viewdistances and no traffic, the huge data dumps cases won´t be solved and you will still see how main thread is blocked during several frames for several seconds, leading you again to the 20 FPS scenario.
Cheers
I think we need a more parallel hardware approach. It should be possible to feed the GPU not only textures and geometry at the same time but do this simultaneously from different CPUs, one handling weather, another one handling objects, a 3rd one terrain and something else by the 4th one. Configurable by the user.
Many thanks for your contributions here, they’ve been most helpful and interesting.
I really hope that MSFS2024 sorts this out, somedays I can fly a route and it’s stutter free at 60+ FPS, boot up the next day and it struggles to maintain half that doing exactly the same route and aircraft and stutters like an annoying stuttery thing.
Thanks for that, increasing my resolution to put more load onto the GPU seems to have helped a bit.
If history is any indicator, it wont.
… the traditional ‘solution’ is to look at the workload on the CPU and see if some complete processing sequence can be moved to other CPU cores. Asobo are currently suggesting exactly this which is a good thing to do but rarely produces the results you were hoping for. Actually all systems tend to have some single-threaded workload which is dominating the overall execution time, rather than a bunch of inconveniently collected independent workloads that can be teased apart. The gold solution is to re-program that bottlenecking algorithm into async components that can execute on multiple cores but that is quite a way beyond what you could expect in MSFS 2024.
That is kind of wishful thinking.
It is a linear application.
At Takeoff, throttle to max and raise the landing gear.
That’s pretty asynchronous.
But it will drop you onto the runway.
LOL in 2023 the CPU is bottlenecking at billions of instructions per second, there’s far more going on than just the flight model carried over from FSX when CPU’s were x1000 slower so I’d expect that to be a trivial workload unless Asobo really messed up (in fact Asobo scaled that algorithm up from processing a dozen surfaces in FSX to a couple of thousand in MSFS because it’s so lightweight).
Given the sensitivity of the CPU % to Object and Terrain LOD changes, I’d suspect it’s somewhere in that part of the processing that’s chewing up the CPU. Re-writing that specific code to exploit multiple cores is possible but radically raises the tech skills requirement which few people understand.
Microsoft should hire you.
I would pay more, much more, for that kind of Flight Simulator.