I’m just taking the counterpoint that you don’t need to disable Gsync to get smooth performance, although I’m very much looking forward to trying out the tweak in the OP to see if it works. There’s clearly a difference with how 2020 and 2024 implements Gsync.
My only reservation is what happens when frame rates dip below the target Fps and Gsync isn’t there to smooth everything out.
The GSX thing is a bit off topic but I’m certain it will fix geloxo’s issue. It took me ages to find the problem
I’m not going to be drawn into an argument, but did you try my fix for capping frame rate in-game and leaving G-sync enabled? It really does work. No need to be offended for me offering alternatives to help people out.
FPS definitely can be limited in game with frame generation, as of SU2. As I said before, it is currently hidden in the user.cfg so might not be very obvious, you have to look for the line that says ‘FrameLimiter’. Apparently SU3 will implement a slider in-game to set this. If you set the in-game frame limiter to 45, and then force 3x FG in NVidia app you get a resultant 135fps.
You’re right, I haven’t tried the fix for disabling GSync yet, I will try it tonight as I’m currently at work and will share my feedback. I’ll be happy if this works, but I am struggling to see how it will be any better than the solution I found because in this case GSync isn’t enabled, but in my ‘solution’ it is. It might be that both solutions work nicely, there isn’t necessarily only one solution.
Whoever wrote this, should really go over to blur busters and educate themselves. I imagine G-Sync doesnt work properly for a lot of people because they are outside of their G-Sync compatible VRR range, creating a pacing issue. By disabling it, they are simply disabling the pacing issues. Basically they are not using G-Sync properly. Everythjing needs setup to work correctly, and G-Sync is no exeption.
Better advice would be to get each user to check their VRR range, and then advise to stay within that range at all times. There is nothing on the market today that is better than G-Sync for smoothness.
PS exceeding your monitors refresh rate is pointless, it will lead to tearing and pacing issues.
I was curious doing the same tip in MSFS 2020, because it’s my main sim right now, live build (not SU16) with the Fenix & flytampa KLAS. System used in a 5800x3d, 4070 Super and 32 GB RAM in 1440p
As you probably know, FG is a DX 12 thing only. Problem in 2020, is that my VRAM of my 4070 Super is simply overloaded, causing the flickering and completely making it unusable. So.. back to DX11 with Lossless Scaling.
Currently testing in 2024 SU2 with the same conditions, I have to say that I don’t see a lot of differences unfortunately. Still a lot of stutters when moving the camera along the cockpit (worse when you switch from cockpit to wing view), passing 100+ FPS to less than 30fps.
I have G-Sync enabled because disabling it actually causes more headaches and issues. Even if you try to disable G-Sync just for MSFS 2024 via the NVIDIA Control Panel while keeping it enabled globally, it still creates problems. In my case, turning G-Sync off completely and using V-Sync set to “Fast” results in screen flickering, and sometimes the sim crashes during loading due to unstable drivers.
One way I’ve found to reduce stutters and get smoother performance, especially when running around 65 FPS, is to lock your FPS to something lower, like 30, and then use frame generation to boost it to 60. Remember, MSFS is a flight sim, not a fast-paced shooter. Also, one simple tweak that works for me is to right-click on the msfs2024.exe, go to Properties, and disable full-screen optimizations. That small change alone can really help.
Negative, sir. In your video, the FPS counter would state “Frame Gen” if it were active — but it doesn’t.
Flying right now with G-Sync off, 3× Frame Generation, and V-Sync on — exactly as I recommended. The result? Smooth as butter, not a single stutter. Just look at the frame pacing: as flat as it gets.
As I say, The video is with MSFS 2020, which don’t take FG into account in the dev counter. I don’t have time to record my MSFS 2024 testing yet, but my impressions of my testings on 2024 are on my last sentence.
This method only works if your system can consistently (under all scenarios) and safely (by a substantial margin) render base FPS above your display’s refresh rate .
Display refresh rate divided by frame gen factor, to be precise If display rate is 120 and one uses 3x FG, it is enough to always be able to stay above 40 fps.
Sorry but I think former post is now hidden, so I had to use yours. Anyway this statement is not correct in my opinion. There are some confusions here and test results are not coherent in accordance:
Frame generation is a GPU feature. It’s not managed by game nor main thread benefits from it. Game only requests the activation to GPU and GPU generates the artificial frames on its own. Main thread still has the same gross workload anyway: it needs to handle the simulation events.
The reason why main thread latency and performance appears to improve is because you reduced quality as a pre-requisite to achieve the max monitor refresh. By doing so you are already eliminating the main system bottleneck yourself. So this step is indeed the real solution behind this whole history and anything else after this is therefore not magical.
After that step all those other secondary modifications are simply improving a bit the new starting conditions for the tests but they are not the responsible ones for the overall gain. Indeed some of them are a bit useless and inconsistent.
Limiting fps is not required as soon as Nvidia Reflex is enabled, as that alone is another way to limit fps and reduce latency. Indeed Reflex is enabled by game automatically once you activate frame generation in game settings.
On the other hand reducing fps artificially to generate more frames afterwards simply destroys frames to create them again after that. However the former ones are real and clean and the others are AI generated and can contain artifacts. Frame generation main target is to create frames based on your original conditions, allowing therefore to keep high quality on demanding conditions. So it just allows you to keep your quality settings and still have high fps. This is the main inconsistency I see with the method and the reason why I think it’s only a placebo.
As far as I read SU3 beta has already included two main fixes related to performance: improved managing of big airports on final and a weather error that tanked performance on areas including many airports or heliports. Those two are the reason of most performance problems (as they can happen worldwide) and would be most likely the true fix. As in most cases game’s enemy in terms of performance is game itself.
Have you actually tested it or are you still just theorizing? Because once you try it exactly as proposed (and you have the good enough hardware) you’ll see that it’s definitely not a placebo. Theory vs. practice, my friend.
Most of the testing I’m seeing in this thread seems to be from users running RTX 5090s Naturally, you’re going to see high FPS and strong performance, even though MSFS 2024 isn’t particularly well-optimised yet, even for top-tier hardware.
Let’s be real, every system is different and will yield different results depending on setup, settings, and background processes.
But back down to earth, the reality is that the vast majority of players don’t own an RTX 5090. In fact, as of early 2025, only a tiny fraction of PC gamers are using any 5000 series GPU. For context, even in MSFS 2020, the most common GPUs were still from the 30-series (like the RTX 3060 and 3080), and even some 20-series cards were hanging on.
So while it’s great to see what a 5090 can do, most simmers are dealing with far more modest setups, and that’s where the real performance concerns and feedback become valuable.
I tested it and that´s why I shared my comments. One of the basis for testing is that test conditions shouldn´t be changed if you pretend to compare results between two different test cases. That´s not followed as soon as you modify the graphical settings in the second test (for disabling G-sync) because with that you are also reducing the initial performance hit compared to the test where G-sync was enabled.
For your information I did an extra test on my own afterwards: I followed the method but without having reduced the graphical settings, so using the same initial testing conditions (same scenery and graphical settings). In fact the fps figures are basically the same and are still high (9950x3d + 4090 + 64 Gb here), and this does not release any significant workload on system. However, what you don´t notice if you follow the proposed method but you notice when you directly compare both tests under the same conditions, is the amount of tearing and stuttering that is generated due to having disabled G-sync, as fps values are so high in the original video.
This, in my opinion, is how tests should be done to be able to compare results, identify the factors that change or not change results as well as the side effects induced by the test execution itself and be able to drop consistent conclusions afterwards.
In our case we can see in the original youtube video two clear things which are ignored:
User is unable to notice any tearing while tearing is indeed existing after the proposed fix. The high fps values just hide that tearing
User is unable to notice any stuttering while stuttering is indeed existing due to deactivation of G-sync. As soon as fps drop a bit below the max refresh the stuttering will start and persits until you come back to that max value again. Frame generation helps here, sure, but don´t forget that you reduced settings, so frame generation will find it easier to keep the max fps figures for longer periods of time.
I know original author was just willing to help and I have nothing against that. However the proposed approach is simply based on a reduction of quality to increase fps. This is something that will always happen, so there´s no magic behind that. Therefore this has nothing to do with G-sync and can´t be used to justify that disabling G-sync prevents any impact on performance, as indeed the proposed approach is generating two more additional problems that were not existing before disabling G-sync (tearing and stuttering) that were not detected due to the way the test was performed, as test conditions changed between the two tests and second test is more performance friendly that first one.