A MainThread az csak egy szál az összes közül. Abszolúte nincs köze ahhoz, hogy hány magos a CPU, meg úgy általában semmihez amikre gondolnál. Ez tisztán egy szoftveres dolog. Ez az első szál amit a Windows a CreateProcess-el létrehoz. Ez tartalmazza az alkalmazás üzenetkezelését, és ehhez van tulajdonképpen minden szinkronizálva (memóriakezelés, grafika, hang, hálózat, soros port, stb.). Ebből az egy szálból jön létre az összes többi, de azoknak mindig is ehhez az egyhez kell igazodniuk. Ha nincs megfelelő szinkronizásció, akkor a windows nem osztható erőforrásai (szinte az összes driver, heap, stb.) össze-vissza fognak működni, és a vége minden esetben valami fatális hiba (akár maga a gép is lefagy). Ezért ha többszálas alkalmazást írunk, oda kell figyelni, hogy a MainThread-et ne lássuk el semmilyen funkcióval, hogy mindig legyen "szabadideje". Ez azért bazi nehéz, még a mostani fejlett fejlesztőeszközökkel is, többnyire nem is tudják a programozók rendesen használni. És mindig túlterhelik a MainThread-et. A MainThread sebessége csak a CPU nyers frekvenciájától függ, azonbelül pedig az egy magon futó többi aktív szál számától, illetve azok kihasználtságától függ. Ha mint ahogyan azt írtad, hogy 4.9GHz-es procival is van ilyen gond, akkor ebben az esetben, tökmindegy milyen proccot teszünk alá, ez lesz. Ezen csak azok az optimalizációk segítenek, amikor a programozók, az "időrabló kódokat" "kiterelik" a MainThread-ből, valamelyik külső szálba. Hát ezt meg kell várni. Vannak apró trükkök, pl. hogy az alkalmazásnak letiltjuk a 0.mag, 0.thread-jét (hogy a Windows ne itt hozza létre a MainThread-et, mivel ezen "ülnek" a legtöbben), de ez önmagában nem fog észrevehető fps növekedést eredményezni, inkább csak a lag-okra van hatással (ha pölö a grafikát nézzük) azzal, hogy pl. egy PostMessage-nek nem kell annyit várnia, hogy sorra kerüljön.
Az pedig egy másik téma, hogy azt látod, hogy a CPU "unatkozik", és a GPU 100%-on teker. Egyáltalán nem biztos, hogy ez így is van. Sőt általában egyáltalán nem ez a helyzet. Inkább visszavezethető szoftverproblémára: nem jó időben indított bármilyen esemény esetleg maga az eseménytípus rossz választása, két függvény összekeverése (talán a leggyakoribb hiba), és a túl lazán megírt kód (pl. itt most nem szenvedünk blokkosítással meg a DMA használatával, jó lesz az közvetlenül és szekvenciálisan is...csak tudnám ki/mi foglalja a CPU-GPU lane-t), meg ilyenek. És amikor egy-egy ilyet megtalálnak és megírják úgy, ahogyan azt kellett volna, na ilyenkor kiabálják szét a világsajtóban, hogy mekkorát akasztottak.
Egyébként kicsit furcsállom amit írsz. Nem tudom hány magos procid van, de mondjuk legyen 4 fizikai, HTT-el, akkor az 8 logikai. Ha ennél a MainThread ki van akadva (100%-on teker), akkor az már önmagában kb. 20% a teljes CPU-ra nézve. Márpedig az MSFS-ben ránézésre elég jól vannak a szálak kihasználva, tehát ez a 20% nem fordulhatna elő. Namost, ha a CPU globálisan tényleg 20% és a MainThread is ki van terhelve, akkor nem utasításvégrehajtásról beszélünk, hanem inkább valaki késleltet valamit valamiért. Mert csak így fordulhat elő. hogy a proci hardveresen ne dolgozzon, míg szoftveresen tele vagyunk (hirtelen nem tudtam szebben írni). Lehet kísérletezni, hogy mi okoz ekkora arányú visszaesést. Bármi lehet, bár ezek szerint visszavezethető a MainThread-re, tehát akkor, inkább hardverelem vagy annak drivere nem illeszkedik ahogyan kellene. Tehát első lépésben VR-t eltávolítani (esetleg minden driverét is a gépről), és úgy megnézni (mivel azt írtad, hogy a VR használatakor van probléma).
Nálam a legutolsó frissítésekkel is teljesen jól működött az MSFS. Azért kifogásolható volt, hogy akadt néhány elmosódás, 10 méterre kirajzolt fák, stb. Kicsit túltolták az erőforráshasználat visszavételét. Van ez így, majd javítják. De a stabilitással nem volt gond. Egészen addig míg naprakészre nem frissítettem az nVidia drivert. Most már nekem is elszáll a menü, meg úgy általában minden. Hát ez egy ilyen sport, lehet várni a javítást meg, hogy legközelebb ki/mi húzza a rövidebbet:).