jlrouzies-fr/DLSS5-Feeder v0.12.1-beta.2

0.12.1-beta.2 - an HDR (FP16) back buffer no longer removes the device on Vulkan/OpenGL

on GitHub

⚙️ You probably do not need to install this by hand

Install-DLSS5Feeder.ps1 does the whole install from one command — ReShade, this feeder, LumeniteFX, your chosen neural consumer, both NVIDIA runtimes, dgVoodoo2 for Direct3D 8/9, and the .ini files with the techniques already enabled in the right order. Drop it next to the game's .exe, right-click ▸ Open in Terminal, and run:

powershell.exe -ExecutionPolicy Bypass -File .\Install-DLSS5Feeder.ps1

Existing files are merged and backed up, never replaced, and it finishes with a verification pass. See AUTOMATIC_INSTALLATION_AVAILABLE.txt in the assets below for the full details and the unattended-run switches.

A one-fix beta on top of 0.12.1-beta.1: a lost D3D12 device on Vulkan and OpenGL games that present an HDR (FP16) back buffer.

Everything in 0.12.1-beta.1 still needs testing — nothing there changed.

The device removed at frame 60 on an HDR Vulkan/OpenGL game

If the game presented an 8-bytes-per-texel back buffer — R16G16B16A16_FLOAT, which is what HDR gives you, and what a RenoDX scRGB add-on produces on a game with no native HDR — the feed's private D3D12 device was removed at frame 60 of every run, with DXGI_ERROR_INVALID_CALL. The feed then latched off for the session while the game carried on normally.

The cause was one of this add-on's own diagnostics. Every 60 frames the staleness probe copies a 64×64 block of the colour input and the DLSS output into a readback buffer, so that when the screen freezes while every frame still reports "delivered", the log can say which hop of the transport went stale. Its row pitch was a compile-time constant:

static const UINT kStaleProbePitch = 256;   // 64 texels of a 4-byte format, already row-pitch aligned

while the copy itself used the game's actual format. The assumption held for every format this add-on had ever met: R8G8B8A8_UNORM, B8G8R8A8_UNORM, R10G10B10A2_UNORM and R11G11B10_FLOAT are all 4 bytes per texel, so 64 texels are exactly 256 bytes — which is also D3D12's row-pitch alignment. Two constraints agreeing by coincidence is what kept it invisible. At 8 bytes a row is 512, the footprint describes a region that cannot exist, and the runtime rejects the copy while the list is recorded.

What turned that into a lost device was a missing check two functions away:

g.list->Close();                          // HRESULT discarded
g.queue->ExecuteCommandLists(1, lists);   // submits a list in an error state

Executing a command list that failed to close is an invalid call, and the runtime removes the device for it. That is also why DRED had nothing to report: no work ever reached the GPU, so there were no breadcrumbs and no page fault.

Both are fixed. The probe sizes its pitch from the format; a list that will not close is never submitted, and a recording error now costs one frame instead of the device.

Who was affected

• Vulkan or OpenGL games only. The probe is not called on the native D3D11 or D3D12 paths, so those were never exposed, whatever their back-buffer format.
• Only with an FP16 back buffer, i.e. in practice only with HDR.
• If your game is 4 bytes per texel, this build behaves identically to 0.12.1-beta.1 — the computed pitch for a 4-byte format is 256, the same number as before, byte for byte.

Found on The Surge 2 (Vulkan, no native HDR, a RenoDX add-on upgrading the swapchain to scRGB). Verified there; verified as no-change on DOOM (2016) (Vulkan, BGRA8) and Metro 2033 Redux (D3D11, FP16 — unaffected either way, which is the point).

The full post-mortem, including the three misreadings that cost a day, is in FP16-DEVICE-REMOVAL.md.

Also in this build

Diagnostics kept from the hunt, because this class of failure is intermittent and otherwise nearly unattributable:

• After each D3D12 call in the frame path the device-removed reason is checked, so a removal names the call that did it and the last call that was still fine.
• DRED is enabled on the private device and dumped on removal. Worth knowing how to read it: DXGI_ERROR_UNSUPPORTED for both breadcrumbs and page fault is not DRED failing — it means nothing reached the GPU, so look at the CPU-side calls.
• A failed Close() logs the full frame geometry with it.
• The D3D12 debug layer can be enabled with DLSS5_FEED_D3D12_DEBUG=1. Off by default: in at least one host process it makes D3D12CreateDevice itself fail with DXGI_ERROR_DEVICE_RESET, while the same calls succeed in a bare process.

Vulkan interop — unrelated to the above, and fixed nothing on its own: an imported D3D12 texture is now bound with the size D3D12 actually allocated (GetResourceAllocationInfo) rather than the size Vulkan computed for an image of its own, which is what the OpenGL path has always done; and the memory type is chosen by asking for DEVICE_LOCAL rather than by taking the lowest allowed bit.

Upgrading

Replace the files. For 32-bit games take both dlss5-feed.addon32 and host64\dlss5-feed-host64.exe. The helper protocol is unchanged (still v7). Existing dlss5-feed.cfg files keep working; no defaults changed.