Crashes in ResizeInternal

Hi,

We observe numerous crashes related to DX12, which ultimately lead to

FD3D12Viewport::ResizeInternal. Judging by the call stack, most of them also involve

FFXFrameInterpolationSlateRenderer::UpdateFullscreenState at one of the stages. In this case, FSR may not work at all (i.e., the player either disabled the upscaler or selected a different one).

Example call stack with UpdateFullscreenState:

D3D12RHI::VerifyD3D12Result (D3D12Util.cpp:991)
FD3D12Viewport::ResizeInternal (WindowsD3D12Viewport.cpp:305)
FD3D12Viewport::Resize (D3D12Viewport.cpp:412)
RHIResizeViewport (DynamicRHI.h:1370)
FSlateRHIRenderer::ResizeViewportIfNeeded (SlateRHIRenderer.cpp:427)
FSlateRHIRenderer::UpdateFullscreenState (SlateRHIRenderer.cpp:500)
FFXFrameInterpolationSlateRenderer::UpdateFullscreenState (FFXFrameInterpolationSlate.cpp:230)
FSceneViewport::UpdateViewportRHI (SceneViewport.cpp:1789)
FSceneViewport::ResizeViewport (SceneViewport.cpp:1632)
FSceneViewport::OnDrawViewport (SceneViewport.cpp:439)

Example call stack without UpdateFullscreenState:

D3D12RHI::VerifyD3D12Result (D3D12Util.cpp:991)
FD3D12Viewport::ResizeInternal (WindowsD3D12Viewport.cpp:305)
FD3D12Viewport::Resize (D3D12Viewport.cpp:412)
RHIResizeViewport (DynamicRHI.h:1370)
FSlateRHIRenderer::ResizeViewportIfNeeded (SlateRHIRenderer.cpp:427)
FSlateRHIRenderer::DrawWindows_Private (SlateRHIRenderer.cpp:1226)
FSlateApplication::PrivateDrawWindows (SlateApplication.cpp:1434)
FSlateApplication::DrawWindows (SlateApplication.cpp:1121)
FSlateApplication::TickAndDrawWidgets (SlateApplication.cpp:1721)
FSlateApplication::Tick (SlateApplication.cpp:1574)

Also, all these crashes seem to have several sources or occur randomly throughout the game (including when starting the game or entering the main menu). Also visible on all hardware and regardless of GPU/CPU vendor.

Perhaps someone has encountered something similar and can suggest a source or what the problem might be? Because from my point of view, it seems very strange that disabled FSR somehow contributes to such crashes.

[Attachment Removed]

Hello,

Thank you for reaching out.

To clarify FFXFrameInterpolationSlateRenderer is part of the interpolation layer and its possible those hooks are active even if you have the upscaling/frame generation feature disabled. We will not be able to provide additional support on the FSR front and would recommend talking to the vendor if there are issues there.

For the non-FSR path, can you please try reproducing the crash with -d3ddebug and provide us the log from that run?

Please see this page for rendering crash debugging guidance:

[Content removed]

[Attachment Removed]

You can use the command-line argument “-d3ddebug” on PC with all build configurations. However, doing it with Development/Test/Debugging builds can yield more useful logs and debug information.

Are you able to reproduce this in Development builds?

[Attachment Removed]

Hey,

We have the same issue with one of out projects. It seems AMD FSR plugin always registers FFXFrameInterpolationSlateRenderer (as well as always creates FFXFrameInterpolationModule implementation) regardless of are you actually using FSR FG or not. Apparently, this has to be sent/escalated to AMD FSR representatives to make sure Unreal integration works as intended.

I also have feeling (no exact repro steps), that setting upscaler to DLSS first (not touching FSR FG) may cause the crash on resize as well.

[mention removed]​ Have you looked more on this?

[Attachment Removed]

If the issue is primarily from third-party plugins, you will need to contact the appropriate vendor for support.

Please let us know if there is additional information that points to an issue in the engine.

[Attachment Removed]

Could you clarify regarding “-d3ddebug” as I don’t quite understand. Does this argument work in shipping builds? Or are Development/Test/Debugging required?

[Attachment Removed]

Okay. Thank you!

No, we can’t reproduce it, but our QA team is working on it. We are also working on getting additional information from players. As soon as we receive logs with this flag, we will send them to you.

[Attachment Removed]

Got it.

Please let us know once you have more information on the issue.

[Attachment Removed]

One of the players caught it and was able to send us a log with “-d3ddebug”.

He also sent the following description:

Bug Description: Crash on switching screen mode

How can the bug be re-created: I am unsure how to recreate this bug on other computers. I have a fairly high-end PC and this has never occured in other games.

[Attachment Removed]

We also suspect that Intel/Nvidia/AMD frame generators may be causing crashes, as they may not be completely disabled, as is the case with XeFG. So, in our next game patch, we will disable them and see if such crashes continue

[Attachment Removed]

Thank you for letting us know.

Do let us know if it continues happening with the updated patch.

[Attachment Removed]

It has now been 36 hours since the patch was released to players, and we can see that 99.9% of crashes of this type have disappeared. To achieve this, we disabled the Streamline and StreamlineDLSSG plugins. We also disabled XeFG (r.XeFG.OverrideSwapChain=False).

We also learned from our colleagues that frame generators generally have many problems, and for this reason we do not plan to use them at this time

So even if AMD’s frame generator prepares hooks and other things, nothing is stopping it now (I mean the other frame generators)

[Attachment Removed]

I’ve done further investigation, apparently:

  • AMD FSR FI does not require swapchain override, but it’s for “better frame pacing” (as per docs). Setting this var requires game restart to take effect
  • Intel XeFG requires swapchain override and game restart to take effect
  • NVIDIA FG (DLSSG) requires swapchain override, but it can do that on fly (recreating swapchain on demand) so does not require game restart

I assume the best solution is to disable 2 cvars overiding swapchain in DefaultEngine.ini:

[SystemSettings]
r.XeFG.OverrideSwapChain=0
r.FidelityFX.FI.OverrideSwapChainDX12=0

and when needed, set cvars accordingly and prompt user to restart the game to take effect. At least we are testing it now.

It’s not an Unreal Engine issue per se, and I completely understand the mainline to improve TSR, though it would be great, if we have unified way in Unreal Engine to support different Upscaler, Low Latency and Frame Generation technologies without meshing plugins altogether.

[Attachment Removed]

Thank you for the confirmation that the issues are from third-party plugins. I will go ahead and close this ticket.

[Attachment Removed]