Many thanks…
Is anyone seeing full black screens when switching between windowed and full screen MSFS using the DLSS DLL version 3.6 or 3.7? If I go back to 3.5.x the issue stops. I can start MSFS full screen or windowed and it’s fine. It’s only when switching does my whole screen go black.
We need a native implementation of the game, which allows to render the instrument or the glass panels display in the cockpit at full resolution and leave the rest to the resolution chosen by the user processed, with DLSS. Then with different levels of DLSS in different sectors of the screen.
I’m on 3.7 but don’t have the issue with the screen going dark.
It’s frustrating that the Devs mentioned it during a Q&A in the Spring when asked about what’s going on with this fix, Martial incorrectly thought it was in the Sim and fixed but was told via text message it wasn’t. Jorg then asked him to chase it up and yet here we are, mid summer and still no word on whether this fix is incoming.
Is it at all possible that you, as a moderator, can ask the question about what’s going on with this? We shouldn’t have to rely on the off chance a Q&A question will remind them, they need to realise the importance and implement this fix in SU16 if it’s ready to go.
Thanks
I have submitted a question regarding this matter for the upcoming developer livestream. Let’s see if we get a response.
Hi everyone,
When is DLSS going to be fixed for glass cockpit? They said in the developer stream (July) the developer was on holidays and it was pretty much fixed. There’s a significant difference in performance and currently DLSS it’s very annoying to use.
It was said in the latest stream a few days ago that the problem cannot be fully fixed because of how the DLSS algorithm works, and it’s the best it can be right now.
Listening to this again, there seems to be a fundamental misunderstand about what the actual problem is. Martial explains that DLSS get’s a bit blurry due to the upscaling inherent to it. But that’s not the issue that keeps the community from using it!
What we have as an issue is that, the the temporal component of DLSS is not biased for the current frame in the glass displays, which smudges numbers into an unreadable mess. This is totally independent from the upscaling and even happens if I use DLAA, which is only using DLSS for anti-aliasing, not upscaling.
And I’m very optimistic, that this should be a simple fix by setting some flag somewhere. Afterall, with their own TAA implementation it does not happen, even though TAA and DLSS are exactly the same in this regard, that they work over multiple frames.
(you can even see, that they don’t use TAA on displays in some addons, eg. the EFB and the PFD in the PMDG 777, since these very much display some slight aliasing. So you just need to apply the recent frame bias option for DLSS on these very same textures)
Now actually though of demonstration for this issue, since they say a picture says more than a thousand words or something along those lines
see the altitude tape here in Fenix A320, the numbers in the readout are almost unreadable and the tick marks wholly disappear
Also very visible in this video. I’m scrolling through the baro settings here to just get some movement on the altitude tape for the demonstration.
Compare this to TAA with the exact same settings that doesn’t blur these numbers and stays readable
Martial explained in that Q&A that they are already flagging glass cockpits and other animated textures (such as the water surface) to bias current frame information on them. The problem though is that DLSS insists on performing a temporal reconstruction pass on these surfaces, rather than ignoring them completely.
The same thing is happening with the FSR 2.1 implementation. The glass cockpits and water look extremely jittery because Asobo have correctly flagged them for the reactive mask, but even that is not enough to prevent ghosting. This is because, despite the stronger reactivity, the FSR algorithm struggles a lot with animated textures and elements without motion vectors (this can be seen across several games, and is not an MSFS issue).
Meanwhile with TAA the glass cockpits look perfectly stable because the algorithm ignores them completely (even from the camera jitter). But that is because Asobo have full control over their own algorithm. The solution would be for Nvidia to allow full reactivity of flagged elements.
Alright, that’s a shame then that nVidia can’t handle that on their end properly. Thanks for pointing that out, must have missed that piece of information in the stream.
But that leaves a slight hope, that some update to DLSS might acutally fix this one day without much more involvement from Asobo. Maybe just need to pump more resolution, cause I saw in my testing that once the numbers get big enough they stay clear even on DLSS. ![]()
Do you have the same issue if you follow the OP’s steps to reproduce it?
Provide extra information to complete the original description of the issue:
Are you using DX12?
Yes
Are you using DLSS?
No
If relevant, provide additional screenshots/video:
Do you have the same issue if you follow the OP’s steps to reproduce it?
Provide extra information to complete the original description of the issue:
Are you using DX12?
yes
Are you using DLSS?
yes
If relevant, provide additional screenshots/video:
It seems that something has been fixed, now they look less blurry today.
I’d rather developers concentrate on optimising their games rather than relying on the crutch that it is upscaling, and DLSS/FSR.
Some are riding high on the x2 claims of Nvidia but turn off the fancy upscaling, and “fake frames”, and you don’t get anywhere near that.
https://www.pcgamesn.com/nvidia/geforce-rtx-5090-30-faster-4090-dlss-4
Moore’s law really is dead my friend. This is the way if you want better performance. Devs didn’t suddenly become incompetent, talent is much more available than ever before. It’s just that improvements cost a lot in performance, and upscaling is the only way.
Honestly at 4K native resolution with a fast GPU (7900 XTX), TAA runs just fine. It’s the main thread limit that always bottlenecks me in MSFS, 2020 and 2024. ![]()
I’ve long since given up on DLSS to work correctly with the computer displays in the cockpit (nor can I run it at all anymore as I don’t have an Nvidia card anymore).
Note as always I don’t care about fps over 60 in the middle of nowhere; the low end of fps in busy scenery areas at airports and cities is the only thing that matters.
Update as of October 2025: MSFS 2024’s native FSR3 frame doubling support works much better than previous frame doubling attempts I made with AFMF, and has completely replaced any desire I might have had to use spatial upscaling because rendering at full resolution keeps all my glass panel displays absolutely razor sharp and I still get 60fps at airports after doubling.

