DLSS5-Feeder: feeding a DLAA contract to games that never call DLSS

The gap DLSS5-Feeder fills: games that never make a DLSS call

The DLSS 5 neural-rendering add-on works by hooking a game's own DLSS calls. A game that ships without DLSS never makes those calls, so the add-on has nothing to attach to and sits idle. DLSS5-Feeder makes the calls itself. It constructs a complete DLSS DLAA contract out of what ReShade already has (the frame being processed, the depth buffer, and estimated optical-flow motion vectors), runs a genuine DLSS evaluate, lets the DLSS 5 add-on hook into that evaluate, and copies the neural result back into the frame. The README describes the whole path as a chain inside ReShade's effect list: game frame, ReShade effects, motion vectors, DLSS5_Feed, then the neural output written back over the frame before later effects and present.

The audience is narrow and the README is explicit about it. If your game is 64-bit and uses DirectX 9, 11 or 12, ShortFuse's renodx-dlss add-on does the whole job by itself and you do not need this project. DLSS5-Feeder is for 32-bit games of any graphics API, Vulkan games, and DirectX 9 games where you want the best handling of motion. The reasoning is structural rather than preferential: renodx-dlss is 64-bit only, and NVIDIA ships no 32-bit NGX runtime at all, so an in-process approach is impossible there by construction. On D3D9, renodx-dlss evaluates only the finished backbuffer with no temporal inputs, while this project drives a full temporal evaluate from ReShade motion vectors.

How the synthetic DLAA contract is assembled

The pipeline has four moving parts. ReShade supplies the frame, the depth buffer and estimated optical-flow motion vectors. The DLSS5_Feed effect is where the contract is built. A private D3D12 device carries the evaluate, and the neural add-on hooks that evaluate rather than the game's own calls. The result is written back over the frame inside the effect chain, so later ReShade effects and the present step see the neural output as ordinary frame content.

The cross-process helper is what makes 32-bit games possible. Because no 32-bit NGX runtime exists, the work cannot happen in the game's process. The repository layout reflects this split: host/, layer/, shaders/, src/, spike/, tests/ and tools/ sit alongside build.bat and build-addon32.bat. The README also notes that in the host64 helper the feeder unbinds the global hotkeys, so a gameplay keypress cannot silently toggle neural rendering in a background process. That is a small detail with real consequences: the helper runs as a separate process, and input routing between the two is a failure surface the project has chosen to close rather than manage.

DLSS5-Feeder does not sharpen anything by itself. It builds the request the game never makes; a second add-on performs the actual neural rendering, and you install exactly one. The README warns that if Deep Fried Chicken finds RenoDX's add-on or Alex's Toolkit loaded beside it, it does nothing at all for the whole session, silently as far as your eyes are concerned. Two neural add-ons is not a configuration, it is a no-op.

Installing DLSS5-Feeder and running a first evaluate

The repository ships an automated installer, shown in the README as dlss5-feeder-install-script.png, and an AUTOMATIC_INSTALLATION_AVAILABLE.txt marker at the top level. The README also refers to an automated way in its own anchor text. Beyond that, the exact installer invocation is not spelled out in the README, so treat the installer as the intended path and verify the pieces below rather than inventing a command line.

Before anything else, check whether the driver, NGX runtime and neural consumer combination works on your machine. The README gives this as a fifteen-second check with no game running:

host64\dlss5-feed-host64.exe --test

The expected output is 300/300 evaluates succeeded. Anything else means the combination is broken before a game is involved. The README's own table was measured with --test on one RTX 5090 through the 64-bit helper, and it shows driver 616.64 failing with renodx-dlss5 v4.6 and v4.7 (1/300 and 0/300 respectively) while driver 616.56 succeeds on v4.7. On 616.64 and later the evaluate faults inside NVIDIA's own nvngx_dlssnr.dll, tracked as issue #54.

Next, install exactly one neural add-on. The recommended one is Deep Fried Chicken, version 1.4.8 or newer, from its Discord. Copy its three files next to your game's .exe, or into host64\ for a 32-bit game:

deep-fried-chicken.addon64
deep-fried-chicken-nvngx.dll
deep-fried-chicken.cfg

Its settings file already arrives set up correctly, so leave it alone for your first run. You supply nvngx_dlssnr.dll and nvngx_dlss.dll yourself. The older option is Krish's RenoDX add-on, renodx-dlss5.addon64 from the #DLSS5 build in the RenoDX Discord. The feeder fingerprints whichever build it finds and adapts, and writes EnableHooks=2, NeuralUplift=1 and NREnableUpscaling=0 when those keys are unset. Note the versioning caveat: before 0.11.0-beta.2 only the exact filename was recognised, and a versioned file such as renodx-dlss5-4.7.addon64 was logged as not found and treated as the classic engine. Keep just one copy, because ReShade loads them all.

Finally, before reporting anything, run Verify-DLSS5Feeder.ps1 in the game folder. The README names this script twice as the prerequisite for a bug report.

Driver 616.64, nvngx_dlssnr.dll and the combinations that fail

The most concrete limitation documented here is not about games at all. It is about the combination of driver, NGX runtime and neural consumer. The README states plainly that some combinations do not work and that it is usually the combination, not the game. On driver 616.64 the evaluate faults inside NVIDIA's own nvngx_dlssnr.dll, and the README lists three things that work instead: Deep Fried Chicken, a classic-engine renodx-dlss5, or driver 616.56.

The distinction between classic-engine and lazy-adoption renodx-dlss5 builds is worth reading carefully, because it cuts against the habit of always taking the newest build. On driver 616.64, v4.55 and latest classic-engine builds both pass 300/300, while v4.6 and v4.7 of the lazy-adoption engine fail. On 616.56 the picture changes again: v4.7 passes. So the safe choice depends on your driver, and upgrading the add-on can move you from working to broken. The README's table also has blank cells, which it identifies as combinations nobody has run. Those are honest gaps, not implied failures, and they are the first place a new user's configuration is likely to land.

There is a second failure mode that is quieter. Installing two neural add-ons produces no error and no visual change, because Deep Fried Chicken disables itself for the whole session when it detects a sibling. A user who has previously installed RenoDX's add-on and then adds Deep Fried Chicken will see nothing happen and may blame the feeder. The README calls this the first thing to check when something looks like it is not working, and that ordering is correct.

Where DLSS5-Feeder is the wrong tool

If your game is 64-bit and DirectX 9, 11 or 12, this project is the wrong choice. The README says so directly and points to renodx-dlss instead, describing it as one add-on rather than two with nothing for this project to add. That is an unusual thing for a README to lead with, and it is the most useful paragraph in the document. Adding DLSS5-Feeder to a game that renodx-dlss already covers buys you a second process, a second add-on to keep in sync, and a driver-combination matrix to debug, in exchange for nothing.

The second boundary is maintenance capacity. The README states that the author cannot test every game reported in the issues, because he does not own them or does not have time to try all of them. That is a real constraint on what a bug report can achieve. The README's suggested workaround is to clone the repository with an AI coding subscription, check the different logs, implement a fix and open a pull request. Whatever you think of that suggestion, it tells you the project expects users to debug their own titles, and it means a game that is not already known to work is not a supported configuration in any practical sense.

A third boundary is distribution. The README warns that malicious websites were making users download ZIP files with names similar to this project, for example DLSS5-Feeder-v0.7.0.zip, and states that the only official release is on this GitHub. Combined with the neural add-ons living on Discord rather than GitHub, this is a project where provenance matters and where a search result is not a safe source.

Alternatives and the actual difference in approach

The primary alternative is ShortFuse's renodx-dlss, recommended in the README itself for 64-bit DirectX 9, 11 and 12 games. The difference is architectural. renodx-dlss is a single add-on that does the whole job, so there is no separate feeder, no cross-process helper, and no host64 folder. DLSS5-Feeder splits the work: one component builds the DLAA contract from ReShade depth and motion vectors, another performs the neural rendering. That split is what lets it reach 32-bit games, where renodx-dlss cannot go at all because it is 64-bit only, and Vulkan games, which are covered here through the bundled layer.

The second alternative is Krish's RenoDX add-on, renodx-dlss5.addon64, which the README describes as the older option and still fully supported. It is not an alternative to DLSS5-Feeder; it is an alternative neural consumer that sits beside it. Every release up to the time of writing was developed against it, and the feeder fingerprints whichever build it finds and adapts. The practical difference is in the compatibility table: the classic-engine builds pass on both 616.56 and 616.64, while the lazy-adoption engine builds do not. If you are on 616.64 and want to stay there, the RenoDX path with a classic-engine build is the documented way through.

On DirectX 9 specifically, the difference is about inputs rather than packaging. renodx-dlss evaluates only the finished backbuffer there, with no temporal inputs. DLSS5-Feeder drives a full temporal evaluate from ReShade motion vectors. That is a quality argument, not a convenience one, and it is the case where the extra complexity of two add-ons is buying something.

Licence, maintenance and upgrade cost

The repository's licence is reported as NOASSERTION, which means GitHub could not match the LICENSE file to a known licence identifier. The README does not discuss licensing terms, and nothing in it describes redistribution rights, commercial use, or what happens if you ship this alongside a game. Read the LICENSE file at the top level yourself before you rely on any of that. This is a description of what the repository states, not legal advice.

Maintenance is active in the narrow sense that the last push was on 2026-09-14, and the recent release list shows v1.16.0-beta.2 on the same date, v1.16.0-beta.1 on 2026-09-10, and v0.15.1 on 2026-09-09. The cadence is fast and the version labels are mostly beta. The v0.15.1 release note is a single line about the neural pass wrecking HDR highlights, and v1.16.0-beta.1 is labelled with recent logged bug reports. That tells you what an upgrade costs: you are tracking a beta line where a fix for one rendering artefact can arrive in the same week as a regression report.

The dependency surface is the real upgrade cost. You are maintaining a driver version, an NGX runtime, a neural consumer add-on, and the feeder itself, and the compatibility table shows those four interacting. The README pins a minimum feeder version of 0.14.0-beta.2 or newer for the current guidance. When one of the four moves, re-run the test before you play.

Editorial conclusion

Adopt DLSS5-Feeder when your game is 32-bit, Vulkan, or DirectX 9 and you want a temporal evaluate driven by ReShade motion vectors; a 64-bit D3D9, 11 or 12 game should use renodx-dlss alone instead. Before reporting anything, run host64\dlss5-feed-host64.exe --test with no game running and confirm 300/300 evaluates succeeded, then run Verify-DLSS5Feeder.ps1 in the game folder. If the test fails on driver 616.64, the fault is in NVIDIA's nvngx_dlssnr.dll, and the README names three workarounds: Deep Fried Chicken, a classic-engine renodx-dlss5, or driver 616.56.

Frequently asked questions

Official sources

1. Issues
2. jlrouzies-fr/DLSS5-Feeder on GitHub
3. README
4. Releases