You probably do not need to install this by hand. There is a one-command installer that does
everything the README's manual sections describe:
tools/Install-DLSS5Feeder.ps1.
Download it, right-click → Run with PowerShell, point it at your game folder. It fetches ReShade,
the shaders, the neural consumer and both NVIDIA runtimes, and switches (-Consumer,-LocalFiles,
-NoElevate,-Api) cover the awkward cases. SeeAUTOMATIC_INSTALLATION_AVAILABLE.txtin the
assets below.
Take Verify-DLSS5Feeder.ps1 from this zip as well — two of the fixes below are in the tooling, and one of them is the reason a working install could be reported as broken.
32-bit games: update BOTH dlss5-feed.addon32 and host64\dlss5-feed-host64.exe. IPC stays at v8.
A tracker release. The open issues were re-read against the source rather than against the threads, which is how most of them turned out to be already fixed and waiting on a retest. Nine were not.
The installer was leaving two neural consumers loaded
The RenoDX add-on also ships under versioned names — renodx-dlss5-4.7.addon64. The add-on itself has matched that since #1; the two PowerShell scripts did not.
Verify-DLSS5Feeder.ps1reported "No neural consumer found" — a hard failure — on a perfectly good install.Install-DLSS5Feeder.ps1disables a competing RenoDX add-on when it installs Deep Fried Chicken, so Chicken is not left inert. With a versioned filename it disabled nothing, and both stayed loaded — which is exactly the state where Chicken does nothing and every check still looks healthy.
If you have wondered why the tickbox says neural rendering is on and the picture says otherwise, check this first (#44). Every copy is disabled now, not just the first.
"NGX would not initialise on this device/driver" was often wrong
That line pointed at your hardware, and it sent people to reinstall drivers on machines where the same files work in another game minutes later.
The add-on already asked NGX a capability question before every init attempt — one that touches no device and creates no feature — and in every failing log of #47 that query answers 0xBAD00002 PlatformError about 7 ms before init fails. It logged that and then said the sentence above anyway. The failure line is now written from what NGX actually answered:
- refused in this process → not your GPU and not your driver; something else loaded into the game is blocking NGX (an overlay, an injector, anti-cheat, a second NGX consumer).
- adapter below the floor → DLSS 5 neural rendering has a minimum GPU architecture, and Turing and older are below it.
feature 18 create failed 0xBAD00001on a 20-series card is the correct answer, not a bug (#73). DLAA still works; the neural pass does not.
64-bit: a game could latch off with stopped: repeated failures
Output is the only one of the four shared textures created with an unordered-access bind, and some D3D11 devices refuse it at a size and format they accept for Color. On the in-process 64-bit path there was no fallback (#70, Metro Last Light Redux).
The 32-bit add-on and the 64-bit helper have both had the answer for a while, and it is now here too: the shared Output is rebuilt without the UAV, DLSS writes a private texture, and the result is copied into the shared one on the same command list —
Output 3440x1440 R8G8B8A8_UNORM: shared copy without UAV, DLSS writes a private texture
The failure line also names which of the three calls refused (CreateCommittedResource / CreateSharedHandle / OpenSharedResource1) and prints the device's feature level.
The GPU-hang reports finally have a trail worth reading
A correction on #63: the missing breadcrumb arming was a real gap but it was not the cause, and that reporter's breadcrumbs were never empty.
Three DRED nodes is this project's own three-frame ring, so the queue that hung is the feeder's, not the game's — and no page fault recorded makes it a genuine hang rather than an invalid access. What could not be told from the dump was whether the faulting ResourceBarrier was one of ours or one of the many NGX records into the same list, because nothing but the device was ever given a debug name, so it read queue='(unnamed)' list='(unnamed)'.
Everything is named now — queue, allocators, list, every shared texture — and the frame is bracketed into copy-in / ngx-evaluate / copy-home. A dump from this build says which phase hung. If you are on #57 or #63, a fresh log is worth posting.
One real bug found in there: the wait on the game's fence was enqueued before the command list was opened, so when opening it failed — which is what happens once the GPU stops retiring allocator slots — the wait stayed on a queue that was already stuck, and the feed re-armed against it every frame.
Vulkan: the transport had no crash guard at all
Every fault guard in this project was around an NGX call, because that is where faults were expected. A fault anywhere in feed_vk.h went straight to the game. It is wrapped now: a fault there disables the feed and leaves the game running.
And the hooks no longer come out from under a live call. Removing a hook frees the memory holding the original instruction bytes, and doing that while another thread is mid-call is an execute fault at an address in no module — which is what X4 Foundations reports on Exit to Desktop (#62). The teardown now disables first, waits for anything already inside to leave, and only then frees; the waiting happens on device destruction, where waiting is legal, rather than at unload, where it is not.
Smaller things
- The verifier picked
studiomdl.exe— the Source engine's model compiler — as the game executable in a Garry's Modbin\folder, because it was simply the largest.exethere, and described the whole install relative to it. It now skips engine tooling, prefers an executable that names a graphics runtime, and says when the pick was a guess (#60). - The verifier claimed "Direct3D 9 via dgVoodoo2" from any local
d3d9.dllplus a straydgVoodoo.confwithout asking the file who it was, and described ReShade's own D3D9 backend as a bland "Direct3D" install instead of the hard failure it is. - The 32-bit cast panel posted key and button releases into a window handle a resize can invalidate, and the helper's message drain is guarded so a fault in a dispatched message names itself instead of taking the helper down (#58).
- The depth resource's real format, footprint and pitch as handed to NGX are logged once per session — what #13's bit-identical depth constant needs next.
A caveat worth reading
None of these nine reproduce on the machine they were fixed on — there is no UAV-refusing device here, no machine where NGX answers PlatformError, and no copy of X4. Every one is reasoned from the logs in the issue and needs a retest from the person who reported it. If one of these is yours, a log from this build is the thing that closes it.
Also in this tag, from #67 (@WitDD): an opt-in SourceGuidedColor.fx, contributed and merged separately from the above. It is not in the zip; take it from the repo if you want to try it.