roman/OptiScaler2

Watch

Fork 0

[Linux/Bazzite] FFVII Remake + Luma: FSR4 DX11on12 RenderThread timeout unless Fsr4Update=false and CreateD3D12DeviceForLuma=false #1190

New issue

Open

opened 2026-10-02 00:02:45 +00:00 by RyZon360 · 2 comments

RyZon360 commented

2026-10-02 00:02:45 +00:00

(Migrated from github.com)

[Linux/Bazzite] FFVII Remake + Luma: FSR4 DX11on12 RenderThread timeout unless Fsr4Update=false and CreateD3D12DeviceForLuma=false

Game name and version:

FINAL FANTASY VII REMAKE INTERGRADE (Steam)

Steam AppID: 1462040
Steam build ID tested: 21888968

Mods and mod versions used

OptiScaler v0.9.4-final (7534ad0)
Luma for FINAL FANTASY VII REMAKE (Nexus Mods #1974)
No frame generation
Manual installation

GPU

AMD Radeon RX 9070 XT
RADV GFX1201 / RDNA4

OS

Linux / Bazzite

Proton:
Proton-CachyOS 11.0-20260703-slr

Game API:
D3D11 through DXVK

Resolution / display setup:
3840x2160 HDR

Used automated or manual install?

Automated
Manual

If on AMD/Intel and Automated, used DLSS inputs?

DLSS input is provided through Luma.

Did you check the Wiki and Compatibility List?

Description

I managed to get FSR 4.1.1 working correctly in FINAL FANTASY VII REMAKE on Bazzite/Linux together with Luma HDR, but two OptiScaler settings are required to avoid a reproducible Unreal Engine RenderThread timeout.

The working path is:

FINAL FANTASY VII REMAKE D3D11
-> DXVK
-> Luma / DLSS input
-> OptiScaler fsr31_12
-> local FFX 2.3 / FSR 4.1.1 SDK
-> Native AA 1.00x
-> 3840x2160 HDR

FSR4 was directly verified using the FSR watermark:

FSR4 UPSCALE 4.1.1
NATIVE-AA 1.00x
SOURCE: LOCAL
COLORSPACE: LINEAR

The game is currently stable with this configuration.

Luma / OptiScaler DLL chain

Luma was installed first into:

FINAL FANTASY VII REMAKE/End/Binaries/Win64

Luma's original:

dxgi.dll

was renamed to:

ReShade64.dll

OptiScaler:

OptiScaler.dll

was renamed to:

dxgi.dll

and OptiScaler is configured with:

LoadReshade = true

Luma itself works correctly under Linux/DX11 and fixes the HDR presentation.

In Luma:

Super Resolution = DLSS

This is the input used by OptiScaler.

Steam launch options

Current working launch options:

PROTON_FSR4_UPGRADE=1 WINEDLLOVERRIDES="dxgi=n,b" scb -f -w 3840 -h 2160 -W 3840 -H 2160 --hdr-enabled -- %command% -dx11

The scb ... --hdr-enabled part is specific to my Bazzite/HDR setup.

The relevant generic part is:

PROTON_FSR4_UPGRADE=1 WINEDLLOVERRIDES="dxgi=n,b" %command% -dx11

Working OptiScaler configuration

For OptiScaler v0.9.4-final:

[Upscalers]
Dx11Upscaler = fsr31_12

[FSR]
UpscalerIndex = auto
Fsr4Update = false
Fsr4Preset = auto
Fsr4EnableWatermark = auto

[Dx11withDx12]
UseDelayedInit = auto
DontUseNTShared = auto

[Hotfix]
CreateD3D12DeviceForLuma = false

Normal logging after troubleshooting:

LogToFile = auto
LogLevel = auto

Important note:

For v0.9.4-final the correct D3D11-on-D3D12 FSR backend is:

Dx11Upscaler = fsr31_12

Using ffx_12 with this release did not select the intended backend and silently fell through to an FSR2 path in my test.

Problem 1: Fsr4Update causes RenderThread timeout

With:

Dx11Upscaler = fsr31_12
CreateD3D12DeviceForLuma = false
Fsr4Update = auto / enabled

the game reaches a black screen and then crashes with:

LowLevelFatalError
RenderingThread.cpp
Line: 1144

GameThread timed out waiting for RenderThread after 30.00 secs

The detailed OptiScaler log stops here:

FSR31FeatureDx11on12::Evaluate calling InitFSR3
FSR31FeatureDx11on12::InitFSR3

There is no subsequent:

_createContext!

Looking at the v0.9.4 source, the first significant external operation inside this path is the FFX D3D12 version query.

So the observed hang appears to happen before FFX context creation, most likely during the first SDK/provider query.

With:

Fsr4Update = false

the same fsr31_12 backend initializes successfully.

Problem 2: CreateD3D12DeviceForLuma=auto also causes the timeout

After getting the game working with:

Fsr4Update = false
CreateD3D12DeviceForLuma = false

OptiScaler's overlay later rewrote:

CreateD3D12DeviceForLuma = auto

while Fsr4Update remained false.

On the next launch the same black-screen / RenderThread timeout returned.

Restoring only:

CreateD3D12DeviceForLuma = false

made the game start normally again.

So on this specific combination, both conditions are independently relevant:

Fsr4Update = false
CreateD3D12DeviceForLuma = false

Successful log evidence

With the working configuration:

Fsr4Update = false
CreateD3D12DeviceForLuma = false
Dx11Upscaler = fsr31_12

the log shows:

FSR.Fsr4Update: false

FSR4ModelSelection::Hook Hooking model selection, o_createModelSDK: 0
FSR4ModelSelection::Hook Hooking model selection, o_createModelSDK2: 6FFFF7A43AB0

CheckForGPU Adapter: AMD Radeon RX 9070 XT (RADV GFX1201), VRAM: 16304 MB
CheckForGPU RDNA4 GPU detected
CheckForGPU RDNA4: true, RDNA3: false, Fsr4Update: false

FSR31FeatureDx11on12::InitFSR3
FSR31FeatureDx11on12::InitFSR3 _createContext!

FfxApiProxy::D3D12_CreateContext Creating with upscaling_dx12
FfxApiProxy::D3D12_CreateContext Created with upscaling_dx12

FSR4ModelSelection::hkcreateModelSDK2

hkcreateModelSDK2 is then called repeatedly during normal gameplay.

The local upscaler DLL was verified as:

amd_fidelityfx_upscaler_dx12.dll
FileVersion: 4.1.1.2740
ProductVersion: 4.1.1.0
AMD FidelityFX (DirectX) Upscaler Library

The Proton prefix also contains:

amdxcffx64.dll
FileVersion: 2.3.0.2913

but the stable configuration uses:

Fsr4Update = false

and the FSR watermark reports:

SOURCE: LOCAL

Expected result

OptiScaler should ideally be able to use:

Dx11Upscaler = fsr31_12

with Luma on Linux without entering the RenderThread timeout path.

If appropriate, a game/Luma quirk for FINAL FANTASY VII REMAKE could force:

Fsr4Update = false
CreateD3D12DeviceForLuma = false

for this configuration.

Alternatively, it would be useful to understand why:

the FSR4 driver/provider update path hangs before _createContext!, and
the Luma early-D3D12-device workaround is harmful in this particular game.

Current workaround

The following is stable:

Dx11Upscaler = fsr31_12
Fsr4Update = false
CreateD3D12DeviceForLuma = false

with:

Luma Super Resolution = DLSS

Result:

FSR4 UPSCALE 4.1.1
NATIVE-AA 1.00x
SOURCE: LOCAL

No black screen, no RenderThread timeout, HDR works, and gameplay is stable.

I have attached

OptiScaler.log with LogLevel=0 from a successful FSR4 launch
Screenshot of OptiScaler overlay showing FSR 4.1.1
Screenshot of the FSR4 watermark showing FSR4 UPSCALE 4.1.1 / SOURCE: LOCAL
Screenshot of game folder (Win64_relevant_files.txt used instead because HDR screenshots render incorrectly when uploaded)
Working OptiScaler configuration (OptiScaler_working_FSR4_4.1.1.ini.txt)

OptiScaler_success_FSR4_4.1.1.log.gz

Win64_relevant_files.txt

OptiScaler_working_FSR4_4.1.1.ini.txt

# [Linux/Bazzite] FFVII Remake + Luma: FSR4 DX11on12 RenderThread timeout unless Fsr4Update=false and CreateD3D12DeviceForLuma=false #### Game name and version: FINAL FANTASY VII REMAKE INTERGRADE (Steam) Steam AppID: 1462040 Steam build ID tested: 21888968 #### Mods and mod versions used - OptiScaler v0.9.4-final (7534ad0) - Luma for FINAL FANTASY VII REMAKE (Nexus Mods #1974) - No frame generation - Manual installation #### GPU AMD Radeon RX 9070 XT RADV GFX1201 / RDNA4 #### OS Linux / Bazzite Proton: Proton-CachyOS 11.0-20260703-slr Game API: D3D11 through DXVK Resolution / display setup: 3840x2160 HDR #### Used automated or manual install? - [ ] Automated - [x] Manual If on AMD/Intel and Automated, **used DLSS inputs**? - [x] Yes - [ ] No DLSS input is provided through Luma. #### Did you check the Wiki and Compatibility List? - [x] Yes - [ ] No --- ## Description I managed to get FSR 4.1.1 working correctly in FINAL FANTASY VII REMAKE on Bazzite/Linux together with Luma HDR, but two OptiScaler settings are required to avoid a reproducible Unreal Engine RenderThread timeout. The working path is: ```text FINAL FANTASY VII REMAKE D3D11 -> DXVK -> Luma / DLSS input -> OptiScaler fsr31_12 -> local FFX 2.3 / FSR 4.1.1 SDK -> Native AA 1.00x -> 3840x2160 HDR ``` FSR4 was directly verified using the FSR watermark: ```text FSR4 UPSCALE 4.1.1 NATIVE-AA 1.00x SOURCE: LOCAL COLORSPACE: LINEAR ``` The game is currently stable with this configuration. --- ## Luma / OptiScaler DLL chain Luma was installed first into: ```text FINAL FANTASY VII REMAKE/End/Binaries/Win64 ``` Luma's original: ```text dxgi.dll ``` was renamed to: ```text ReShade64.dll ``` OptiScaler: ```text OptiScaler.dll ``` was renamed to: ```text dxgi.dll ``` and OptiScaler is configured with: ```ini LoadReshade = true ``` Luma itself works correctly under Linux/DX11 and fixes the HDR presentation. In Luma: ```text Super Resolution = DLSS ``` This is the input used by OptiScaler. --- ## Steam launch options Current working launch options: ```bash PROTON_FSR4_UPGRADE=1 WINEDLLOVERRIDES="dxgi=n,b" scb -f -w 3840 -h 2160 -W 3840 -H 2160 --hdr-enabled -- %command% -dx11 ``` The `scb ... --hdr-enabled` part is specific to my Bazzite/HDR setup. The relevant generic part is: ```bash PROTON_FSR4_UPGRADE=1 WINEDLLOVERRIDES="dxgi=n,b" %command% -dx11 ``` --- ## Working OptiScaler configuration For OptiScaler v0.9.4-final: ```ini [Upscalers] Dx11Upscaler = fsr31_12 [FSR] UpscalerIndex = auto Fsr4Update = false Fsr4Preset = auto Fsr4EnableWatermark = auto [Dx11withDx12] UseDelayedInit = auto DontUseNTShared = auto [Hotfix] CreateD3D12DeviceForLuma = false ``` Normal logging after troubleshooting: ```ini LogToFile = auto LogLevel = auto ``` Important note: For v0.9.4-final the correct D3D11-on-D3D12 FSR backend is: ```ini Dx11Upscaler = fsr31_12 ``` Using `ffx_12` with this release did not select the intended backend and silently fell through to an FSR2 path in my test. --- ## Problem 1: Fsr4Update causes RenderThread timeout With: ```ini Dx11Upscaler = fsr31_12 CreateD3D12DeviceForLuma = false Fsr4Update = auto / enabled ``` the game reaches a black screen and then crashes with: ```text LowLevelFatalError RenderingThread.cpp Line: 1144 GameThread timed out waiting for RenderThread after 30.00 secs ``` The detailed OptiScaler log stops here: ```text FSR31FeatureDx11on12::Evaluate calling InitFSR3 FSR31FeatureDx11on12::InitFSR3 ``` There is no subsequent: ```text _createContext! ``` Looking at the v0.9.4 source, the first significant external operation inside this path is the FFX D3D12 version query. So the observed hang appears to happen before FFX context creation, most likely during the first SDK/provider query. With: ```ini Fsr4Update = false ``` the same `fsr31_12` backend initializes successfully. --- ## Problem 2: CreateD3D12DeviceForLuma=auto also causes the timeout After getting the game working with: ```ini Fsr4Update = false CreateD3D12DeviceForLuma = false ``` OptiScaler's overlay later rewrote: ```ini CreateD3D12DeviceForLuma = auto ``` while `Fsr4Update` remained `false`. On the next launch the same black-screen / RenderThread timeout returned. Restoring only: ```ini CreateD3D12DeviceForLuma = false ``` made the game start normally again. So on this specific combination, both conditions are independently relevant: ```ini Fsr4Update = false CreateD3D12DeviceForLuma = false ``` --- ## Successful log evidence With the working configuration: ```ini Fsr4Update = false CreateD3D12DeviceForLuma = false Dx11Upscaler = fsr31_12 ``` the log shows: ```text FSR.Fsr4Update: false FSR4ModelSelection::Hook Hooking model selection, o_createModelSDK: 0 FSR4ModelSelection::Hook Hooking model selection, o_createModelSDK2: 6FFFF7A43AB0 CheckForGPU Adapter: AMD Radeon RX 9070 XT (RADV GFX1201), VRAM: 16304 MB CheckForGPU RDNA4 GPU detected CheckForGPU RDNA4: true, RDNA3: false, Fsr4Update: false FSR31FeatureDx11on12::InitFSR3 FSR31FeatureDx11on12::InitFSR3 _createContext! FfxApiProxy::D3D12_CreateContext Creating with upscaling_dx12 FfxApiProxy::D3D12_CreateContext Created with upscaling_dx12 FSR4ModelSelection::hkcreateModelSDK2 ``` `hkcreateModelSDK2` is then called repeatedly during normal gameplay. The local upscaler DLL was verified as: ```text amd_fidelityfx_upscaler_dx12.dll FileVersion: 4.1.1.2740 ProductVersion: 4.1.1.0 AMD FidelityFX (DirectX) Upscaler Library ``` The Proton prefix also contains: ```text amdxcffx64.dll FileVersion: 2.3.0.2913 ``` but the stable configuration uses: ```ini Fsr4Update = false ``` and the FSR watermark reports: ```text SOURCE: LOCAL ``` --- ## Expected result OptiScaler should ideally be able to use: ```ini Dx11Upscaler = fsr31_12 ``` with Luma on Linux without entering the RenderThread timeout path. If appropriate, a game/Luma quirk for FINAL FANTASY VII REMAKE could force: ```ini Fsr4Update = false CreateD3D12DeviceForLuma = false ``` for this configuration. Alternatively, it would be useful to understand why: 1. the FSR4 driver/provider update path hangs before `_createContext!`, and 2. the Luma early-D3D12-device workaround is harmful in this particular game. --- ## Current workaround The following is stable: ```ini Dx11Upscaler = fsr31_12 Fsr4Update = false CreateD3D12DeviceForLuma = false ``` with: ```text Luma Super Resolution = DLSS ``` Result: ```text FSR4 UPSCALE 4.1.1 NATIVE-AA 1.00x SOURCE: LOCAL ``` No black screen, no RenderThread timeout, HDR works, and gameplay is stable. --- #### I have attached - [x] OptiScaler.log with `LogLevel=0` from a successful FSR4 launch - [x] Screenshot of OptiScaler overlay showing FSR 4.1.1 - [x] Screenshot of the FSR4 watermark showing `FSR4 UPSCALE 4.1.1 / SOURCE: LOCAL` - [x] Screenshot of game folder (`Win64_relevant_files.txt` used instead because HDR screenshots render incorrectly when uploaded) - [x] Working OptiScaler configuration (`OptiScaler_working_FSR4_4.1.1.ini.txt`) [OptiScaler_success_FSR4_4.1.1.log.gz](https://github.com/user-attachments/files/32938024/OptiScaler_success_FSR4_4.1.1.log.gz) <img width="1924" height="1870" alt="Image" src="https://github.com/user-attachments/assets/7b710718-63e9-426c-9c5e-dcfc13daf9a3" /> <img width="1153" height="143" alt="Image" src="https://github.com/user-attachments/assets/c26b316f-c657-48d9-90b5-21bd1fb85d71" /> [Win64_relevant_files.txt](https://github.com/user-attachments/files/32938056/Win64_relevant_files.txt) [OptiScaler_working_FSR4_4.1.1.ini.txt](https://github.com/user-attachments/files/32938077/OptiScaler_working_FSR4_4.1.1.ini.txt)

cdozdil commented

2026-10-15 07:32:46 +00:00

(Migrated from github.com)

Hi,

From what I saw you have shared info about working runs. To detect and diagnose the issue we need info about unsuccessful runs.

Hi, From what I saw you have shared info about working runs. To detect and diagnose the issue we need info about unsuccessful runs.

RyZon360 commented

2026-10-15 19:38:27 +00:00

(Migrated from github.com)

Hi @cdozdil and @IamInnocent3X,

Thanks for your replies. I've gone back through my troubleshooting records and recovered additional evidence from unsuccessful FF7 Remake launches.

@cdozdil — Regarding the failed-run evidence:

You're correct that my original attachment was a successful OptiScaler log.

I have now recovered 11 original Unreal Engine crash reports from September 15 to October 8, 2026, all reporting:

CrashType: Assert
LowLevelFatalError
RenderingThread.cpp — Line 1144
GameThread timed out waiting for RenderThread after 30.00 secs

I've also prepared a sanitized crash-context extract from an unsuccessful October 2 run, removing machine identifiers, login identifiers and local paths.

The corresponding original Unreal Engine minidumps are still available locally, but I haven't published them for privacy reasons.

My troubleshooting history identified two separate configurations associated with the timeout:

Failure A:

Dx11Upscaler = fsr31_12
Fsr4Update = auto
CreateD3D12DeviceForLuma = false

Failure B:

Dx11Upscaler = fsr31_12
Fsr4Update = false
CreateD3D12DeviceForLuma = auto

The historically confirmed working configuration was:

Dx11Upscaler = fsr31_12
Fsr4Update = false
CreateD3D12DeviceForLuma = false

During a documented failing initialization, the OptiScaler log excerpt stopped around:

FSR31FeatureDx11on12::Evaluate calling InitFSR3
FSR31FeatureDx11on12::InitFSR3

The _createContext! message observed in successful runs was not reached.

These historical observations help narrow down the failure, although I cannot definitively match every recovered Unreal Engine crash report to its exact OptiScaler INI state.

Unfortunately, I haven't recovered a complete OptiScaler log from a failed launch. The attached sanitized crash context is additional evidence, not a replacement for that log.

@IamInnocent3X — Regarding your Nightly 1410 results:

One finding from my investigation may be particularly relevant to your Rendering Thread error.

CreateD3D12DeviceForLuma=auto was independently associated with the timeout in my configuration, even when Fsr4Update=false.

More importantly, changing only:

[Hotfix]
CreateD3D12DeviceForLuma = false

restored successful launching.

I observed this behavior on separate occasions. At least once, saving settings through the OptiScaler overlay rewrote this parameter back to auto, and the launch failure returned. Restoring false resolved it again.

This makes the CreateD3D12DeviceForLuma setting one of the strongest suspects in my specific setup.

Since you mentioned already applying the INI edits, I would suggest first verifying that the setting actually remains false in the saved INI after using the overlay.

If it is already false and you still get the timeout, then my workaround is clearly insufficient for your configuration, and your failed-run OptiScaler log would be valuable.

Your environment also differs from mine: Nightly 1410, Proton Experimental on SteamOS, the 4K HD Remake Project and an additional SDR ReShade, versus my OptiScaler 0.9.4-final + Proton-CachyOS + Luma HDR setup on Bazzite.

I cannot determine from the available evidence whether any of those differences contribute to your crashes or heavy microstutters.

I hope the recovered crash evidence and the reproducible configuration differences help narrow down the issue. Thanks again for investigating.

FF7_Remake_failed_crash_2026-10-02_sanitized.xml.txt

Hi @cdozdil and @IamInnocent3X, Thanks for your replies. I've gone back through my troubleshooting records and recovered additional evidence from unsuccessful FF7 Remake launches. **@cdozdil — Regarding the failed-run evidence:** You're correct that my original attachment was a successful OptiScaler log. I have now recovered **11 original Unreal Engine crash reports** from September 15 to October 8, 2026, all reporting: ```text CrashType: Assert LowLevelFatalError RenderingThread.cpp — Line 1144 GameThread timed out waiting for RenderThread after 30.00 secs ``` I've also prepared a sanitized crash-context extract from an unsuccessful October 2 run, removing machine identifiers, login identifiers and local paths. The corresponding original Unreal Engine minidumps are still available locally, but I haven't published them for privacy reasons. My troubleshooting history identified two separate configurations associated with the timeout: **Failure A:** ```ini Dx11Upscaler = fsr31_12 Fsr4Update = auto CreateD3D12DeviceForLuma = false ``` **Failure B:** ```ini Dx11Upscaler = fsr31_12 Fsr4Update = false CreateD3D12DeviceForLuma = auto ``` The historically confirmed working configuration was: ```ini Dx11Upscaler = fsr31_12 Fsr4Update = false CreateD3D12DeviceForLuma = false ``` During a documented failing initialization, the OptiScaler log excerpt stopped around: ```text FSR31FeatureDx11on12::Evaluate calling InitFSR3 FSR31FeatureDx11on12::InitFSR3 ``` The `_createContext!` message observed in successful runs was not reached. These historical observations help narrow down the failure, although I cannot definitively match every recovered Unreal Engine crash report to its exact OptiScaler INI state. Unfortunately, I haven't recovered a complete OptiScaler log from a failed launch. The attached sanitized crash context is additional evidence, not a replacement for that log. **@IamInnocent3X — Regarding your Nightly 1410 results:** One finding from my investigation may be particularly relevant to your Rendering Thread error. **`CreateD3D12DeviceForLuma=auto` was independently associated with the timeout in my configuration, even when `Fsr4Update=false`.** More importantly, changing **only**: ```ini [Hotfix] CreateD3D12DeviceForLuma = false ``` restored successful launching. I observed this behavior on separate occasions. At least once, saving settings through the OptiScaler overlay rewrote this parameter back to `auto`, and the launch failure returned. Restoring `false` resolved it again. This makes the `CreateD3D12DeviceForLuma` setting one of the strongest suspects in my specific setup. Since you mentioned already applying the INI edits, I would suggest first verifying that **the setting actually remains `false` in the saved INI after using the overlay**. If it is already `false` and you still get the timeout, then my workaround is clearly insufficient for your configuration, and your failed-run OptiScaler log would be valuable. Your environment also differs from mine: Nightly 1410, Proton Experimental on SteamOS, the 4K HD Remake Project and an additional SDR ReShade, versus my OptiScaler 0.9.4-final + Proton-CachyOS + Luma HDR setup on Bazzite. I cannot determine from the available evidence whether any of those differences contribute to your crashes or heavy microstutters. I hope the recovered crash evidence and the reproducible configuration differences help narrow down the issue. Thanks again for investigating. [FF7_Remake_failed_crash_2026-10-02_sanitized.xml.txt](https://github.com/user-attachments/files/33511834/FF7_Remake_failed_crash_2026-10-02_sanitized.xml.txt)