Anybody having the same performance issues with multicore systems?
Please optimize for CPUs with lower MHz and more cores.
I have a dual Xeon (e5-2687w v2) Workstation that is working great for games. Except for MSFs, which is utilizing only a fraction (10%) of the CPUs power. The games is “Limited by MainThread” which should not be the case.
DX11 only allows the use of 4 cores at all. I think we will see improvements within the DX12 release coming this summer.
1 Like
Well, I have seen in this forum lots of people saying that dx12 will not bring that much performance to multiple cores than people thinks.
It’s frustrating to me too, I have ryzen 7 3800x, and I know, it’s not the top cpu but not that bad too, and can’t handle with this Sim. So I don’t have much hope that dx12 will bring that much improvement…
DX 12 in general will not provide stutter free 60 FPS. All these discussions that were going on here turned into mad talking, that you don’t need 60 FPS and you will not get them anyway.
Here is something interesting, I quoted the important part below:
https://www.google.com/amp/s/www.hardwaretimes.com/what-is-the-difference-between-directx-11-and-directx-12/amp/
One of the core advantages of low-level APIs like DirectX 12 and Vulkan is improved CPU utilization. Traditionally with DirectX 9 and 11 based games, most games only used 2-4 cores for the various mechanics: Physics, AI, draw-calls, etc. Some games were even limited to one. With DirectX 12 that has changed. The load is more evenly distributed across all cores, making multi-core CPUs more relevant for gamers.
1 Like
This is incorrect.
That ‘Traditionally with DirectX 9 and 11 based games, most games only used 2-4 cores for the various mechanics’ does not mean that it’s a limitation with DX11.
MSFS has been programmed with multithreading in mind already, it’s just that there has to be a ‘main thread’ which keeps all the jobs that have been outsourced to other cores in sync (you can’t have the aero calculations done before the 3D graphics are. They all need to be finished and in sync before a frame can be sent to the GPU to process).
This main thread can only run on a single core (hardware limitations), and as such, good single core performance is important.
@CassimoTTV Sadly, the CPU you have was built specifically for heavy productivity workloads (like rendering, 3D modeling, video editing etc).
There’s currently no way that an entirely different type of workload (especially a complex sim like this) can be recoded to utilize all those cores.
DirectX12 will bring nothing to the table for you. The devs have already stated that DirectX12 will mostly provide some more visual eyecandy.
They did however find some optimizations while working on the XBox version, which will benefit PC as well. Expect those around this summer.
Currently a 6C/12T CPU is all you really need for any gaming or simming workload. Go up to a 8C/16T if you really want to future proof yourself. Sadly though, the simple fact is that a Xeon is a terrible CPU for gaming/simming workloads, and that’s not going to change soon. It’s just a completely different type of workload.
4 Likes
Yeah, I corrected my self with the website I posted (unintentional). They are saying that at least only 4 cores are used for various mechanics. Saying that it only uses 4 cores at all is incorrect.
In your opinion, what’s the best CPU (I’m open to AMD or Intel) to get today for MSFS? I’m upgrading that very soon and can use some good expertise:-)
AMD 5600X hands down.
I went with the 5800X myself, since I couldn’t find a 5600X, and the 5800X was in stock. That’s the only reason.
Couple it with some fast RAM (3200MHz minimum, 3600MHz suggested if your budget allows), and you’ve got a winning package.
Stick with a B550 motherboard. The premium you’ll pay for an X570 one is not worth it (at least in my opinion). It only brings PCI-E gen 4 for the storage, which you won’t really benefit from in games/sims.
2 Likes
MortThe2nd is right.
The limitation is with the mainthread processing.
It controls everything. Any game cannot run faster than this mainthread can process.
MS/ASOBO can’t do much about this except clean up their code
for efficiency if that matters to them. They can optomise for storage space required for the program on your drive or speed of execution of the program, etc…
It’s mind blowing in complexity.
Try to give them a little slack. This is a monumental task.
I think they have done an excellent job.
We all love it. Don’t we?
Yes…
Myself and others are limited consistently by the GPU. Since the main thread is not the bottleneck does this mean that the game cannot run faster than my GPU?
The FPS counter only looks at five different parts in the graphics pipeline. It doesn’t show anything before or after the pipeline. If the bottleneck is the main thread, what is contributing to the main thread bottleneck? Bad coding, slow CPUs, and no DX12 are the primary culprits. The CPU has to collect and process graphics information from many sources and if any of these sources are not feeding data to the main thread fast enough, it becomes the bottleneck. But the FPS counter only shows the main bread. I am always puzzled when users change their graphics settings but there is no FPS change. The FPS display should be changed to show more possible bottlenecks in the graphics pipeline.
1 Like
I have an i9-9900K and a GTX1660 TI.
This CPU runs FS2020 at around 22% utilization.
This GPU runs FS2020 at around 100% utilization.
I am bottlenecked by this GPU.
But the CPU is still limited by it’s mainthread.
Can the game run faster than the GPU? Trick question? Kind of a double negative .
I don’t know if I should answer it.
My WT CJ4 flies at the speed it is set to. I don’t get to the destination airport any sooner/later. Doesn’t matter what the GPU is.
My CPU can run (process) faster than my GPU can display it.
But, the game can run faster than the GPU.
I can put my FS2020 Sim Rate to 10x (only possible with 64GB of memory without crashing). The screen kind of “gallops”. When I put the Sim Rate back to 1x, the screen displays the scenery of the new location hundreds/thousands of miles away. And FS2020 keeps running. The WT CJ4 flies normal. You just have no idea where you are.
You can display the Task Manager and see all threads. The displayed FPS in FS2020 “Dev” screen is an average.
Display is on the Welcome Screen.
Interesting. CPU utilization = 11%. GPU utilization = 75%. FS2020 Dev FPS = 30.
The FPS screen shows the CPU in green, GPU in yellow with red stripes and displays “Limited by GPU”.
I can change my Render Scaling, and LODs (and many others) and get a change in FPS. The FPS is the result of the amount of data to display that the Graphics Setting are set to.
A change in Graphics Settings with no change in FPS would be a clear demonstration of limiting of the CPU processing speed due to the limitation of the mainthread. More data to display but the mainthread cannot process it (send it to the GPU). I assume the GPU could display it if received.
A fixed FPS could also be from a GPU’s display speed not capable to keep up with the data it receives. (Stutters, chops, etc.)
No. Task Manager Performance tab does not show all the threads. It shows how many threads there are. MSFS usually has about 170 threads. The Task Manager image you posted show 2,700 threads for all the running processes.
The i9-9900K has 8 cores, 16 threads.
The Performance tab in Task Manager shows 16 boxes for CPU utilization which I assume are the 16 threads.
These 8 cores and 16 threads are hardware references.
The 2700 threads you reference are software tasks/processes.
1 Like
The question becomes “Why (or what) is limiting the main thread?” If the main thread is not receiving all the data it needs to process before sending it to the GPU then the true bottleneck is whatever is feeding the main thread, not the main thread itself. We’ve been assuming that there are no issues with whatever feeds the main thread. Since we don’t know from the FPS counter what feeds the main thread, we can only assume the main thread is the only bottleneck, the only thing that needs to be “fixed”.
Reference to the “mainthread” is to the hardware (CPU).
It is not “fixable”.
MS/ASOBO cannot fix a CPU. Only Intel or AMD can.
They can only optomize how their software executes in the CPU.
Task Manager refers to these 16 threads as "Logical Processors.
They exist inside the CPU.
MS/ASOBO cannot control/modify how they function.
MS/ASOBO software programs can only issue commands to these 16 Logical Processors.
Now, with this following statement, I am assuming/guessing:
The concept of a “limiting mainthread” is maintaining control of an application/program.
If software programs could hit all 16 logical processors with commands simulltaneously, that would result in overload in the CPU. It could not handle it and would lockup, quit/freeze/shutdown.
The mainthread takes the software commands (instructions) and spreads them to the 15 other Logical processors. When they complete their task, they respond back to the mainthread.
Thus, all processing is controlled by the mainthread.
No it doesn’t. The Task Manager Performance tab photo shows THREADS 2700. Threads are NOT processors, logical or real. The computer doesn’t have 2700 processors. I know what a CPU is and how they are designed.
MSFS doesn’t issue commands to logical processors. It loads the program code into memory and tells Windows to run it. Windows decides which processors will run the code (I.e. threads). For MSFS to issue commands to a processor, it has to know how many processors there are and their utilization. Windows already does this so MSFS and other programs don’t have to.
MSFS usually has about 170 threads running at the same time. They are not continually overloading the processors. If a thread or 16 threads or 160 threads are ready to run, they would not lockup or shutdown any PC. Remember the Task Manager screen print showing 2700 THREADS. Windows is managing all those threads using a complex scheduling system that dispatches threads to a processor. When a user changes a priority for a program, it is messing around with the Windows scheduler.
We do not know the internal design of MSFS. We can only speculate. We have no idea how MSFS threads operate. They may be crafting a frame and sending it directly to the GPU for final processing. There is a lot of CPU and GPU shared memory to remove any potential hardware bottlenecks.
The FPS counter displays limited information. It doesn’t present any pre-CPU/main thread information. It doesn’t show very much post-GPU information. If I want to run MSFS at 4k but my monitor is an older big screen TV that can only display 1080p, then the monitor is the “bottleneck”. That is, if the FPS counter shows 50 FPS, this doesn’t mean that 50 FPS Is being displayed no matter what is plugged into the GPU.
What is feeding the main thread that is given to another thread for processing? If MSFS needs 15GB of scenery NOW that is currently on a disk, retrieving all those scenery files is going to take some time, maybe not a lot but the main thread has to wait and wait which limits downstream processing. Yes, the main thread is the bottleneck because there is a bottleneck in front of it. If someone looks at the main thread being the limiter and thinks that a faster processor or more cores or changing graphics parameters will fix the problem, they might be very wrong.
There are many things contributing to how fast or how slow FPS is. The FPS counter shows only a small set of the total environment because the FPS counter was designed by developers FOR developers.
From “Tom’s Hardware”:
A thread is a virtual version of a CPU core. To create a thread, Intel CPUs uses hyper-threading, and AMD CPUs uses simultaneous multithreading, or SMT for short (they’re the same thing). These are both names for the process of breaking up physical cores into virtual cores (threads) to increase performance.
Now we have a new definition: Thread - Logical Processor - Virtual Core
Yes. FS2020 is an application that runs under Window 10. It tells Win 10 what to do. Win 10 relays that command to the CPU and it’s 8 Physical Cores via it’s 16 Logical Processors (threads).
Not quite, I’ll try to explain.
MSFS was programmed with multithreading in mind (that is, spreading workloads over the available cores/threads).
All these different workloads need to be kept in sync; as in, the aerodynamic calculations need to be done, the 3D worlds needs to be done, the weather needs to be done, the instruments need to be done, all before a frame can be sent to the GPU for further processing.
The main thread is the thread responsible for keeping everything in sync. There are also a couple of workloads that HAVE to run on the main thread.
This main thread is the heaviest workload in the sim, and thus benefits a lot from a fast single-core CPU.
If your GPU (at your resolution and settings) is powerful enough to process all the frames the CPU can feed it, you’ll be ‘main thread limited’ (the GPU is waiting for the CPU to deliver the frames to process).
If your GPU (at your resolution and settings) is not powerful enough to handle all the frames the CPU can feed it, You’ll be ‘limited by GPU’ (the CPU is waiting for the GPU to be done to send it more frames).
This is the type of workload a sim brings (as do most games, the sim is just heavier on the CPU). As such, a sim (or other games) simply CAN NOT utilize all the cores/threads on productivity optimized CPU’s (more than 8 cores/16 threads or 6 cores/12 threads).
Most productivity workloads are just a different type of workload. Let’s take a tile-based renderer. The software cuts the scene up into 100’s of tiles, and every tile gets sent to its own CPU thread to be processed. Here it doesn’t matter that 1 tile is done sooner than the others. So the more threads you have available on your CPU the better, even if all those cores/threads run slower.
Different workloads, benefitting from different CPU’s.
I don’t see it in your explanation.
It would not result in overload. Tile based renderers do this all the time. For an example check out the ‘Cinebench’ benchmark.
This workload will load up all your cores/threads to the maximum, and you’ll not see any crashes, quits, freezes or anything like that. Specifically, software like this doesn’t need this ‘Main thread’ workload, since there is nothing to sync up there. Tiles get rendered when they are, and after all tiles are completed (doesn’t matter in which order), you’ll end up with a nice fully rendered picture.