Have you disabled/removed all your mods and add-ons?
Yes
Are you using Developer Mode or made changes in it?
Yes
Brief description of the issue:
Note that in both cases the IN GAME setting for vsync appears to be already broken as it is ignored once DLSS3 frame generation is enabled. I dont think this should happen as nVidia released drivers to support vsync in conjunction with DLSS3 in Nov 2022 (driver 526.98).
However a workaround was possible in 1.29.30 of MSFS by setting vsync in the control panel. This worked well. see this image (note the 30fps here is being doubled to 60fps at the monitor and therefore is very smooth):
Well DLSS3 certainly worked without vsync in version 1.29.30.0 provided you set it in nvidia CP.
The screen shots I posted above show that. The only change I made between taking those was to update to 1.30.9.0 so something must be different in the MSFS code. I would like the developers to go back to whatever they were doing in 1.29.30.0 even if it wasn’t intended. DLSS3 with vsync only is amazingly smooth
Further to my post above, it may be worth adding that if I revert to version 1.29.30.0 and leave all settings the same (i.e. in windows, nvidia CP and in-game), then I do successfully get DLSS3 Frame Generation with vsync only (i.e. no gsync enabled) and my frame rate is a super smooth 60fps at the monitor while leaving a 32msec interval for the simulation to perform it’s calculations - a win-win. This indicates that something has changed in the code between 1.29.30.0 and 1.30.9.0.
I have repeated this swap between the two versions several times just to be sure.
I’m glad it’s not only me who couldn’t get VSYNC to work with FG on, I tried every combo in NVCP including FPS limiting and nothing has worked. VSYNC ON does stop tearing but introduces a awful lag when panning. All other settings continue to tear. I’m on the Beta so I’ll try coming off that.
In-game DX11 VSYNC works perfectly at 60 on my 4K monitor so I hope Asobo can implement same in DX12/FG.
I am also having issues with frame generation. The only way I can avoid screen tearing on my 60hz 4K monitor is to enable vsync ON in nvidia control panel and off in the sim.
The performance is excellent and incredibly smooth but there is noticeable lag when panning / moving in the sim.
Is there any way around this or am I pretty much stuck with these settings for now?
As far as I understand, DLSS-FG does not have proper vsync support, it didn’t have it ever. There was a hack where one could force vsync in the NVCP and get a framerate limit without causing tears. But this always came with massive latency penalty if your framerate (generated framerate, not actual framerate) went above monitor refresh rate. The trick was to stress the GPU so that the final framerate stays below monitor refresh rate. This is explained in detail in this digital foundry video:
That was before there was a driver update which enabled vsync support officially but only in limited sense. It is supposed to be enabled from NVCP and is supposed to work with G-Sync (this includes freesync too i think). With that, it should be smooth. This works on my setup very well, other that some artefacts under certain conditions, but those were there before too. And I am on the latest beta build of MSFS.
While your post contains correct info the issue I’ve raised is that the ‘hack’ worked in 1.29.30 but no longer works in 1.30.9.0 onwards. And that is broken even with zero config or driver changes. After a week of trying I’ve not been able to get PROPER vsync working with FG. The pseudo-vsync available now is just not as good due to the frame time spikes being still present. The lag while noticeable was not a problem for me in a flight sim. If you use the hack now you get the frame time instability you see in the screen shot in my OP.
I assume you don’t have a gsync / freesync compatible display and that is why this becomes an issue for you. If that’s correct, then i am not sure what you can do other than wait for a patch which may or may not arrive as this was never an official solution. You can try updating the driver to the newest driver and see if the issue persists. You can try to use rtss framerate cap too, it worked for me without vsync but it had issues. And without vrr (gsync/freesync) there may still be some tearing.
But i think the best course of action would be, if you have a gsync / freesync display that is, to use those features and enable vsync from nvcp.
Edit: i am not sure about your display refresh rate but it seems to be 60 as you are getting about 30fps with frame generation. I can see that your framerate is right at the edge sometimes even higher than 30. Thus this is supposed to cause massive latency penalty that i mentioned from the df video. Have you tried stressing the GPU? May be you can enable 2.25x dldsr from nvcp and run the game at higher output resolution, or you can power limit your GPU so that it stays under 30fps. Don’t use the render scale as i ve found on my setup it increases artefacting, kind of like deforming lines.
Even with a gsync display it was still smoother on the initial release with vsync enabled as the op says. It did introduce some latency and is likely what nvidia was fixing with their driver update. Basically with vsync enabled the mainthread wasnt tied to the actual frametime as it is now.
If you actually mean WITHOUT gsync, then i understand, but if you mean WITH gsync, i don’t think op said anything about using gsync. With gsync, this should be a non issue now.
Gsync or not it was still smoother when the mainthread was not tied to the framerate as it allowed the huge frametime variances to be smoothed by the latency that is introduced. Dont get me wrong its fine for the most part now with gsync and its understandable why this was done as for the majority of games latency is arguably more important. Which is why i wonder if reverting the dll (if it was updated) may actually return to the previous behaviour.
Last time i checked, the nvgnx_dlssg.dll was at version 1.01 i think. Not sure if there was a version 1.00 ever. Maybe during the SU11 beta. And unfortunately we don’t have download location like the techpowerup for this dll.
Just checked 1.29.30 and the DLL versions are the same so this does look like a code change. I would doubt that this would be changed as arguably it is correct behaviour.
Let me clarify - I do have a G-SYNC capable monitor (LG OLED) but I still don’t like using it as no-one will convince me that G-SYNC is as smooth as vsync! It may be my old eyes but that’s what I think
The workaround became broken with no driver change (as stated) so is nvgnx_dlssg.dll updated via the MSFS update process? (I’m not at home now so cannot see if it is present in the MSFS exe (virtual)folder). Edit: Actually as I can swap between the two versions of MSFS (pre and post AAU1 beta) and see the workaround return to working I’m guessing it must be part of the MSFS update.
Let me be clear in what I’m asking - I agree that Asobo haven’t really broken anything here - in fact they may just be using the correct and updated DLSS SDK from nVidia when compiling MSFS for the AAU 1 beta but this is just a plea from me to go back to the way it was in 1.29.30.0! Sadly, I think there little chance of this happening as my use-case is in the minority but until then I’ll be wasting the FG capability of my 4090 as I NEED vsync
Edit 2: Sorry @WarnersWorld I’d not seen your post before this reply so some of my words regarding nvgnx_dlssg.dll may not be correct…
Just for the interest of discussion, as far as I understand, in most scenarios (not specific to msfs), both gsync and vsync work in tandem and this is recommended. So even if you enable gsync, you should still use vsync. Sometimes this causes a latency spike when the framerate jumps to the monitor refresh rate. To counter that, a framerate limiter like rtss can be used to limit frame rate to 2-3 fps lower than the display refresh rate. Personally I never had to do this as regular gsync + vsync works great for me. But that may just be because of my untrained eye.
And since you are saying that you find gsync to be not as smooth as vsync ( and i believe you ), you may be facing the latency spike i talked about just in the above para. If you are not using vsync with gsync, you can still get some tearing when fps goes above monitor refresh rate.
So don’t know what is the issue you are facing on your setup. But to give you a option if you are willing to try:
Not sure if you are limiting the refresh rate to 60, but as far as I know, most modern LG oleds support 120Hz, so if you run at that refresh rate with gsync, you should not hit the latency spike issue on gsync + vsync. You can still use vsync. Not sure if it will be as smooth as you are expecting and ofcourse there will be fps variances (because msfs). But you can still enable frame generation and smoot out those cpu bottlenecked frametime spikes.
But else you can of course not use frame generation. Personally i don’t use frame generation by default and only use gsync + vsync. I enable frame generation only when the fps goes down below 40fps. So not in mid flight.
Thanks for trying to help @AbhishekDey1594 but in the past week I’ve spent literally hours per day and tried just about every combination of G-SYNC, vsync, refresh rate, RTSS, there is! In fact I’ve been back to the bad old days of testing more than flying
The ‘official’ scenario is as you describe - 120hz, enable G-SYNC, enable vsync (although this has to be done in nVidia control panel as the in-game setting appears to be ignored and I believe that is a genuine bug (or not yet implemented) on the part of Asobo) OR use a frame rate limiter to make sure the 120hz is not exceeded BUT a spin of the head in the cockpit view when in down-town New York (my standard stress-test) results in stutter when object/terrain data is being loaded into memory. This does not happen with genuine vsync and version 1.29.30.0.
In fact my PC being a i7 12700K @5.1Ghz + RTX 4090 meant that I’d pretty much met my life-time goal of zero stutters and all at a glorious and smooth 60fps. This is now back to 30fps as I’ve had to switch off FG. Vsync on in both cases I should add. Also I’ll declare that that’s with no traffic and not using the more complex 3rd party airplanes as in those cases CPU limitations appear.
Now of course there’s always going to be the very odd stutter on a non-realtime OS like Windows (you’ve got to expect that) but they were acceptable.
I’ve reminder myself that I think 1.30.11.0 has increased the frequency and severity of the terrain loading stutters - I may make a new topic regarding that!
I realise that I may be perceived as being a ‘fussy customer’ but my life-long flight sim goal was achieved with 1.29.30.0 for 3 days before I updated to AAU 1! Now that’s appears to be gone and the reason for my upgrade to the 4090 is only half fulfilled - that’s hard to take! (Unless the developers reverse the code changes haha)
For anyone who wants to contribute on this issue, Click on the button below to use this template:
