Feature Request: Official DirectX 11 support for the Unreal Engine FSR 2 Plugin

[Montazeran8]

Hello AMD FidelityFX Team,

First of all, thank you for your incredible work on the FSR technologies and for making them open source. It's a huge benefit for the entire development community.

I am a solo developer working with Unreal Engine 4.26 on a system with older hardware (NVIDIA GT 730, 2GB VRAM), which fully supports DirectX 11 (Shader Model 5.1) but does not have stable support for DirectX 12. For developers like me, UE4 remains a very viable and important engine.

After extensive testing, it's clear the official UE plugin for FSR 2 only contains backends for D3D12 and Vulkan, and does not work on a D3D11 RHI setup.

However, during my research, I made a very exciting discovery. I found a "hidden" patch in the FSR2-Unity-URP repository that adds a DX11 backend to the core FSR2 library:
0001-fsr-2.2-dx11-backend.patch
(Found via this issue: #16)

This patch proves that a DX11 implementation is not only possible, but officially exists internally at AMD.

My question and feature request is:

Would it be possible for your team to officially integrate this DX11 backend into a future version of the Unreal Engine FSR 2 plugin? Or, if a version with this support already exists (even an experimental one), could you possibly make it available?

Having official DX11 support would be a massive game-changer for a huge number of developers who are still actively using and developing for DirectX 11 hardware with Unreal Engine.

Thank you so much for your time and consideration. I truly appreciate your work.

Best regards.

[Montazeran8]

Hello AMD Team,

I have a critical new piece of information regarding this issue, which makes the situation much clearer.

I have managed to get FSR 2 running successfully, but ONLY in the Play-In-Editor (PIE) mode.

Here are the details:

• Engine: Unreal Engine 4.26.2
• RHI: DirectX 11
• Scenario:** In a blank project with a simple floor plane, I enabled the FSR 2 plugin. In PIE, it worked perfectly. I could enable it via the console (r.FidelityFX.FSR2.Enabled 1) and saw a significant performance boost (e.g., from 75 FPS to 120+ FPS on Performance mode). There were no crashes.

The crash ONLY occurs when running the project as a Standalone Game (or a packaged build).

When running as a standalone game, I get the following fatal error:

Fatal error:
[File:D:/Build/++/UE4/Sync/Engine/Source/Runtime/Windows/D3D11RHI/Private/D3D11Util.cpp] [Line: 258]
Direct3DDevice->CreateComputeShader((void*)CodePtr, CodeSize, nullptr, Shader->Resource.GetInitReference()) failed
at
D:/Build/++/UE4/Sync/Engine/Source/Runtime/Windows/D3D11RHI/Private/D3D11Shaders.cpp:356
with error E_INVALIDARG

This discrepancy between PIE and Standalone suggests that the issue is not with the FSR 2 plugin's core logic, but with a specific shader permutation that is only compiled for the game/shipping builds. It seems one of the more complex compute shaders uses an instruction or feature that is not supported by my hardware's Shader Model 5.1 feature set, which causes the driver to return E_INVALIDARG.

Is there any known workaround for this? Is it possible that a small modification to one of the .usf shader files could provide a fallback or a simpler code path to avoid this specific instruction on older hardware?

This could be the key to enabling FSR 2 for many developers still on DX11 hardware.

Thank you for any insight you can provide.

[Montazeran8]

Hello AMD FidelityFX Team,

First, I want to express my deepest gratitude for your time and work. Following up on my initial request, I have conducted a deep-dive investigation into the matter, and I have some critical findings I'd like to share.

My goal was to test if the FSR 2 algorithm could run on my older hardware (NVIDIA GT 730) under DirectX 11.

Here are the steps I took:

1. I successfully applied the official DX11 backend patch (0001-fsr-2.2-dx11-backend.patch) to the FSR 2.2.1 source code.
2. I successfully downloaded the Cauldron framework dependency.
3. I successfully compiled the FSR2DX11Sample.exe using Visual Studio.

The sample launches, but it fails immediately when the FSR2 context is created. The D3D11 debug layer provides the exact reason for the failure:

D3D11 ERROR: ID3D11Device::CreateComputeShader: Shader uses new Typed UAV Load formats, but the device does not support this.

The debugger confirms this failure happens in ffx_fsr2_dx11.cpp when trying to create the compute shader for the compute_luminance_pyramid pass.

My research confirmed that my GPU, while supporting the DX11.1 API, only supports it at Feature Level 11_0. According to official NVIDIA documentation, this feature level does not expose support for advanced UAV features like Typed UAV Loads, even if the hardware is partially capable.

This brings me to my final, and most important, technical question:

Is the use of Typed UAV Loads a fundamental and non-negotiable architectural requirement for the FSR2 algorithm's core logic? Or would it be theoretically feasible to create a fallback code path for hardware that only supports DX11 Feature Level 11_0? For instance, by using a more traditional (though likely slower) multi-pass "ping-pong" technique for the passes that rely on this feature?

I completely understand if this is not architecturally feasible or is outside the scope of the project. A definitive "no, this is not possible due to core architectural reasons" is a perfectly acceptable answer and would be immensely helpful for me and other developers on similar hardware. If that's the case, I will happily move forward with FSR 1.

Thank you again for your incredible work and for your time in considering this deep technical query.

Best regards.

[mirh]

Repo's dead Jim, I'm afraid. #117 has been open for years with no comments, and insofar as they are still technically supporting FSR2 that happens in the SDK repository (TIL that FSR3 could supersede it and be used without frame generation though).
And I wished it stopped there, but they really really really don't appear to take (or give) any kind of feedback.

@Zephyron-Dev @PotatoOfDoom @cdozdil @JuanDiegoMontoya @TheJackiMonster @Themaister @DarioSamo @Calinou @HydrogenC @Blinue @jntesteves @atyuwen @agyild
So.. I don't know, I'll admit that there's such a wide range of use cases here (from game engines to emulators to screen upscalers) but it's annoying that this is supposed to be FOSS yet everybody is kinda on its own, having to re-re-reinvent the wheel again if they can even be bothered, and their neat new backend/improvement falling into oblivion nonetheless.
Isn't there some guy/org that would feel like hosting a FSR repository that did take external contributions and improvements?

[JuanDiegoMontoya]

Not really sure what you expect us to do. I've never been involved with FSR in any official capacity.

[mirh]

Yes, "official" is exactly what I'm saying should get screwed.
In your FSR2 repo for instance (with those few issues and PR you interacted) you already provided more support than amd itself.

And ofc it shouldn't become a job (and ofc it couldn't be an opengl guy to start reviewing dx11 code) but I was hoping that somebody that cared for it could make a community repository. One that could accept the cross-platform support, and whatnot.
It's so infuriating that so many people had to duplicate their work, and so much of it eventually to get forgotten.