I made this same observation about the even/odd numbered sim updates a couple of months ago. It makes me wonder if Asobo has 2 independent code batches they are working with, and that’s why we see huge hardware load swings each update, along with some “old, fixed” issues popping back up every now and again?
Are there any software developers that can weigh in on this being a possibility?
Directx 12 will do exactly that. Read this What is the Difference Between DirectX 11 and DirectX 12 | Hardware Times
It’s very dense, but you will get some key takeaways.
The point is DirectX 11 can never use multi-core CPU’s effectively. And has a very monolithic approach to rendering, due to the way it handles draw calls (draw calls are basically the directions to the GPU on what to do)
DirectX 12 should take a lot of the rendering load off the main thread, both by allowing the CPU to direct the rendering much more effectively, and with more threads, as well as moving the load more towards the GPU.
Key info:
DirectX 12 adds many technologies to improve utilization such as asynchronous compute which allows multiple stages of the pipeline to be executed simultaneously.
With DirectX 12, the draw calls are more flexible. Instead of a single global state (context), each draw call from the application has its own smaller state (see PSOs below for more). These draw calls contain the required data and associated pointers within and are independent of other calls and their states. This allows the use of multiple threads for different draw calls.
Each of the objects in DirectX 11 needs to be defined individually (at runtime) and the next state can’t be executed until the previous one has been finalized as they require different hardware units (shaders vs ROPs, TMUs, etc). This effectively leaves the hardware under-utilized resulting in increased overhead and reduced draw calls.
^all of this above stuff is related to CPU, as you can see DirectX 12 will allow the work to be broken up, and what’s not broken up can be done with One “direction” vs multiple with DX11.
Considering the massive rate of GPU improvement, I would much much rather be GPU bound, the next generation Nvidia chips will be out by the end of the year, and very very conservatively will be 50% faster than this current gen.
If you look at the history of directx , every new version introduced performed so inefficiently, it made a hardware upgrade necessary. The next generation of motherboards will have pci-xpress 5X. DDR5 for Ram modules. The next generation of GPU will obviously be faster.
I agree with your statement 100%. Case in point is that the sim is clearly working just fine for many other players, which is why they are not here posting their complaints. How do you troubleshoot performance issues when not everyone is experiencing the same issues on the same hardware? Is it really an Asobo issue or a 3rd party issue? Or a combination? It’s quite daunting to take on something this complex, regardless of the size of a studio.
I don’t agree that it is an Xbox related issue like some believe. The specs, and especially the CPU, is more powerful than some PCs out there. Heck, with anyone with less than a RTX 2080 Super, the Series X out performs them. While the Series S is running the sim at medium to low settings at native 1080p 30fps. So no big deal. Most applications, including this one, doesn’t even make good use of anything passed 6 cores, let alone 8 or more. If anything, the speed of the CPU makes a bigger difference… at least for now. Which is why OC’d CPUs run this sim more smoothly then those with more cores but slower processors.
However, I do agree that not developing this sim from the ground up with DX12 in mind and THEN making it backward compatible with DX11, was a mistake. Not sure about the thought behind this decision. But going this approach would have at least addressed the CPU core usage issue much earlier on.
One thing will be certain. SU10 will NOT solve everyone’s performance issues and will another of many more updates to come. Systems are much to varied for that to happen. It will help many, some won’t see a difference, and others may be hurt by it.
I do have to give a lot of credit to Asobo for their frequent communication and constantly providing us with updates. They are clearly doing their best on trying to address issues
"… people are upset that they paid for the game and we’re basically using beta software … and that isn’t 100% fair. "
Nailed it.
I didn’t realize that. Seems odd to me that my mediocre systems runs the CPU at about 25-50% and the GPU at about 95% most of the time when in the current game structure and when sitting at a menu, of course the CPU is idling at about 10% and the poor GPU is still running at 95%.
…
I suppose the only people that really know are the programmers.
I have a hunch about the reason why Asobo hasn’t fixed current (DX11) performance. I think it’s because they are now focusing to work on DX12 implementation, which would solve current performance issues.
I hope my hunch is right. 
I haven’t got an xbox but I thought that its RAM was quite limited in comparison with a lot of PCs now which are running with 32gb or more. I would have thought that this alone could potentially have a performance impact.
I was dissapointed by this as well but then realised a flight simulator will never be finished. It can be more stable for sure. I think we can only tell what we think about it and report issues and then hope more than we has the same issue. The more that has the sme issue the more chance we have to get a fix for it. And maybe many more are using the sim with no problems and they will not be here complaining.
Yeah, I see this a lot. But there are other things to take into account. A console does not run anywhere near as many resources as a PC does. The memory bandwidth is FAR higher on Xbox SX than system RAM on PC, and being a console that is unified across all other SX consoles, optimizing for it is easier than PC, which can have thousands of different hardware combinations and 3rd party addons.
Also, it’s not like the sim is maxed out on the Series S or X. The internal resolution is lower on both consoles (1080p and 1440p respectively at mostly 30fps), graphics settings are a mix between low and medium on the “S”, and medium to Ultra on the “X”. Plus a lot of data is being streamed from SSD and network as required. All that plus the high bandwidth in memory keeps memory usage under control on console. Meanwhile, PCs can easily brute force memory usage depending on a systems memory configuration.
If less RAM, turn some memory hogging features off or lower the quality. If more RAM, keep those features on or at higher quality. RAM size is very important, just a little bit less important on an enclosed custom system like a game console.
That stat is meaningless. You need to see how it uses individual threads. OPen your task manager, right click on the CPU graph and select “show logical processors”. That will show you what each thread is doing. With MSFS running, you’ll see one pegged at near 100%, a couple with moderate usage, and others doing little to nothing. Depending on how many threads you have, of course.
That’s what 25-50% means. The overall capacity of all your threads. And that means nothing in terms of how the sim uses the CPU. What’s important is what that main thread is doing.
He says mediocre system, it’s possible the GPU is so bad even his lower CPU isnt being used waiting for the GPU as 25% is very low even task manager.
Not really. Could be an old i7 with 8 threads. 1 thread maxed out, a couple partially used, and the rest doing nothing. That would easily get 25-50% on an old CPU.
The point is still that overall CPU usage is a meaningless stat when talking about MSFS performance and CPU use.
If they can utilize every single core to be equally utilized in the future not many would need to upgrade cpu 
Maybe dx13
Yeah, but I don’t see that ever happening. This isn’t a workload that’s easy to run in parallel. DX12 may help them unload to other threads for effectively, but it’s still never going to get to that point. There will always be a master thread that controls everything.
Agree, well it would be good if Asobo could control the sim to not use 100% of mainthread. To me it almost never uses less than 100% even if i turn down cpu demanding settings. The 100% use of mainthread causes stutters. Feels like the load to other threads are transfered too late when the mainthread is already at full load.
Correct me if i’m wrong. If something is handled on a different thread, that also needs to go through the mainthread? That means it’s faster to have everything handled on mainthread that needs to be updated instantly? Only things that doesn’t need to be updated instantly is better to be handled on different threads?
To be honest, Asobo doesn’t have the ability to optimize performance and cores, it’s just a game to watch the scenery, and it’s just your feelings that kidnap you.
is anyone having “stuck in the loading screen” when doing a flight and back to the main menu for a second flight and the sim gets stuck in the loading screen? btw my comm folder is full of shhhhyyyyiiiiyt…
Honestly that’s what 100% of a thread is, once you hit maximal you begin to increase thread time causing the stutter.
As a test manager for a living I would not force users to use save mode but instead give them proper instructions on how to test. If some reports don’t stick to the plan these should be closed.
That’s how testing usually is also done on other projects - the test coordinators or managers can simply reject defect reports if they are not created properly (information missing), if something is a change request (aka. a “wish” which was not covered by any requirement) or if it does not reflect the overall test plan.
It’s totally fine if users got different configurations but they have to list as much information as possible in their reports. Also testing is about the core sim so they should at least try to retest their discoveries with default only stuff if they found any bug.
If a user for example has bad performance using the A32Nx mod he should try the same route after a restart using the default A32N. If the problem still exists a report can be provided, if not the issue might be with the mod.
