CPU Bug "Limited by Main Thread" is causing the bad FPS

The patch is already out.

1 Like

and it is not addressing any fps problem, just CTD and similar problems.

70%, all other settings posted in the linked thread.

NB: the high memory consumption could be related to the ‘glitch’ which was reducing the renderer to 10fps. Maybe it is something related to oversubscribing the VRAM (bug in fs2020) and it took some time for the GC to clean it up and restoring fps, albeit, with some memory still allocated and not reclaimed.

That is odd… Lower resolution, less upscaling. Could be driver and OS related. There have been improvements to vram usage by the os in Windows 2004 vs 1909.

1 Like

has anyone tried?

And it was never meant to, unless you include the SimConnect issue. I lost 10fps with SPAD.neXt running.

I didn’t get a chance to fly last night, but I did get the patch installed, which was without significant issue, so that in itself boxes well for the future.

Hi All,

I hope you are well. I have been having the same issues. My system specs are the below…

i7-9700k @ 4.6ghz
RTX2080
16GB DDR4. (Another 16 arriving today so i will document any improvements)

I was getting around 15-20 FPS at Heathrow on medium with sliders turned down. I was constantly getting ‘Limited by mainthread’. I checked my RAM and it appeared to only be running at 1033mhz. I had a check, enabled XMP and moved ram into the correct slots. I now see 30-40 FPS at heathrow on ULTRA. Something worth checking.

1 Like

what makes you think DX12 would make performance any better for us?

Easy: this piece of software is cpu limited. Dx12 is supposed to alleviate issues with draw calls so it seems like the perfect thing for a flight sim like this.

2 Likes

@CptLucky8 @fulatoro Thanks for trying this out. It’s very odd. After reading what you guys wrote, I went back and re-tried this by starting at LFPG rather than finishing there and found much the same results as your initial ones @CptLucky8. Between 25 and 30 FPS generally with the occasional dropped frame or mini chug.

To me, this makes sense, since I was careful not to open any menus. However, when I’ve flown there previously at night, it’s been following a long flight with numerous menu opens etc. It would seem that there’s a bug somewhere where opening a menu causes some configuration change which overloads the CPU. It may also be a memory leak causing the performance to get worse over a flight so that by the time you get to an airport, there’s not enough RAM left to hold everything it needs to in memory, forcing the CPU to constantly load textures etc. Weird.

I suppose the takeaway is, don’t open menus unless you really have to.

I will try a flight from London to LFPG and see how it behaves.

1 Like

What I find even more peculiar is that regardless of running at 1K or 4K I get about the same fps in both cases.

I might be wrong but this would usually mean the CPU has reached its limit and can’t deliver enough while the GPU is not fill or shader bound with my settings. Otherwise, there is too much traffic between the CPU and the GPU and I’m reaching my PCI bus speed limit (on this particular computer it is not x16 but x8 yet it should be more than enough GB/s).

Mind you, these tests at CDG were done with the Citation Longitude and I also suspect part of the problem is the aircraft itself and the way the EFIS screens with this CoherentGT technology are sucking too much CPU/GPU by themselves.

NB: I’ve done the CdG test with my other settings (besides graphics) which are also a factor: 100% road vehicles, 75% workers, 75% ground traffic, the others at 50% (default).

Also, I’ve tried this flight test again today and this time I’ve opened the console in the dev mode windows menu. Ouch… Ouch… so many errors and warnings about the stock fs2020 files and missing this or missing that… tens of thousands messages in the console.

I’ll try other tests with CPU OC and see how it goes.

1 Like

Tbh, I don’t find it all that surprising given how heavily CPU bound this is. From what I understand (I may be wrong), the resolution of the textures doesn’t really impact on how long the CPU takes to load them or how hard it has to work to do that. So whether it’s loading a texture at 1K or at 4K makes no difference to CPU loading.

Given that the bottleneck is the CPU, the GPU has enough overhead to render the 4K textures within the same frame draw time meaning no impact on FPS. That’s because the frame is being held up by the CPU calculating all the physics and telling the GPU what to draw on all the screens and loading textures etc. Once the instruction to output reaches the GPU, it’s got more than enough time to render that before it’s asked to draw another one, irrespective of resolution. The problem is further upstream, hence there being next to no impact on FPS from changing res.

At least that’s my understanding.

It’s worth noting too that this will likely change when DX12 support arrives since lots of this stuff will be offloaded from the CPU meaning that at lower resolutions. We’re likely to remain CPU bound (albeit with higher frame rates thanks to DX12 allowing the CPU to offload some tasks to the GPU) at lower resolutions and then go heavily GPU bound at higher resolutions (also with higher frame rates).

I did the same yesterday night, scary amount of errors and warnings :joy:

Looking at the roadmap and feedback from yesterday, I expect significant improvement in the upcoming patch.

1 Like

From my observation, most of the time I see “Limited by GPU”. What that would mean is any difference between target frame rate and actual is due to the GPU.

Now, as I get closer to a bigger airport, suddenly things start getting busier with terrain and objects rendering, planes in and around airport, traffic on roads, flight model behavior etc. This creates sudden spikes in the CPU usage and bogs down the framerate as the CPU is not able to cope up with so many tasks at once.

I’m no tech expert by any stretch but I think if Asobo works towards better scheduling and distribution of CPU specific tasks in the sim, we might be able to get rid of those random freezes and stutters. In the meantime, ProcessLasso is your friend.

Apart from this, I’ve also been seeing “Limited by manipulators” spontaneously, don’t know exactly what that means. What I dislike in the sim is that the buildings and objects in the immediate vicinity are fine but if I look farther (>5-6 nm), I just see empty terrain which fills up right before me only if I move closer to that region of emptiness. Similar thing happens with airport runway as well which appears jagged and blurry from a distance, greatly affects visual landings.

2 Likes

I do agree that there is a significant CPU load issue with this release of MSFS. I see people struggling on lower end systems with 100% cpu load and low GPU loads. I don’t want to go too deep into details as some of you have pointed them out already and I agree. But what I want to address is an independent observation from reading all these posts on this forum. Count the times a RTX 20XX.XX is mentioned and you do start to think it could have something to do with this particular GPU. I personally own a 1080ti and a i7 9700k but I don’t recognize me in the fps issues mentioned in this thread. And I see amost no issues mentionened about a 1080ti. Yes some with the gtx 1080. So perhaps, could it be that there might be an issue with the RTX 2080xx or the RTX 20XX.XX? I’m doing 65% CPU and 85% GPU with my combination. Nearly smooth. And yes MSFS craves (V)RAM so less then 32 GiB RAM or less then 10 or 11 GiB VRAM will also put you into trouble. But again what really stands out of all this is the mentioning of the RTX2080xx. Just an observation people. Grtz.

For those who don’t know what you are talking about: https://bitsum.com/

1 Like

As for Process Lasso I’d refrain from advocating its use. First because the mere usage of this kind of product shouldn’t be an excuse to not optimizing the simulator. Secondly because with the FS2020 SDK architecture (no in-process DLLs anymore) there will be more external processes running concurrently with the simulator and anything prioritizing the simulator will be detrimental to the 3rd party addons.

CPU bound simulator and poorly scheduled tasks are key characteristics of Flight Simulator since at least FS9 up to P3D3. Starting with P3D4 there has been significant changes you could see the difference in day-to-day flights.

Given Asobo is claiming they’ve kept most of what is already good (in their opinion, which doesn’t mean in customer’s/simmers expectations) so that they won’t break too much (meaning also save months of development), this makes me wondering how much they’ve changed from the past legacy code.

An example: In FS2020, like any other simulator since FS9 (at least), whatever the operating system and the computer I’m running it with, whenever I’m in short final there is a small stutter when I reach a certain distance to the runway. This is happening with all these simulators and this is the worst moment to stutter.

The only explanation I’ve found over the years is that at this particular distance, the simulator is loading the OMI Markers sounds and this loading event is making the stutter. If it is not the sound, it is more likely something else they only load once below a certain distance threshold and whatever it is in the end, it is causing a stutter and this is happening since FS9…

This is not the case in X-Plane (please no debate, just comparing how it runs) where the internal task scheduler has been greatly improved upon and does a good job at balancing the tasks, but more importantly in how X-Plane is pre-loading all necessary assets “intelligently” so that when these are needed (either being rendered on screen or played on the speakers) it won’t stutter the simulator.

Makes you wondering.

4 Likes

There is a new interesting solution for the airliners instruments here: Highonsnow JS Fix 15-19 FPS improvement on Airliners targetting specific instruments

1 Like