While working on integrating FSR3/4 frame generation, I noticed that our application consistently freezes when I set up an FSR replacement swapchain, enable frame interpolation with a ConfigureDescFrameGeneration Configure call, and then disable frame interpolation again with the same Configure call with frameGenerationEnabled set to false.
We rely on the frame latency waitable object from the FSR replacement swapchain to signal when it is safe to start a new frame on our main CPU thread. I noticed early on that these signals stop arriving after disabling FI, which causes the application to wait indefinitely for permission to start a new frame, causing the observed freeze.
While debugging the issue, I observed the following messages in the Visual Studio Output window whenever I send the Configure message to disable frame interpolation:
The thread 'AMD FSR Presenter Thread' (27720) has exited with code 0 (0x0).
The thread 'AMD FSR Interpolation Thread' (16996) has exited with code 0 (0x0).
The thread 'AMD FSR WaitableObject tracking Thread' (12884) has exited with code 0 (0x0).
The key here is the final line. The "AMD FSR WaitableObject tracking Thread" is what continuously listens to frame done events and releases the waitable object semaphore that the application waits on.
Looking closer at the code of the DX12 replacement swapchain, this thread is stopped when the Presenter is shut down. This happens both when the FSR replacement swapchain is destroyed (shutdown -> killPresenterThread), and when frame interpolation is disabled (setFrameGenerationConfig -> killPresenterThread). I believe the latter is an error, and the WaitableObject thread should be stopped only when the FSR replacement swapchain is destroyed. When FI is merely disabled, the thread should continue running, in order to signal the application that it may start new frames.
The relevant code (particularly: the CreateReplaceableObjectHandle and waitableSignalThread functions along with the waitableObjectSemaphoreHandle) was added in the FidelityFX SDK 2.2.0 update from March 2026, so this is a relatively new issue. I have confirmed that we do not have this issue with FidelityFX SDK 2.1.1 or the older FidelityFX SDK 1.1.4.
This issue is not visible in the included Sample application, because it never simply disables frame interpolation while maintaining the FSR replacement swapchain; it completely replaces the swapchain with a stock DXGI swapchain whenever you disable FI. For various reasons, this is not a viable solution for us. We need to be able to dynamically enable and disable FI without switching the swapchain.
While working on integrating FSR3/4 frame generation, I noticed that our application consistently freezes when I set up an FSR replacement swapchain, enable frame interpolation with a
ConfigureDescFrameGenerationConfigure call, and then disable frame interpolation again with the same Configure call withframeGenerationEnabledset tofalse.We rely on the frame latency waitable object from the FSR replacement swapchain to signal when it is safe to start a new frame on our main CPU thread. I noticed early on that these signals stop arriving after disabling FI, which causes the application to wait indefinitely for permission to start a new frame, causing the observed freeze.
While debugging the issue, I observed the following messages in the Visual Studio Output window whenever I send the Configure message to disable frame interpolation:
The key here is the final line. The "AMD FSR WaitableObject tracking Thread" is what continuously listens to frame done events and releases the waitable object semaphore that the application waits on.
Looking closer at the code of the DX12 replacement swapchain, this thread is stopped when the Presenter is shut down. This happens both when the FSR replacement swapchain is destroyed (
shutdown -> killPresenterThread), and when frame interpolation is disabled (setFrameGenerationConfig -> killPresenterThread). I believe the latter is an error, and the WaitableObject thread should be stopped only when the FSR replacement swapchain is destroyed. When FI is merely disabled, the thread should continue running, in order to signal the application that it may start new frames.The relevant code (particularly: the
CreateReplaceableObjectHandleandwaitableSignalThreadfunctions along with thewaitableObjectSemaphoreHandle) was added in the FidelityFX SDK 2.2.0 update from March 2026, so this is a relatively new issue. I have confirmed that we do not have this issue with FidelityFX SDK 2.1.1 or the older FidelityFX SDK 1.1.4.This issue is not visible in the included Sample application, because it never simply disables frame interpolation while maintaining the FSR replacement swapchain; it completely replaces the swapchain with a stock DXGI swapchain whenever you disable FI. For various reasons, this is not a viable solution for us. We need to be able to dynamically enable and disable FI without switching the swapchain.