Today’s v1.7.17.0 update does not mention this reported bug / regression.
I am growing very disheartened.
Today’s v1.7.17.0 update does not mention this reported bug / regression.
I am growing very disheartened.
Given how light on the updates are now I’m very sure that this regression is going to be baked into the the SU5 release.
Which really begs the question…what are we all actually doing here with supposed “beta testing”.
This isn’t actually a minor issue - It will dramatically effect all people who use multiple render windows once SU5 is released.
I hope I’m proven wrong, but I expect this will be yet another regression baked into a SU that will be quietly forgotten about.
I installed MSFS2024 SU5 beta 1.7.17 to check the situation, but the issue where FSR3 frame generation only works on the center screen when using multiple monitors was not fixed.
The left and right monitors still display blurry and unclear images.
I tried disabling it and switching to DLSS FG, but the FSR3 FG 3 screen did not become available.
I came across this thread because I use a second monitor to display the TDS GTN Nxi… when I’m typing on it (and the MSFS 2024 window loses focus), the main FS2024 window becomes stuttery until I click back into it. I’m using FSR/Framegen, so would this be related to the problem you’re having?
It’s been this way for years… frame gen is inactive when you click off the sim.
Yes, but that is not the bug reported.
The issue here is that prior to SU5, FSR3 Frame Generation was correctly applied to and working on triple screens while MSFS had focus (regardless of which MSFS window had focus). Since SU5, only the main window has FSR3 Frame Generation applied to it, regardless of which window has focus.
It’s a regression, and is “bug logged” which means they replicated it. My concern is that they fix the regression so we have the prior and expected functionality.
Thanks to everyone who contributed to this thread. Really hoping Asobo gets to work on fixing this regression.
I run two monitors myself (a massive, 32:9 Odyssey G9 OLED and a little 7” Prechen LCD for pop-out panels), and currently have to resort to Lossless Scaling for frame generation (works fine, but has higher latency cost and inferior image quality compared to DLSS and FSR FG).
Perhaps with DLSS Frame Generation, but for me (and plenty of others it seems), using FSR3 Frame Generation has worked since its introduction on all three render windows at the same time.. That stopped with the introduction of SU5 Beta where it now behaves the same as DLSS Frame Gen and only functions on the main render window.
My initial gut instinct at the beginning of SU5 was that maybe MSFS is mistakenly using DLSS FG even when you have FSR3 FG selected - which would accout for it not working on additional screens. Up until 1.7.10.0, the work around was as simple as toggling FG off, saving, then ON again, and it would work.
So we know FSR3 Frame Gen is 100% capable of working in MSFS - but, for whatever reason, MSFS is not calling it correctly, or is calling DLSS FG instead.
If that were the case, is there a way to have the type of frame generaiton being used displayed on an overlay? Like we can do with the DLSS Preset and DLL infomation that can be activated via editing the registry (or using DLSS Swapper). If such an overlay could be used it help indicate if FSR FG is still being applied (albeit to only one monitor).
When I renamed nvngx_dlssg.dll (DLSS FG) in the MSFS2024 folder and launched the game, DLSS FG disappeared from the graphics settings.
I hear that SU5 is targeted to release next week, but they still have a couple of bugs that needs to be fixed for release to go ahead. Didn’t watch the dev stream myself, but hope that this is one of these essential bugs to be fixed.
Would be really sad if we had to wait for SU6(+?) for this regression to be fixed.
Jorg literally said, “we are down to the last 2 or 3 bugs” in SU5, and my heart sank.
This is a fundamental regression of functionality we depend on for our hefty investment in MSFS to work. Am happy for all the fixes for those who use 1 screen, but will be thoroughly disappointed if they leave this unfixed after acknowledging it.
I hope that when Jorg mentioned the three bugs, he was referring to the one reported in this thread, as well as the CTD occurring during loading of the SU5 beta on RDNA2 GPUs. I’m wondering what the third bug is … because in my opinion, both the one from this thread and the CTD are core issues and should be fixed by the time SU5 goes live.
I agree 100% with @TenPatrol. Even though I personally am not affected by either of these 2 bugs, in my view they are most critical and need to be addressed prior to release.
According to the developer forum, many Asobo developers are working with multiple screens.
However, it’s unclear whether they are generating frames.
https://devsupport.flightsimulator.com/t/sim-freezes-when-creating-an-airport-project/17640/18
It’s my firm belief that it’s a settings issue - there are so many issues with settings not being obeyed. Another glaring example is the cockpit interaction mode - if you set Legacy it ignores it and still uses the blue highlights.
I’m glad to hear some are using triple screens - and I wonder how high or low their settings must be without frame gen…
Asobo was working on FSR3 throughout SU5 - mentioned in the first beta version release notes, and it was at that point that it broke. I do hope someone at that level noticed and cares enough to put it in the bug fixing queue.
Well the one bright spot is that the issue has been bug-logged, which indicates it has been reproduced by the dev team. Let’s just hope they realize its importants to those with big rigs.
Sadly searching the Developer Forum > MSFS 2024 Bug Reports > for “FSR3” or “frame generation” brings up nothing about this issue.