I know the new FSR 3 plugin only just dropped today but I thought I’d ask for some ideas.
When enabled (with either TAA or TSR, it is required that one of those is active for frame gen to work) and working there are some serious flashing bars on either side of my rendered window. Kind of looks like an OCAT overlay but there shouldn’t be anything enabled to display that.
We are experiencing the same thing, it does not matter if we are using UseRHI or UseNativeDX12. We also noticed that frame interpolation sometimes does not work at all, despite starting standalone with the same config settings.
Have you managed to find the source of the artifacts?
Edit*
Appears to be r.FidelityFX.FI.ShowDebugTearLines. Set it to zero to get rid of it. Found it thanks to @nno_x in this other thread.
Update to my own comment. NVIDIA Streamline module fights with the FSR3 FI module. Streamline is the module for Reflex and Frame Generation. r.Streamline.InitializePlugin and r.FidelityFX.FI.Enabled (and some other cvars, see the readme) must be toggled accordingly in the config before the engine starts. This is only relevant for frame generation, not upscaling, and can’t be changed during runtime. There is also a bug with r.Streamline.InitializePlugin where it is not properly working due to module initialization order, I have sent a bug report for that.
I was certain I’m the only person in the world struggling with the simultaneous implementation of DLSS FG and FSR 3 FI. So, for now, there is no solution to switch between them at runtime, and we have to wait for an update, right?
I would not hold my breath. Both plugins use a very early initialization stage to modify the engine internal state. I do not have enough experience with that part of the engine, but it looks very low level, low enough to require a restart perhaps (making any possible update from AMD and NVIDIA impossible). We got it working anyhow by doing some “LoadingPhase”: “EarliestPossible” trickery to configure both plugins using their console vars before they in turn initialized. Be careful to ensure those CVars exist before trying to set them, if they do not it means the related plugin module has not loaded yet. We needed to use GameUserSettings and sav-files (not other ini-files), for other reasons, so that is how we solved it.
You need to create a module or uplugin that starts in the EarliestPossible phase. Also add FFXFSR3Settings and FSR3 to AdditionalDependencies and Plugins so that your module starts before those. This allows your module to start before any of the NVIDIA or AMD modules do their startup configuration. In your StartupModule function you configure all the CVar values related to the NVIDIA and AMD modules, then those modules will read the values in their startup phase.
These are the related CVars from the plugins that I touched last time I messed with this. It is up to you to read the documentation for each plugin and understand how to set all the values properly in relation not only to the NVIDIA vs AMD conflict, but also based on dx11, dx12, etc.
CVarFSR3UseRHI
CVarEnableFFXFI
CVarFSR3UseNativeDX12
CVarFSR3OverrideSwapChainDX12
CVarFFXFIUpdateGlobalFrameTime
CVarFSR3AllowAsyncWorkloads
CVarStreamlineInitializePlugin
e.g.
CVarStreamlineInitializePlugin.AsVariable()->Set(true, ECVF_SetByConsole);
The ECVF_SetByConsole property just marks the CVar priority so that other parts of the code or ini loading does not overwrite your chosen values. It’s a bit of a hack.
I cannot share the exact code for various reasons, but that should be enough for you to get started. Just be vary that all modules have a loading phase and you need to make sure that your module loads in a good spot and BEFORE the other modules do their startup thing. Remember that you cannot change the Frame Generation method during runtime and you have to restart the engine for the changes to apply. If you need a user setting you need to LoadConfigIni in your StartupModule to fetch the value in the EarliestPossible phase.