Filing this as an issue rather than a PR, because I don't think the fix belongs in the launcher — see the last section.
Symptom
Satisfactory 1.2 (appid 526870) crashes during graphics init on the d3dmetal backend, before any window appears:
Assertion failed: GGlobalSamplerDescriptorHeapSize <= MaximumSamplerHeapSize
[File:D:\HordeAgent\Sandbox\Rel\Sync\Engine\Source\Runtime\D3D12RHI\Private\D3D12Device.cpp] [Line: 372]
[Callstack] FactoryGameSteam-RHI-Win64-Shipping.dll!RHIInit()
[Callstack] FactoryGameSteam-Win64-Shipping.exe!FEngineLoop::PreInitPreStartupScreen()
D3DMetal itself is detected fine and advertises a fully capable device:
LogD3D12RHI: Found D3D12 adapter 0: AMD Compatibility Mode (VendorId: 1002, DeviceId: 66af)
LogD3D12RHI: Max supported Feature Level 12_2, shader model 6.6, binding tier 3, wave ops supported, atomic64 supported
LogRHI: RHI D3D12 with Feature Level SM6 is supported and will be used.
Because it reports resource binding tier 3 / SM 6.6, UE enables bindless samplers and sizes its global sampler descriptor heap against the full D3D12 budget, which D3DMetal apparently doesn't actually have. The assert then kills the process.
Not fixable from config (tested)
I tried clamping the heap from the game's user Engine.ini, in both [ConsoleVariables] and [SystemSettings], using the cvar names extracted from the game's own FactoryGameSteam-D3D12RHI-Win64-Shipping.dll:
D3D12.GlobalSamplerDescriptorHeapSizeD3D12.GlobalSamplerHeapSizeD3D12.Bindless.SamplerDescriptorHeapSize
The assert still fires at 1024, and — the decisive test — still fires at 16. A value of 16 failing means that variable isn't ini-reachable in this build and the effective maximum is essentially zero, so there's no user-side value that satisfies it.
Workaround
DX11 works completely. The game runs to its main menu and plays, via DefaultGraphicsRHI=DefaultGraphicsRHI_DX11 in the user Engine.ini, or -dx11 on the command line. Worth noting the ini route is fragile: UE rewrites that file on exit, and after one crash-exit it dropped the entire [/Script/WindowsTargetPlatform.WindowsTargetSettings] section and silently reverted to the packaged D3D12 default. A launch argument survives that; the ini doesn't.
Also, Satisfactory's in-game graphics-API selector writes that same key, so a user picking Vulkan or DX12 there breaks startup with no window and no obvious cause. Vulkan fails separately with VK_ERROR_INCOMPATIBLE_DRIVER on profile VP_UE_Vulkan_SM6 (MoltenVK can't provide UE5's Vulkan SM6 profile).
Why I'm not sending a patch
The obvious launcher-side fix — extend the existing -d3d11 auto-add from UE4 to UE5 — would be wrong. That code is UE4-only by design, with the comment noting UE5 needs D3D12 for Nanite/Lumen, so forcing DX11 across all UE5 titles would visually downgrade every one of them to fix one. If you'd want a narrow per-title quirk list (appid → extra args) I'm happy to put that together, but the real fix looks like it belongs in D3DMetal's reported sampler-heap capability versus its advertised binding tier.
Related: #176 fixes two separate reasons this same game wouldn't launch at all.
🤖 Generated with Claude Code
Filing this as an issue rather than a PR, because I don't think the fix belongs in the launcher — see the last section.
Symptom
Satisfactory 1.2 (appid 526870) crashes during graphics init on the
d3dmetalbackend, before any window appears:D3DMetal itself is detected fine and advertises a fully capable device:
Because it reports resource binding tier 3 / SM 6.6, UE enables bindless samplers and sizes its global sampler descriptor heap against the full D3D12 budget, which D3DMetal apparently doesn't actually have. The assert then kills the process.
Not fixable from config (tested)
I tried clamping the heap from the game's user
Engine.ini, in both[ConsoleVariables]and[SystemSettings], using the cvar names extracted from the game's ownFactoryGameSteam-D3D12RHI-Win64-Shipping.dll:D3D12.GlobalSamplerDescriptorHeapSizeD3D12.GlobalSamplerHeapSizeD3D12.Bindless.SamplerDescriptorHeapSizeThe assert still fires at 1024, and — the decisive test — still fires at 16. A value of 16 failing means that variable isn't ini-reachable in this build and the effective maximum is essentially zero, so there's no user-side value that satisfies it.
Workaround
DX11 works completely. The game runs to its main menu and plays, via
DefaultGraphicsRHI=DefaultGraphicsRHI_DX11in the userEngine.ini, or-dx11on the command line. Worth noting the ini route is fragile: UE rewrites that file on exit, and after one crash-exit it dropped the entire[/Script/WindowsTargetPlatform.WindowsTargetSettings]section and silently reverted to the packaged D3D12 default. A launch argument survives that; the ini doesn't.Also, Satisfactory's in-game graphics-API selector writes that same key, so a user picking Vulkan or DX12 there breaks startup with no window and no obvious cause. Vulkan fails separately with
VK_ERROR_INCOMPATIBLE_DRIVERon profileVP_UE_Vulkan_SM6(MoltenVK can't provide UE5's Vulkan SM6 profile).Why I'm not sending a patch
The obvious launcher-side fix — extend the existing
-d3d11auto-add from UE4 to UE5 — would be wrong. That code is UE4-only by design, with the comment noting UE5 needs D3D12 for Nanite/Lumen, so forcing DX11 across all UE5 titles would visually downgrade every one of them to fix one. If you'd want a narrow per-title quirk list (appid → extra args) I'm happy to put that together, but the real fix looks like it belongs in D3DMetal's reported sampler-heap capability versus its advertised binding tier.Related: #176 fixes two separate reasons this same game wouldn't launch at all.
🤖 Generated with Claude Code