jlrouzies-fr/DLSS5-Feeder v0.13.0-beta.1

0.13.0-beta.1

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 fix-only beta on top of 0.12.1-beta.2, opening a 0.13 line because one change alters behaviour rather than merely fixing it (see enabled=0 below). Everything here came out of issue reports filed over the last two days; three of the five are bugs found by reading a reporter's log rather than by reproducing anything here.

32-bit games: take BOTH dlss5-feed.addon32 and host64\dlss5-feed-host64.exe from this zip. The helper protocol is unchanged (still v7), so mixed halves will start without complaining — but the fixes live half in each binary and simply will not be there if you update only one side.

The 32-bit add-on was mis-stamped through the whole 0.12.1 series and reported 0.12.1-beta.1 regardless of which one you installed. From this build both halves report the same version.

The cast panel freezes while the helper is fine (#33)

The helper copies the frame it has just presented into the texture the 32-bit game shows in its in-game panel, and it chose that frame with:

const UINT presented = (g_swap3->GetCurrentBackBufferIndex() + 1) % 2;

That was correct when the swapchain had two buffers. A third was added later (issue #15, so that one present per evaluate is actually reachable) and this line was never revisited. With three buffers it picks 0 or 1 arbitrarily and never 2, so the panel was fed a stale frame about a third of the time — a picture that stops tracking the helper while the helper is perfectly healthy. The buffer count now comes from the swapchain.

The helper window goes "Not Responding" (#33)

The helper is single-threaded: one thread owns the window, the pipe and the GPU queue. Two separate ways that thread stopped pumping messages:

• The frame path's "no DLSS feature yet" branch was a bare continue that skipped the only PumpPresent in the loop. With frames arriving at game rate the tag wait never goes idle either, so the window went genuinely unpumped — Windows ghosts it within seconds while fences keep being signalled and the game runs on normally.
• Message bodies were read with an unbounded GetOverlappedResult(..., TRUE) on that same thread, over a 1 KB pipe. A game that stalled mid-message froze the window with no upper bound. That wait is now bounded, pumps messages while it waits, and drops the connection rather than hanging.

There is also a new log line when the present debt has sat at its cap for 120 evaluates, which is the state where the window really has stopped repainting. A rising presents skipped count on its own reads as benign, because it usually is.

enabled=0 now actually disables everything (#44)

This is the behaviour change, and why the version is 0.13.

It did not. enabled was consulted in exactly four places, all inside the per-frame feed path. Everything else kept running: the add-on still tracked ReShade runtimes, resolved techniques, texture variables and preprocessor definitions, read the helper's ReShade.ini, scanned the module list for Smooth Motion, loaded dbghelp.dll, polled every virtual key on each present, and — on Vulkan — installed MinHook trampolines over vulkan-1's exports from create_device, which was never gated at all.

That made "set enabled=0 and see whether it still crashes" a test that proved nothing, which is exactly what it had been used for.

Now enabled=0 leaves only the overlay page, so the Enabled checkbox can undo it, and the log says on its first line what is and is not still running. Two consequences worth knowing if you use it as an A/B:

• on a Vulkan game, turning it back on needs a restart — the interop hook can only be installed before the game creates its Vulkan device, which has already happened by the time you tick the box;
• a hook already installed with enabled=1 stays until the game exits.

The crash line no longer guesses (#44)

this add-on was last doing: starting up was the default value of that field, reported whenever no feed work had run yet — not a finding. With the feed off it could never say anything else, and I read it on an issue as evidence that a crash had happened during our startup. It now reads nothing yet -- no feed work has run in this process. The informative half of that line is unchanged: the module named as the faulting one.

The helper stops destroying its own log (#46)

dlss5-feed-host.log is opened for truncation as the very first thing the helper does. So double-clicking dlss5-feed-host64.exe to find out why a window flashes and vanishes — an entirely reasonable thing to do — erased the log of the run you were trying to explain. A run with no arguments now says what the program is and exits without touching the log.

Along with it:

• the helper logs its full command line and argc before parsing them, so a log that ends at the usage line says why;
• the first numeric argument wins, instead of a later unrecognised token silently zeroing an already-parsed pid;
• an unwritable host64\ — a game installed under Program Files — falls back to %LOCALAPPDATA%\DLSS5-Feeder. Until now both attempts to open the log failed in silence, and CREATE_NO_WINDOW means there is no console to complain to either, so the helper simply ran mute;
• the add-on reads the helper's exit code instead of discarding it, so "the 64-bit host went away" carries a number.

NGX failing in-process while the helper succeeds (#47, #48)

Diagnostic, not yet a fix — but it may fix itself on your machine.

Three machines report NVSDK_NGX_D3D12_Init -> 0xBAD00001 (FeatureNotSupported) from the in-process session in a 64-bit game, while the same files, the same driver and the same RenoDX build initialise NGX fine inside the host64 helper — and on at least one of them the game's own native DLSS works. Comparing the two call sites, exactly one argument differs:

NGX writes its own logs into the application data path, and for a game under Program Files that folder is not writable without elevation the game does not have. Nothing logged the path, nothing checked it, and nothing ever passed a FeatureCommonInfo — so NGX had never been told to look anywhere but beside the exe for a feature runtime.

Rather than send three reporters three builds, this one tries each candidate in a single run and logs every result: the add-on's folder as before, then host64\, then a created folder under %LOCALAPPDATA%. If one works, the log names it and the session starts. If your NGX already initialises, attempt 1 succeeds exactly as before and the second is never reached.

Also new on failure: the adapter by LUID as well as by name on both sides, a writability probe on the data path, the resolved paths of every loaded nvngx* / _nvngx.dll, and the NGXCore registry entry — read from inside the failing process. The helper's error-name table was missing 0xBAD00001 entirely, so it printed (?) for the one failure being reported.

This does not explain the case where the helper itself fails with the same code. If that is you, please say so on #47 with the new logs; it is likely a second, different problem.

Verified here: all four binaries build clean, and the helper's --test rig stays at 300/300 evaluates. Everything above is reasoned from reporters' logs — the games involved (NFS Most Wanted 2012, Bayonetta, Medal of Honor: Warfighter, Mafia DE) are not reproducible on this machine. Please post dlss5-feed.log, host64\dlss5-feed-host.log and ReShade.log from the same run on the relevant issue.