jlrouzies-fr/DLSS5-Feeder

↓ Jump to the Table of Contents

⚠️ Careful of fake malicious websites

We got information that some malicious websites were making users download ZIP using similar name as this project, e.g. DLSS5-Feeder-v0.7.0.zip.

The only official release of DLSS 5 Feeder is on this GitHub, so be careful!

This now includes copies of this repository on GitHub itself: same source tree, but the README replaced by a "Download" button leading to a ZIP on a personal github.io page, sold as "double-click to run, it detects your game". This project has no executable installer, only a PowerShell script you can read, and the only download is https://github.com/jlrouzies-fr/DLSS5-Feeder/releases. If you got a ZIP anywhere else, delete it and scan your machine.

Thank to NIGos for the report, and to the reporter of #115.

ℹ️ Does not work with your game? Read this part

Please note that I cannot test every games reported in the issues (as I simply do not own them or don't have time to try all).

If you are really looking for a specific game to work, see to get like a Claude Pro subscription, install it and ask it the following:

"Here is my game folder: [GAME PATH] ; I am using https://github.com/jlrouzies-fr/DLSS5-Feeder but sadly it doesn't work well. Can you help clone it, check the different logs, and implement a fix? Then if you implement a legitimate fix, make a pull request."

⚠️ Nvidia Driver can cause issues with some addons

Some combinations of driver, NGX runtime and neural consumer do not work — it is usually the combination, not the game. Check yours in fifteen seconds, with no game running: host64\dlss5-feed-host64.exe --test (300/300 evaluates succeeded means you are fine). The scenarios we know about:

neural consumer	driver 616.56	driver 616.64	driver 617.14
(none — DLAA only, no neural pass)	—	✅ 300/300	—
Deep Fried Chicken 1.4.8-alpha	—	✅ 300/300	—
renodx-dlss5 v4.55 (classic engine)	—	✅ 300/300	—
renodx-dlss5 "latest" (classic engine)	—	✅ 300/300	—
renodx-dlss5 v4.6 (lazy-adoption engine)	—	❌ 1/300	—
renodx-dlss5 v4.7 (lazy-adoption engine)	✅ 300/300	❌ 0/300	❌ 0/300
renodx-dlss5 v6.1.0	—	—	✅ 300/300
renodx-dlss5 v7.0.0-rc8	—	—	✅ 300/300
renodx-dlss5 v8.0.1 (beta 8)	—	—	✅ 300/300

Blank cells are combinations nobody has run. Measured with --test on one RTX 5090 through the 64-bit helper; every ✅ on 617.14 also created and evaluated the neural feature. On 616.64+ the v4.6/v4.7 evaluate faults inside NVIDIA's own nvngx_dlssnr.dll (#54) — any one of these works: a renodx-dlss5 v6.1 or newer (what the installer now downloads), Deep Fried Chicken, a classic-engine renodx-dlss5, or driver 616.56.

The neural model runs on RTX 50 only. NVIDIA's signed nvngx_dlssnr.dll 310.8.0, and the modified 310.8.Lecram build the installer downloads, create the neural feature on RTX 50-series GPUs only. On an RTX 20/30/40 DLSS still runs but the neural pass does not (feature 18 create failed with 0xbad00001 in ReShade.log, #131): get the modified nvngx_dlssnr.dll made for your GPU from the RenoDX Discord. Verify-DLSS5Feeder.ps1 says so at the end.

Use 0.14.0-beta.2 or newer, and run Verify-DLSS5Feeder.ps1 in the game folder before reporting anything.

DLSS 5 neural rendering in games that ship without any DLSS — D3D11, D3D12, Vulkan, OpenGL, 32-bit, even DirectX 10 and DirectX 9.

DLSS 5's neural-rendering add-on only works by hooking a game's own DLSS calls. A game that has no DLSS never makes those calls, so the add-on sits idle. DLSS5-Feeder makes the calls itself. It builds 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 neural-rendering add-on hook into that evaluate, and copies the neural result back into the frame. All inside ReShade's effect chain.

game frame → ReShade effects → [motion vectors] → [DLSS5_Feed] → DLSS5-Feeder:
                                                    depth + MV     DLSS DLAA + DLSS 5 neural rendering
                                                                   ↓
                                    neural output written back over the frame → later effects → present

↓ Jump to the Contents

None of this is hard, and the automated installer verifies most of it for you.

If your game is 64-bit and uses DirectX 9, 11 or 12, there is now a simpler option: ShortFuse's renodx-dlss add-on does the whole job by itself. Use that instead — it is one add-on rather than two, and there is nothing for this project to add.

The first row presumes the game calls DLSS itself. renodx-dlss works by hooking the DLSS calls a game already makes; in a game that has no DLSS of its own there is nothing for it to hook, and it sits at Auto: Waiting (or Present: Waiting) with every counter at zero — application frame 0, DLAA/SR 0, RR 0, Upscaled resource ID: 0x0 — while looking perfectly healthy in the log. That is not a fault; it is the add-on having nothing to work with. Monster Hunter: World is a measured example (#120). A 64-bit DirectX 9/11/12 game with no native DLSS needs this project to manufacture the frames for it, the same as a 32-bit one.

renodx-dlss is not on GitHub. It comes from the RenoDX Discord, #DLSS5 channel: https://discord.com/invite/renodx

DLSS5-Feeder does not sharpen anything by itself. It builds the DLSS request your game never makes; a second add-on does the actual neural rendering. You install exactly one of them.

Recommended: Deep Fried Chicken, by Alexander, from its Discord: https://discord.gg/g2v2XGqvR — take 1.4.8 or newer.

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 and 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, as always.

Never install two neural add-ons. 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. Pick one. If something looks like it is not working, this is the first thing to check.

• OptiScaler — a stock OptiScaler must be off. It takes over the very NGX calls this project makes, upscales them, and never runs a neural pass, so the picture never changes while every log reads healthy. The exception is a DLSS-NR fork of it (wilsjo2's OptiScaler-DLSSNR-PreSR-Multipass or Dagherbou's OptiScaler_DLSSNR), which is a supported neural consumer — see Alternative: OptiScaler DLSS-NR. With it installed there must be no Deep Fried Chicken and no RenoDX add-on beside it.
• NVIDIA Smooth Motion — turn it off for Vulkan games only. On Vulkan the two cannot work together, and no future release can fix that. You would see roughly half your frames unprocessed, which looks like heavy flickering or a picture stuck on an old frame. Nothing is broken and nothing is crashing; it simply cannot work.
• DirectX 11 and 12 games are fine. Leave Smooth Motion on there if you like it.

To switch it off for Vulkan alone and keep it everywhere else: in NVIDIA Profile Inspector, set Smooth Motion - Enabled APIs (0xB0CC0875) and clear the Vulkan bit — the value is a sum of 1 for DX12, 2 for DX11 and 4 for Vulkan, so 7 becomes 3.

A release here contains exactly three files: DLSS5-Feeder-<version>.zip, AUTOMATIC_INSTALLATION_AVAILABLE.txt and CAREFUL_FAKE_MALICIOUS_FEEDER.txt. Nothing else on the internet is a release of this project, whatever it is named.

Several third-party installers repackage this project (and ReShade, and the neural consumers) into their own downloads. That is fine and often convenient — but if Windows Defender flags a file under someone else's download folder, that file is theirs, not ours, and only they can get it cleared. Trojan:Win32/Kepavll!rfn on a shaders_*.zip under AppData\Local\<tool>\ is the common shape of this report; the path names the tool that downloaded it.

For a warning on a file that really came from this repository:

• The release zips are scanned on VirusTotal. DLSS5-Feeder-1.16.0-beta.2.zip, for instance: https://www.virustotal.com/gui/file/b6c2a5a5e69812a91b10edb1fc84617caef4becf163b7f87960af1a802f25e0d. Look the SHA-256 printed in the release notes up there yourself; the report is for that exact file, so a copy from anywhere else will not match it.

• Check it against the SHA-256 published on the release you downloaded it from (Get-FileHash <file> in PowerShell). A hash that does not match means you did not get it from here.

• If it matches and Defender still objects, it is a false positive, and the useful thing to do is submit it: https://www.microsoft.com/en-us/wdsi/filesubmission. That fixes it for everyone rather than for one machine.

• One known true-but-harmless case: Deep Fried Chicken hooks NVIDIA's NGX runtime with Detours, which heuristics dislike. The automated installer tries the plain install first and only asks about an exclusion if Defender removes it.

This project asks for no exclusion you have not been shown the reason for, and never disables your antivirus.

• Before you install: four things
• Status
• Install: the automated way
• Install for a 64-bit game
  • Deep Fried Chicken: first run
  • Alternative: the RenoDX add-on
  • Alternative: OptiScaler DLSS-NR
• Install for a 32-bit game
• Install for a DirectX 10 game
• Install for a DirectX 9 game
• Install for a Vulkan game
  • 32-bit Vulkan (DXVK)
  • 64-bit helper mode
• Install for an OpenGL game
• Motion vectors: choosing a provider
• How it works
  • The 32-bit path
  • The DirectX 10 path
  • The DirectX 9 path
  • The Vulkan path
  • The OpenGL path
• Requirements
• Configuration
• Logs and troubleshooting
• Building
• Limitations and roadmap
• Credits
• License
• AI declaration — what was written by AI, and what wasn't

Proven working in seven games covering every supported path:

In each, the DLSS 5 add-on reports feature 18 created … inline feature 18 evaluation succeeded, driven entirely by ReShade depth + estimated motion vectors.

It is not game-specific: any D3D11, D3D12, Vulkan or OpenGL game with a working ReShade depth buffer and a motion vector provider should work — 64-bit directly, 32-bit via a bundled 64-bit helper process, D3D9 via a wrapper.

Detroit: Become Human (Demo), 64-bit Vulkan — almost certainly the Smooth Motion case above. The picture holds stale frames while the log reports every frame delivered, which is exactly the signature described in the Smooth Motion warning. Enabling Smooth Motion in DOOM 2016 reproduces it in a game that otherwise works, and the feeder cannot detect Smooth Motion on Vulkan, so its silent log never ruled it out here. If you hit this: check "Smooth Motion - Debug Bars" (0xB01B8B02), and if the bars appear, turn Smooth Motion off for Vulkan. Eight further tests (DLSS/NGX, renodx NR, HDR and format detection, cross-API memory coherence, queue-family ownership) all came back clean — full investigation in docs/PLAN-DETROIT.md.

32-bit Vulkan (DXVK) is implemented and user-confirmed — see the World of Warcraft 3.3.5a row above (issue #15). The transport is the same src/feed_vk.h the 64-bit Vulkan path uses, compiled x86, with the host creating the shared textures the way the OpenGL path already does; the cross-bitness half is proven end-to-end on this hardware by spike\spike-vkhost64.exe + spike\spike-vkclient32.exe. Treat it as untested in a real game until a row appears above. See docs/PLAN-VULKAN32.md.

The OpenGL path is verified 32-bit-first, which is the harder of its two halves: Worms Ultimate Mayhem runs the full cross-process route — the host creates the shared textures (GL memory objects are import-only), the game imports them raw and answers on a shared D3D12 fence. The 64-bit in-process OpenGL path shares that same src/feed_gl.h transport, is proven by spike\spike-gl64.exe, and is user-confirmed in MX Bikes (#5). See The OpenGL path and docs/PLAN-OPENGL.md.

This is beta software. Expect the temporal quality of estimated motion vectors (some ghosting in fast motion, softness on thin moving geometry), and the HUD is processed along with the scene.

0.6.1: read this before installing

The motion-vector provider is now chosen with a preprocessor definition (DLSS5_MV_PROVIDER) instead of being whichever shader happens to write texMotionVectors. Five providers are supported and the recommended one is LumeniteFX Kernel — see Motion vectors: choosing a provider.

If you installed a release up to 0.5.2 and followed the old instructions, your feed has most likely been running on zero motion vectors. ReshadeMotionEstimation (DRME), which those releases recommended, does not compile on ReShade 6.8 (error X3020: cannot sample from texture that is also used as render target). ReShade still lists it as an enabled technique, so nothing looked wrong — but it wrote nothing. This release detects that and says so in the overlay and the log.

Install-DLSS5Feeder.ps1 does the whole install from one command:

• Download the script.
• Drop the .ps1 file next to your game's .exe.
• Right-click in the folder ▸ Open in Terminal.
• Paste this and press Enter:

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

• Confirm the executable it proposes.

Or point it at the exe from anywhere:

powershell -ExecutionPolicy Bypass -File .\Install-DLSS5Feeder.ps1 "C:\path\to\game.exe"

It reads the architecture and render API out of the executable, then downloads (once, into a cache) and installs everything the manual sections below describe: ReShade 6.8+ with add-on support (a local DLL, or the machine-wide Vulkan layer plus the ReShadeApps.ini entry), the feeder from the latest release (addon32 + host64\ for a 32-bit game), the ReShade framework headers, LumeniteFX, Deep Fried Chicken, both NVIDIA runtimes, dgVoodoo2 for Direct3D 8/9 games (watermark off; -DgVoodooWatermark keeps it), and ReShade.ini / ReShadePreset.ini with the provider selected and both techniques enabled in the right order. Existing files are merged into and backed up, not replaced. It ends by running a read-only verification pass and prints the result — every line is [ OK ], [WARN] or [FAIL], with the fix for each failure.

Things to know:

• Windows Defender flags Deep Fried Chicken (it hooks NVIDIA's NGX runtime with Detours, which heuristics dislike). The script tries the plain install first; only if Defender removes the file does it explain, ask, and add an exclusion for the game folder through a UAC prompt. Nothing is excluded without your yes.
• Vulkan games need one UAC prompt to register ReShade's layer and add the exe to ReShadeApps.ini. -NoElevate turns every such step into printed instructions instead.
• It asks which neural consumer you want before downloading anything: Krish's RenoDX DLSS 5 add-on (the default), OptiScaler DLSS-NR, or Deep Fried Chicken. The first two are downloaded for you; Chicken has no public download, so the script asks you to fetch it. Only one is ever installed, and if another is already in the folder it offers to disable it. For OptiScaler it also asks which fork: wilsjo2's (the default) or Dagherbou's. -Consumer RenoDX|OptiScaler|DFC and -OptiScalerFork wilsjo2|Dagherbou answer both in advance for an unattended run.
• For a 64-bit game it asks whether to use the 64-bit helper mode, which runs NGX in host64\ as for a 32-bit game. Answer No (the default, and what Enter does) unless the game already failed with "NGX would not set DLSS up inside this game's process". -HelperMode Yes|No answers in advance; -Yes alone means No.
• Pieces you already have go in a folder passed with -LocalFiles, or one at a time with -DfcZip, -RenoDxAddon, -OptiScalerZip, -DlssNrDll, -DlssDll, -FeederZip, -ReShadeSetup, -LumeniteZip, -DgVoodooZip.
• -Api D3D|Vulkan|OpenGL|D3D9|D3D8 overrides the detection (some engines, Max Payne 3 among them, can run on either Direct3D 9 or 11; the script assumes 11 and says so).
• The Discord download links inside the script expire; when one does, the script says so and tells you which parameter takes a fresh link or file.

1. Run ReShade's installer (https://reshade.me), point it at your game's .exe, choose Direct3D 10/11/12, and tick "Enable loading of add-ons".
2. Download dlss5-feed.addon64 and DLSS5_Feed.fx from the latest release. Put dlss5-feed.addon64 next to the game .exe, and DLSS5_Feed.fx into reshade-shaders\Shaders\. The shader includes the standard ReShade.fxh header. ReShade normally installs it with its standard shader package; if ReShade.log says it cannot open that file, copy ReShade.fxh from the official reshade-shaders repository into the same Shaders\ folder.
3. Download LumeniteFX (Code ▸ Download ZIP). Copy its Shaders\ folder (the lumenite_*.fx files and include\) into reshade-shaders\Shaders\, and Textures\lumenite_bluenoise256.png into reshade-shaders\Textures\. (Other providers: see Motion vectors: choosing a provider.)
4. Get the neural consumer — Deep Fried Chicken (see Before you install) — and put its three files next to the game .exe: deep-fried-chicken.addon64, deep-fried-chicken-nvngx.dll and deep-fried-chicken.cfg. Add nvngx_dlssnr.dll (from the RenoDX Discord — Chicken does not bundle it) and a nvngx_dlss.dll (from any DLSS game, or DLSS Swapper) in the same folder. (Using the RenoDX add-on instead? See Alternative: the RenoDX add-on.)
5. Press Home for the ReShade overlay, select DLSS5_Feed.fx, set DLSS5_MV_PROVIDER = 3 in its Preprocessor definitions, and reload effects.
6. In-game: enable "LUMENITE: Kernel 2.0", then DLSS 5 Feed below it, then turn on neural rendering in the consumer's own panel — the Deep Fried Chicken tab, or the DLSS 5 Neural Rendering panel if you took the RenoDX route. Turn the game's MSAA/SSAA off.

Check dlss5-feed.log (next to the game .exe) for feature ready … DLAA, frame N delivered, and DLSS5_MV_PROVIDER=3 (LumeniteFX Kernel) -> Lumenite_Kernel (enabled). The overlay's Motion vectors section shows the same, in red if the shader and the enabled provider disagree. dlss5-feed.cfg is created automatically with working defaults.

Do I need the DLSS 5 DX11 bridge? No. DLSS5-Feeder does the bridge's job for games that have no DLSS. The bridge — https://github.com/NIGos/dlss5-dx11-bridge/releases — is only for DX11 games that already have their own DLSS; don't run both for the same game.

Deep Fried Chicken (by Alexander) is the add-on that does the neural rendering on top of what this project feeds it. There is nothing to set up on our side — the two recognise each other automatically.

Four things to know:

1. Don't edit its settings file. The deep-fried-chicken.cfg it ships with is already the right starting point: on, one pass, extras off.
2. It will ask you to restart once more. On its first run it adds itself to ReShade's startup list and wants one more restart. That is normal, and only happens once.
3. Start with one pass. It can do up to 30. That is a stress test, not a starting point.
4. Nothing else neural in the folder. No RenoDX add-on, no Alex's Toolkit, no DX11 bridge. With any of those present, Chicken quietly does nothing at all.

For a 32-bit game, its three files go in the host64\ folder, next to dlss5-feed-host64.exe — not beside the game itself. A 32-bit game cannot load them.

Is it working? The overlay's Status section and dlss5-feed.log both show Chicken's version and its state. ARMED is what you want. DISARMED, CONFLICT or FAILED mean it is not running its passes, and the log says which and why.

Reporting a problem? Send dlss5-feed.log, deep-fried-chicken.log and ReShade.log from the same run (plus host64\dlss5-feed-host.log for a 32-bit game), and the output of the installer's verification output.

To use Krish's renodx-dlss5.addon64 (the #DLSS5 build) instead of Deep Fried Chicken — Before you install has the download and the list of build generations:

• In step 4, put renodx-dlss5.addon64 next to the game .exe in place of the three Chicken files. nvngx_dlssnr.dll and nvngx_dlss.dll are needed either way. For a 32-bit game it goes into host64\, again for the same reason Chicken does.
• Its neural rendering is turned on in ReShade's DLSS 5 Neural Rendering panel, and on 32-bit games mirrored onto our own overlay page — see Configuration.
• The feeder writes EnableHooks=2, NeuralUplift=1 and NREnableUpscaling=0 when they are unset, and unbinds the helper's global hotkeys. Both are RenoDX-specific and do nothing on the Chicken path.
• warmup_rebuild matters here: older builds latch STANDBY on their first create, and the warm-up re-create is what clears it.

Two OptiScaler forks have the DLSS 5 neural-rendering model built in, as a pass on their upscaler's output, and both are supported here: OptiScaler-DLSSNR-PreSR-Multipass (wilsjo2; actively maintained, pre-SR / multipass / finished-picture options, no forwarder DLL since v0.8.1) and OptiScaler_DLSSNR (Dagherbou; the original, ships its nvngx.dll_dlssnr.dll forwarder). Neither is a hook over NVIDIA's NGX like the two add-ons above: it is the NGX implementation the process talks to. Installed the normal OptiScaler way, its loader hook hands its own module to the NGX SDK inside this feeder, so the feeder's DLAA request is upscaled by OptiScaler (dlss by default, so nothing changes there) and then given the neural pass, in place. The feeder detects it, tells the two generations apart (it logs direct-runtime build for wilsjo2 v0.8.1+ and forwarder build for Dagherbou), checks that its calls really went there, and skips the warm-up re-create the other two need. On the no-game rig the pass costs the same whether OptiScaler runs DLSS, XeSS or FSR underneath. The installer does all of the below with -Consumer OptiScaler and asks which fork (-OptiScalerFork wilsjo2|Dagherbou to skip the question; -Yes takes wilsjo2).

• Get the release zip from the fork's releases page (OptiScaler-NR-v<version>.zip for wilsjo2, not the -rtx40-mfg variant; OptiScaler-DLSSNR-<version>.zip for Dagherbou; about 130 MB either way; nvngx_dlssnr.dll is not in it — you supply that as always). Extract it into the folder where the DLSS work happens: next to the game .exe for a 64-bit game, into host64\ for a 32-bit one. wilsjo2's docs\, images\ and tests\ folders can stay out.
• Rename OptiScaler.dll to winmm.dll (or version.dll). ReShade keeps dxgi.dll. The name must be one the process imports at start: dlss5-feed-host64.exe imports both of those, and most games import winmm.dll. Do not run OptiScaler's own setup_windows.bat — it wants dxgi.dll.
• In OptiScaler.ini, under [DlssNr] set Enabled=true (both ship off); under [Upscalers] set Dx12Upscaler=dlss. Dagherbou's build only: ScanExposure=false too (wilsjo2's dropped the key). Leave [DlssNr] FinishedPicture=false (wilsjo2): true moves the pass from the feeder's evaluate to the game's Present, and on the 32-bit path that is the helper's own window, which the game never sees. Leave [ProcessFilter] TargetProcessName=auto: an ini copied from a game folder carries that game's name and puts OptiScaler into pass-through (no hooks, no menu).
• Switching from Dagherbou's build to wilsjo2's: delete the leftover nvngx.dll_dlssnr.dll (nothing loads it any more; the fork's own install notes say so). The installer renames it.
• Remove Deep Fried Chicken's three files and any renodx-dlss5*.addon64 from that folder. OptiScaler captures every nvngx load in the process — Chicken's own bridge DLL ends in nvngx.dll — so a second consumer either talks to OptiScaler or runs a second neural pass.
• OptiScaler's menu opens with Insert; its neural-rendering section holds the pass controls. For a 32-bit game the menu is in the helper: press Show the DLSS 5 panel in-game and then Insert, or run with host_window=1.
• Model resolution below 100% flickers on wilsjo2's builds up to v0.8.91 and keeps "settling" for a few frames after the camera stops, at every scale below 100%. The cause is in the fork's reduced path: the model was given a colour at the working size and depth / motion vectors at the frame's size. A fixed build is on this project's fork, release v0.8.92 (v0.8.91 plus that one change, offered upstream as a pull request): same zip layout, same install. [DlssNr] MatchGuides=false in its OptiScaler.ini brings the old behaviour back for a comparison. The feeder's own Work resolution (work_resolution) is the other way to run the model below native, and was never affected: it shrinks the whole frame and makes the guides at that size.

dlss5-feed.log (or host64\dlss5-feed-host.log) then says NGX calls are routed through OptiScaler DLSS-NR (winmm.dll) and, after the first frames, neural model (feature 18) loaded (Dagherbou's build has the model up by the second evaluate; wilsjo2's creates it on its own schedule, so the feeder keeps looking for up to 120 evaluates before it calls it absent). If it says the DRIVER answered the probe, OptiScaler is present but its redirect did not take (its [Inputs] EnableDlssInputs and [Hooks] HookOriginalNvngxOnly keys are the two that can do that, and so can a TargetProcessName that names another exe). If the model is NOT loaded, OptiScaler.log beside the DLL names the missing piece. A stock OptiScaler build is reported as such: it upscales and never runs a neural pass. Verify-DLSS5Feeder.ps1 checks the whole layout, knows both generations, and reads both logs.

NGX only exists as 64-bit code, so a 32-bit game gets a 64-bit helper process that does the DLSS work. Two folders to fill:

Next to the game .exe (32-bit side)

• ReShade, installed with its installer (it detects 32-bit itself; tick "Enable loading of add-ons").
• dlss5-feed.addon32 from the latest release.
• DLSS5_Feed.fx into reshade-shaders\Shaders\, plus a motion-vector provider (steps 3 and 5 of the 64-bit instructions).

In a new host64\ folder next to the game .exe (64-bit side, nothing here can go beside the game)

• dlss5-feed-host64.exe from the same release.
• A 64-bit ReShade dxgi.dll (run the ReShade installer once against any 64-bit game and take it from there).
• The neural consumer: Deep Fried Chicken's three files (deep-fried-chicken.addon64, deep-fried-chicken-nvngx.dll, deep-fried-chicken.cfg), or renodx-dlss5.addon64 (the RenoDX route), or the OptiScaler DLSS-NR set with OptiScaler.dll renamed winmm.dll (that route).
• nvngx_dlssnr.dll and nvngx_dlss.dll.

Then, in-game

• Turn it on as for a 64-bit game. The first fed frame starts the helper by itself.
• Day-to-day settings: ReShade overlay → Add-ons → DLSS 5 Feed (see Configuration).
• The neural consumer's own panel lives in the helper, not in the game's ReShade. No alt-tab needed: press Show the DLSS 5 panel in-game on that page, or bind a key with Set key, and it is drawn at the top right of the game window with your clicks forwarded to it. Changes apply live.
  • That button uses the desktop compositor: windowed or borderless games only.
  • Show as texture draws it through the game's own ReShade instead and also works in exclusive fullscreen; it appears once the feed has built.
  • While the panel is up the mouse and keyboard belong to it. Escape away from it hides it, Alt+F4 hides it and closes the game, and the X in its corner always closes it. Panel size scales it, and Panel corner moves it to any of the four corners of the game window.
  • Toggle ReShade in host flips ReShade's overlay inside the helper window, which is what the panel casts. The helper opens it by itself at startup; use this to get it back after you close it. The panel is the readout: the helper's placeholder banner shows when the overlay is closed, the tuning panel when it is open. One press flips it; press again if it went the wrong way.
• host_window=1 in dlss5-feed.cfg gives the helper a visible window of its own instead (Home opens the panel there).
• Host window width / height on the overlay resize the helper's window for real -- its window, its swapchain and the panel texture cast into the game, so ReShade's own tab column gets more room rather than the same pixels drawn bigger. From 0.14.0-beta.4 this applies immediately, with no host restart, and you can equally just drag the helper window's border. The values are saved as WindowWidth / WindowHeight under [DLSS5Host] in host64\ReShade.ini (a different file from dlss5-feed.cfg, because it is the helper's own ReShade that reads them at startup).

The helper's own window, with host_window=1:

Direct3D 10 games need nothing extra installed -- no translation layer, unlike the DirectX 9 path. Install exactly as for any other game of the same bitness (64-bit, 32-bit): ReShade goes in as dxgi.dll, which is what its own installer picks for "DirectX 10/11/12".

Three things are worth knowing before you start.

Direct3D 10 support lives in the 32-bit add-on -- dlss5-feed.addon32 plus the host64\ folder -- because that is where the Direct3D 10 games are. The 64-bit add-on has no D3D10 backend. For a 64-bit D3D10 game (Crysis's Bin64\Crysis.exe, #134), use the 64-bit helper mode: it is the 32-bit add-on's code built x64, D3D10 backend included. Nobody has run a D3D10 game through it yet.

Choose a motion-vector provider that does not need compute. ReShade compiles effects at shader model 4 on Direct3D 10, so a provider written around compute shaders will not build. LumeniteFX is the safe first choice -- it checks __RENDERER__ and has a non-compute path -- and the older pixel-shader providers (qUINT, dh_uber_motion) predate compute entirely. See Motion vectors: choosing a provider.

Only DLAA is on offer, and that is a property of the API rather than of this add-on. A D3D10 game publishes no NGX parameter block and no engine jitter, so what gets reconstructed is the finished frame plus whatever the motion-vector provider can infer from it. The DirectX 9 and 32-bit Vulkan paths sit under exactly the same ceiling.

Two smaller notes. The in-game panel's Show as texture button is unavailable here -- the panel would have to cross into the game's ReShade as a Direct3D 11 texture -- so use the compositor button next to it, or host_window=1.

And the frame costs two GPU drains, because Direct3D 10 has no fence. The copies themselves are cheap (spike\spike-d3d10client32.exe measures hundredths of a millisecond at 1080p on an idle GPU), but that is a floor rather than a forecast: a drain waits for everything the device has outstanding, which in a real game includes the frame the game has just queued. The honest cost is lost CPU/GPU pipelining, and the only place to measure it is in the game, with the add-on's own GPU-cost figures on the overlay.

D3D9 games need a translation layer first — dgVoodoo2 turns D3D9 into D3D11, and everything after that is a normal 32-bit install.

A 64-bit D3D9 game has a second route, and it is the one to try if dgVoodoo2 crashes the game: put DXVK (x64\d3d9.dll, with dxvk.allowFse = False in dxvk.conf) in front of it instead, install ReShade as a Vulkan layer, and follow the 64-bit Vulkan steps — the existing Vulkan transport handles it with no changes. Confirmed on Darksiders II Deathinitive Edition, where dgVoodoo2 crashed at startup in every configuration (#64). Windows only: it works because the Windows Vulkan loader reads ReShade's layer from the registry, which Proton's winevulkan does not do.

Not sure if you need this? Launch the game with ReShade installed and check ReShade.log: IDirect3DDevice9 means yes; D3D11CreateDevice means the game already runs on D3D11 — skip to Install for a 32-bit game.

1. Download dgVoodoo2 from http://dege.freeweb.hu/dgVoodoo2/ and unzip it.

2. Copy MS\x86\D3D9.dll, dgVoodoo.conf and dgVoodooCpl.exe next to the game's .exe (often not the game's root folder — Fable Anniversary's is Binaries\Win32\).

3. Run dgVoodooCpl.exe from that folder (or edit dgVoodoo.conf directly). In [DirectX]:

   Setting	Value	Why
   DisableAndPassThru	false	Ships as true, which disables dgVoodoo entirely — the #1 reason "dgVoodoo doesn't seem to do anything".
   VRAM	1GB	The default (256 MB) causes "ran out of video memory" crashes regardless of your real GPU. Don't use 2GB — some old engines mishandle it.
   VideoCard	internal3D	dgVoodoo's own virtual card; the most capable option.
   dgVoodooWatermark	true	Temporary — confirms dgVoodoo is actually running.

   In [General]: OutputAPI = d3d11_fl11_0 (or higher).

4. Launch the game — the dgVoodoo watermark must appear, or nothing else will work.

5. Follow Install for a 32-bit game (or the 64-bit steps for a 64-bit D3D9 game). Install ReShade as dxgi.dll, never d3d9.dll — dgVoodoo owns that name.

6. Turn the watermark off once everything works.

Same pieces as a 64-bit game — with two differences.

1. Run ReShade's installer, point it at your game's .exe, choose Vulkan, and tick "Enable loading of add-ons".
2. Add AddonPath=.\ under [ADDON] in the game's ReShade.ini (next to the exe).
3. Everything else is identical to the 64-bit instructions.

The add-on tick matters more on Vulkan than anywhere else. The Vulkan layer is machine-wide (C:\ProgramData\ReShade\ReShade64.dll), so it is shared by every Vulkan game on the PC: one plain, no-add-on install done for some other game years ago is reused here, and nothing complains — ReShade loads, the overlay appears, and dlss5-feed.addon64 is simply never looked for. The two builds carry the same version number and the same product name, so they are indistinguishable by eye (issue #53). Verify-DLSS5Feeder.ps1 now checks this directly and the installer replaces a plain layer automatically.

Most Vulkan games don't enable the extensions this needs — the add-on adds them automatically, so there's nothing else to configure. See The Vulkan path for the mechanism.

If dlss5-feed.log says the interop entry points are missing, launch through the bundled fallback layer instead:

layer\run-with-feed-layer.bat "E:\path\to\game.exe"

See layer/README.md — it does the same job from outside the process.

Almost every 32-bit game that reaches Vulkan does it through DXVK. Two differences:

1. Install ReShade as a Vulkan layer, not as a local dxgi.dll or d3d9.dll — DXVK owns those names in the game folder.
2. Add the host64\ folder from Install for a 32-bit game, and install both halves from the same release.

DLSS runs at the game's native resolution here, so the Work resolution slider is fixed at 100%.

A working configuration from issue #15 (World of Warcraft 3.3.5a, DXVK 3.0.2, ReShade 6.8 x86 as a global Vulkan layer, Guild Wars Reforged likewise): the default dxvk.conf is fine; the only setting that mattered was dxvk.allowFse = False. Expect roughly half the frame rate — DLAA at native size plus the 32→64-bit hop — and, from 0.11.0-beta.2, no more plateaus at exactly 30 fps (the helper's own Present used to block on the compositor while the game waited behind it; it no longer waits). If frame times still step between two fixed values, run once with mode=1 (transport only, no DLSS) and once with async_home=0 and post both dlss5-feed.logs; the present probe line now also counts presents against frames fed here, which tells an external frame pacer apart from a slow helper.

If dlss5-feed.log says the interop entry points are missing, use the 32-bit fallback layer:

layer\x86\run-with-feed-layer32.bat "E:\path\to\game.exe"

Some games create a first Direct3D 9 object, drop it and load d3d9.dll again (Fallout: New Vegas under Mod Organizer 2 and NVSE, #135). Under DXVK that unloads vulkan-1.dll and ReShade's Vulkan layer and loads them again, and ReShade never unloads its add-ons on the way out. Up to 1.17.0 the add-on stayed behind: ReShade.log said "No add-on was registered" and no DLSS 5 panel appeared. Now the add-on takes its Vulkan hooks off the old vulkan-1.dll and releases itself, and the new ReShade loads it again. dlss5-feed.log shows "releasing the add-on ReShade left loaded" followed by a second "attached".

Some 64-bit games cannot run NGX inside their own process. dlss5-feed.log then shows NVSDK_NGX_D3D12_Init -> 0x00000001 (Success) followed by SuperSampling.Available=0, and the add-on stops with "NGX would not set DLSS up inside this game's process (SuperSampling.FeatureInitResult 0xBAD00002 PlatformError)", while host64\dlss5-feed-host64.exe --test on the same PC succeeds. Confirmed so far: Bloodborne on shadPS4, where NGX's own log says NvAPI_D3D12_CreateCuModule failed.

When the in-process session fails like this, the add-on runs NGX's init once more with NGX's own log routed into dlss5-feed.log, between two ===== NGX's own log lines, then shuts it down again. The helper always writes NGX's log into host64\dlss5-feed-host.log. Both leave out NGX's config dumps and its per-preset lines; set the environment variable DLSS5_FEED_NGX_VERBOSE=1 to keep everything.

For these games, dlss5-feed-helper.addon64 runs the 32-bit path's in-game half as 64-bit code. The game hands its frames to the helper process and NGX runs there, exactly as for a 32-bit game.

Next to the game .exe

• ReShade with add-on support, as in Install for a Vulkan game.
• dlss5-feed-helper.addon64 instead of dlss5-feed.addon64. If both are there, dlss5-feed.addon64 sees the helper, says so in the log and stands down, so the helper mode runs; remove one anyway.
• DLSS5_Feed.fx and a motion-vector provider, as for any game.
• No neural consumer here: it goes in host64\.

In host64\: the same files as in Install for a 32-bit game: dlss5-feed-host64.exe, a 64-bit ReShade dxgi.dll, the neural consumer, nvngx_dlssnr.dll and nvngx_dlss.dll.

From there it behaves like the 32-bit path: the first fed frame starts the helper, and the panel and settings are the ones described there. The limits of 32-bit Vulkan apply too: DLAA at native size, Work resolution fixed at 100%.

• Tested on Vulkan only (shadPS4). The D3D10, D3D11 and OpenGL paths of the same code are compiled in, but nobody has run them at 64-bit yet. D3D10 makes it the only route for a 64-bit Direct3D 10 game. D3D11 may also help a game where NGX fails in the game's process but works in host64 (#47); that is untested too.
• ReShade's add-on list shows it as DLSS 5 Feed (64-bit helper). The log still calls it dlss5-feed32 / [feed32]: it is the same code, built x64.
• Verify-DLSS5Feeder.ps1 recognises the layout by dlss5-feed-helper.addon64 next to a 64-bit exe and then checks host64\ and the neural consumer there, as for a 32-bit game.

The simplest of the four — nothing extra to configure.

1. Run ReShade's installer, point it at your game's .exe, and choose OpenGL.
2. Everything else is identical to the 64-bit instructions.

For a 32-bit OpenGL game, follow Install for a 32-bit game — install both halves from the same release.

Hybrid laptops: force the game onto the NVIDIA GPU (Windows Settings ▸ Display ▸ Graphics). Otherwise the feed disables itself — DLSS needs that GPU.

DLSS5-Feeder does not estimate motion itself — it reads the output of a motion-vector shader you install. Which one it reads is fixed at compile time by the DLSS5_MV_PROVIDER preprocessor definition on DLSS5_Feed.fx (ReShade overlay → select DLSS5_Feed.fx → Preprocessor definitions → reload effects):

Rules that apply to all of them:

• The provider's technique must be enabled and above DLSS 5 Feed in the technique list.
• Only one provider should be enabled. The add-on warns (overlay + log) when the shader is compiled for one provider while a different one is enabled — the classic silent failure.
• Nothing of any provider is bundled or #included here: the shader declares the provider's output texture identically to the provider itself, so ReShade binds the same resource. Only the selected provider's texture is allocated.

ReshadeMotionEstimation (DRME) does not compile on ReShade 6.8 (error X3020: 'V__texCur0': cannot sample from texture that is also used as render target). It still appears as a technique and can be "enabled", but it writes nothing, so DLSS runs with no motion vectors at all. Releases up to 0.5.2 recommended it. This release reads the compiler error out of ReShade.log and reports it in the overlay and dlss5-feed.log.

The add-on checks both configuration and the actual textures handed to DLSS:

• The overlay's Motion vectors section states the mode, the provider found, and its state (enabled / DISABLED / FAILED TO COMPILE / not installed), in red when something is wrong.
• A low-frequency guide probe reads back the vectors actually handed to DLSS every 600 frames and logs their mean/max magnitude and non-zero share: MV probe … N% non-zero. While you move, that must not be 0%. The same deferred readback samples four distributed depth blocks and reports min/max/mean/variance/finite share. It warns when sampled depth is flat without disabling the feed. Both readbacks analyse an older, completed copy, so they do not introduce a per-frame GPU stall.

Every provider here is optical flow: it answers a lighting change — a flickering light, a flame — with a confident vector pointing at whatever happened to match, and DLSS then warps history in from there. DLSS5_Feed.fx now reprojects each vector into the previous frame and checks it: depth (disocclusion), vector consistency, and a static-hypothesis test asking whether "did not move" explains the pixel better, on illumination-normalised structure. Vectors that fail are zeroed, and the pixel is flagged in a DLSS5_Mask texture the add-on passes to DLSS as its bias-current-colour mask — DLSS's own mechanism for "don't trust history for this pixel" (all three transports; the 32-bit add-on does not pass it yet). The defaults are the tuned ones.

The static test is the one with a memory. Left to decide afresh every frame, it can win on one and lose the next over a low-contrast surface under a slow pan, so the vector alternates between the provider's and zero and DLSS alternately reprojects and does not — a flicker that comes and goes and that no consumer downstream can smooth away. Static test: require two frames in a row (STATIC_HYSTERESIS, on by default) only zeroes a vector where the test won twice; on the first win it keeps the vector and masks the pixel instead. Turn it off to compare against the old behaviour. Debug view Validation tests over the image marks in yellow what was actually zeroed, and in orange what the hysteresis held back, so a flip is visible rather than inferred.

• DLSS5_Feed.fx (companion effect) converts the selected provider's motion vectors (delta-UV, prev_uv = uv + mv) into DLSS5_MV (RG16F, pixels), copies the raw hardware depth with ReShade's orientation fixes into DLSS5_Depth (R32F), and flags every vector it does not trust in DLSS5_Mask (R8). MV, mask and raw depth are emitted by one MRT guide pass, avoiding a second full-screen depth pass while leaving the depth values sent to DLSS unchanged.
• dlss5-feed.addon64 registers with the ReShade add-on API. After the DLSS5_Feed technique renders, it takes the backbuffer + those textures and runs NGX_D3D12_EVALUATE_DLSS in DLAA mode (render size = output size, no jitter). The neural consumer (deep-fried-chicken.addon64, or renodx-dlss5.addon64) detours that D3D12 evaluate and inserts its neural pass — it cannot tell the contract is synthetic.
• On a 64-bit D3D11 game the optional Work resolution slider can run the private DLAA + Neural Rendering contract at 50–100% of each backbuffer axis. Color is resampled linearly; depth, motion vectors and the trust mask use point sampling; motion-vector magnitudes are corrected for the selected work extent. The result is expanded back over the native-size backbuffer, bilinearly or (work_upscale=1) through AMD FSR 1 EASU + RCAS. At 100% this reduces to the original copy path.
• On a D3D12 game there is no transport at all: NGX runs on the game's own device and queue, motion vectors and depth are consumed zero-copy straight from the effect textures, and the feature survives alt-tabs and effect reloads untouched (only a real resolution change rebuilds).
• NGX calls are wrapped in SEH, a command list the add-on crashed in is discarded rather than submitted, and NGX is reinitialized after repeated failures — a faulting closed-source add-on disables the feed instead of taking the game down. A failed or crashed feature create is retried up to twice, each attempt spaced a full hook-arming grace apart (with an NGX re-initialisation before the second), instead of latching the feed off on the spot. On the D3D11 bridge the shared textures and the live feature also survive alt-tabs and effect reloads now: a runtime recreation re-creates only the feature, and keeps the old one if the new create fails.

NGX and the DLSS 5 add-on only exist as x64 code, and a 32-bit process cannot load an x64 DLL — so dlss5-feed.addon32 does none of the NGX work itself. Instead:

• It creates the four Color/Output/Depth/MV textures as cross-process shared D3D11 resources (D3D11_RESOURCE_MISC_SHARED_NTHANDLE) on the game's own device, plus two shared fences. If the game's device refuses (a feature-level 10.x device cannot bind the UAV the DLSS output needs — NFS Most Wanted 2012, issue #33), it switches to the route the GL and Vulkan clients use: the host creates the set on D3D12 and hands the handles in, keeps the output's UAV on its own side and copies the result into a plain shared texture. The log says so (the host will create the shared set instead).
• It spawns dlss5-feed-host64.exe and hands it the texture/fence handles over a named pipe (DuplicateHandle across the process boundary — the same WDDM sharing the driver already uses, just one hop further).
• The host — a genuine 64-bit process — opens those shared resources on its own D3D12 device, runs the same DLSS DLAA evaluate the 64-bit add-on runs in-process, and signals a fence back. No frame data ever crosses into system memory; every copy stays GPU-to-GPU.
• Because the DLSS 5 add-on is itself a ReShade add-on, the host disguises itself as a game to load it: a window with a minimal D3D12 swap chain lets its own bundled ReShade (host64\dxgi.dll) attach and the add-on arm its hooks, exactly as in a real D3D12 title. The 32-bit dlss5-feed.cfg add-on writes settings changes made in the game's own overlay straight into that window's ReShade.ini and restarts it to apply them. For live changes it instead casts that window into the game: a DWM live thumbnail of the host window is registered on the game window (no pixel transport, no protocol change), and while the cursor is over it the game's mouse and keys — read through ReShade's add-on API and blocked from the game — are posted to the host window as ordinary WM_* messages, which is where the host's ReShade reads its input.
• Everything that means waiting on the host — spawning it, the handshake, and each build request — happens on a worker thread, and every pipe transfer has a deadline. The render thread hands a build over and returns; the answer is picked up on a later frame. So the expensive part, a host starting up (up to 15 s while it loads ReShade, NGX and the ~165 MB model) and every build after a resolution or work-resolution change, no longer freezes the game at all. A host that hangs rather than dies no longer freezes it either: the transfer times out and the add-on treats it as a lost host. Apply and Restart still pause briefly — up to about four seconds — because the old helper has to be given time to save its ReShade.ini before the replacement can claim the pipe; the reconnect after it is free.
• If the host process dies, the pipe breaks, the add-on notices and disables itself — the game keeps rendering normally.
• Verified end to end with a deliberate split-screen test (mode=1): the host copies only the left half of the frame back, so a visibly half-black screen proves the full round trip — game → shared texture → host → shared fence → game's backbuffer — actually reaches the display, not just the logs.

Direct3D 10 cannot reach the helper on its own, and not for one reason but three. NT-handle sharing is Direct3D 11.1+, so the helper's D3D12 device can never open a texture a D3D10 device made. D3D10 has no fence of any kind, which is how every other client here says a frame is ready. And it has no UAVs, so the Output slot could not be written at all.

So the add-on creates a private D3D11 relay device of its own, inside the game's process, on the game's adapter (matched by LUID). The game's D3D10 device copies colour, depth and motion vectors into legacy shared textures; the relay opens those same textures; and from there this is the 32-bit D3D11 client running unchanged -- the NT-handle shared set, the shared D3D12 fence, the blit chain, the pipe, the helper. The host is never told the game was D3D10. It is a FEED_CLIENT_D3D11 on the same protocol version, and host\dlss5-feed-host64.cpp needed no change at all. The relay is created at feature level 11_0, so the ID3D11Device1 / ID3D11Device5 / ID3D11DeviceContext4 queries the D3D11 client hard-fails on all succeed, and the game's own device is asked for nothing but copies.

Two details are worth recording, because neither is what the design notes predicted.

Keyed mutexes do not work. LEGACY-API-ADAPTER.md says D3D10.1 can synchronise the two devices with an IDXGIKeyedMutex. On real hardware it cannot: every CreateTexture2D carrying D3D10_RESOURCE_MISC_SHARED_KEYEDMUTEX comes back E_INVALIDARG -- every bind flag, every format, with or without MISC_SHARED alongside -- while the same call on a D3D11 device succeeds and plain legacy MISC_SHARED on the same D3D10 device succeeds. Modern drivers simply do not implement that legacy path. Both D3D10 versions therefore take the event-query route that document reserves for D3D10.0, and spike\spike-d3d10client32.exe keeps the check so that a driver which ever grows the capability shows up as a passing line rather than as folklore.

The frame comes home by CopyResource, not by a draw. The relay runs the whole blit chain -- scaling, FSR1 EASU/RCAS -- into a backbuffer-sized shared texture, and the game's device only copies that into its own render target. So the D3D10 side never binds a shader, a viewport or a render target. That matters more here than anywhere else in this project, because D3D10 has no ID3D10DeviceContext: state lives directly on the device, so anything the add-on set, the game would silently inherit.

The price is two pipeline bubbles a frame, one per device, since an event query drains everything that device has outstanding. All three input copies share a single drain rather than paying for one each, and spike\spike-d3d10client32.exe measures the result.

dgVoodoo2 sits in front as D3D9.dll and translates the game's D3D9 calls onto its own D3D11 device. ReShade (installed as dxgi.dll) hooks that D3D11 device rather than the game's D3D9 one, so from DLSS5-Feeder's point of view it is simply a D3D11 game and the 32-bit path applies unchanged. The translation is what makes SM5 motion-vector shaders, shared NT-handle textures and fences available at all — none of which exist on real D3D9.

The DLSS 5 add-on only hooks D3D12 NGX entry points, so even though NGX has a Vulkan API, using it would be pointless — the add-on would never see the call. The evaluate therefore runs on a private D3D12 device exactly as on the D3D11 path, and the frame crosses the API boundary through shared memory rather than being copied out to system RAM:

• The D3D12 side creates the shared textures and two shared fences (D3D12_HEAP_FLAG_SHARED, D3D12_FENCE_FLAG_SHARED) and exports NT handles for them.
• The add-on imports those handles into the game's own VkDevice with raw Vulkan — the D3D12 external types (VK_EXTERNAL_MEMORY_HANDLE_TYPE_D3D12_RESOURCE_BIT, VK_EXTERNAL_SEMAPHORE_HANDLE_TYPE_D3D12_FENCE_BIT, dedicated allocation). A D3D12 fence and a Vulkan timeline semaphore are the same object, so the frame counter crosses unchanged.
• The resulting VkSemaphores are handed back to ReShade as api::fence handles (in ReShade's Vulkan backend they are those objects), so per-frame queue signal/wait stay inside ReShade's own locks. A raw vkQueueSubmit would race the game's and ReShade's submits.
• Per frame: ReShade's barrier() moves the game's own images (its layout tracking stays correct), raw vkCmdCopyImage/vkCmdBlitImage move pixels into and out of our imported images, which sit permanently in VK_IMAGE_LAYOUT_GENERAL.

The interop extensions are fixed at vkCreateDevice, and games rarely enable them (ReShade adds external_memory_win32 and timeline_semaphore itself, but not the semaphore/dedicated-allocation ones). The add-on is already in the process by then — ReShade's Vulkan layer loads add-ons inside its vkCreateInstance hook and fires create_device from there — so on that event it puts an inline hook (MinHook) on vulkan-1.dll's exported vkCreateDevice (src/feed_vk_hook.h). The loader returns that same export for vkGetInstanceProcAddr(instance, "vkCreateDevice"), so every loading style lands in the hook, above ReShade's own layer, which then passes the extended list down. The hook is removed on DLL unload, since ReShade reloads add-ons per Vulkan instance. layer/VkLayer_feed_vk.dll does the same from outside the process, as a fallback.

32-bit Vulkan (DXVK) reuses every one of those pieces — src/feed_vk.h and src/feed_vk_hook.h are compiled into the x86 add-on unchanged — with the D3D12 middle moved out to the helper process, exactly as on the 32-bit D3D11 and OpenGL paths. One thing flips: the host creates the shared textures and duplicates the handles into the game, because D3D12 cannot open memory Vulkan exported. That is the same direction the OpenGL path already uses, so the pipe protocol needed only a new client kind and one extra field — the host owns the Output format there, since only its device can be asked whether this GPU supports a typed UAV store to BGRA8, and DXVK swapchains are almost always BGRA8. Getting that wrong is issue #11's washed-out image again. spike\spike-vkhost64.exe + spike\spike-vkclient32.exe prove the cross-bitness half on its own.

Same shape as the Vulkan path — a private D3D12 device creates the shared textures and fences, and the game's API imports them — but everything the Vulkan path had to fight for comes free here, and one thing it could rely on does not exist.

What comes free. There is no device hook and no layer. Vulkan bakes extensions in at vkCreateDevice, which is why the add-on has to hook that call; OpenGL has no equivalent opt-in — extensions are a property of the driver's context, resolved at runtime through wglGetProcAddress. If GL_EXT_memory_object_win32 and GL_EXT_semaphore_win32 are in the extension string, the transport works. If they are not, the frame is not being rendered on an NVIDIA GPU, so DLSS could not run either way and the feed says so and stops. Add-on discovery is also a non-question: ReShade is the local opengl32.dll, and add-ons load from its own directory.

What does not exist. On Vulkan, ReShade's api::fence is a VkSemaphore, so the imported objects could be handed back and every queue operation kept inside ReShade's locks. On OpenGL an api::fence is documented as "an opaque value" — there is no way to wrap a raw GL semaphore into one. So the whole per-frame GL side is raw (src/feed_gl.h), which is safe here precisely where it was not on Vulkan: OpenGL has no queue object. Every command enters the current context's single in-order stream on the calling thread, and reshade_render_technique fires while ReShade is itself issuing GL commands on that thread and context. Our calls interleave in program order — there is no lock to bypass, and no barriers are needed at all.

Per frame, inside the technique callback:

• glCopyImageSubData copies the motion vectors, depth and trust mask into our imported aliases (exact formats, no state touched); the colour is captured with glBlitFramebuffer, which converts formats and channel order and can read what a raw copy cannot — a renderbuffer or the default framebuffer.
• glSemaphoreParameterui64vEXT(GL_D3D12_FENCE_VALUE_EXT) + glSignalSemaphoreEXT + glFlush hands the frame to D3D12 (a D3D12 fence is a GL "D3D12 fence" semaphore, so the counter crosses unchanged). The flush matters: without it the signal can sit in the client command buffer while D3D12's GPU-side wait starves.
• D3D12 waits, evaluates, and signals back — or CPU-signals on any failure, because glWaitSemaphoreEXT has no timeout and a missing signal would hang the GL stream.
• glWaitSemaphoreEXT stalls the GL stream on the GPU (never the CPU), and a final blit puts the output back over the technique's render target.

A small state guard saves and restores exactly what the blits touch — the two framebuffer bindings, the read/draw buffer selection, scissor and GL_FRAMEBUFFER_SRGB — and nothing else. GL_FRAMEBUFFER_SRGB is forced off for our blits on purpose: the frame we are handed is already encoded, and an sRGB encode on the way home is the OpenGL flavour of the washed-out image of issue #11.

Because GL has no sized BGRA8 internal format and we choose the shared textures' formats, the GL path folds B8G8R8A8/B8G8R8X8 to R8G8B8A8 — harmless, because a blit is component-wise rather than byte-order-preserving. GL names live in the share group of the context current at import, so every frame checks wglGetCurrentContext() and rebuilds the session if the game switched contexts.

The 32-bit OpenGL path uses the very same header, compiled x86, over the existing helper-process protocol — with one change forced by the API: the host creates the shared textures, because GL memory objects are import-only and a GL process cannot export one. Both directions (x86 extension parity, cross-process D3D12→GL import) are proven by spike\spike-gl32.exe.

The easiest way to change any of this is ReShade's overlay → Add-ons tab → DLSS 5 Feed: every setting below is a live control there (checkboxes, sliders, combos), reading from and saving straight to dlss5-feed.cfg. On 32-bit games running the RenoDX add-on, the same page also mirrors that add-on's neural-rendering settings from the host process (neural uplift, NR intensity/style/local structure/local tone/auto mask/UI correction) with an Apply button — since those live in a separate process, Apply writes them into host64\ReShade.ini and restarts the helper (~2 s without DLSS; the game keeps rendering, the feed reconnects automatically). Deep Fried Chicken is not mirrored: its settings live in its own tab in the helper's window and in deep-fried-chicken.cfg.

dlss5-feed.cfg itself is created automatically next to the add-on and re-read while the game runs, if you prefer editing the file directly:

For neural consumers that draw their own UI in the helper window. The cast draws the helper's window into the game, and what reaches the helper from it is ordinary posted WM_* input that says nothing about where it came from -- so a consumer with its own window (OptiScaler's menu is one, not a ReShade page) could not tell whether it was on screen, and had to tail dlss5-feed.log to find out (#118). Since 1.16.0-beta.6 the helper posts a registered window message to its own window on every change:

UINT m = RegisterWindowMessageW(L"DLSS5_FEED_CAST");   // wParam: 1 = the panel is on screen, 0 = it is not
                                                       // lParam: the scale it is drawn at, x1000 (0 when hidden)

Subclass the helper window or run a message hook to see it; nothing outside the helper process is told. dlss5-feed-host.log carries the same state in words, with the destination rectangle in the game's client pixels and the corner it is anchored to.

The mouse wheel in a game that hides its mouse from ReShade, since 1.16.0-beta.7 (Castlevania: Lords of Shadow 2 is the measured one, #118). Such a game keeps the wheel from ReShade as well as the pointer, and the add-on cannot register a raw-input sink of its own: RegisterRawInputDevices is per process, so it would replace the game's registration and break the game's own mouse. The helper has no input to lose, so the sink lives there. While the cursor is over the panel and the add-on is in that real-cursor mode, it posts RegisterWindowMessageW(L"DLSS5_FEED_CAST_WHEEL") to the helper window (wParam 1 = forward the wheel, 0 = stop); the helper then turns raw wheel input into the same WM_MOUSEWHEEL the add-on forwards everywhere else, in whole notches. In every other game the sink is never registered. If something else in the helper process has already registered raw mouse input -- a consumer shipping its own wheel workaround -- the helper leaves that registration alone and says so in dlss5-feed-host.log; it does not take the mouse away from it.

Two more live in a different file -- [DLSS5Host] WindowWidth and WindowHeight in host64\ReShade.ini, because the helper's own ReShade reads them when it starts. They size the helper window, its swapchain and the cast panel texture; WindowHeight=0 means "fill the work area". The overlay's Host window width / height sliders write them and apply them to the running helper at once, so there is normally no reason to edit them by hand.

A third key there is a diagnostic: [DLSS5Host] Dred=1 arms D3D12's Device Removed Extended Data in the helper before it creates its device. If the helper's device is then removed (DEVICE_HUNG in host64\dlss5-feed-host.log), the log names the queue and the operation that never finished, which is what separates the feeder's own work from the neural consumer's pass (#119). It is off by default because on some runtimes arming DRED makes D3D12CreateDevice itself fail; if the helper stops starting with it on, set it back to 0.

In DLSS5_Feed.fx's own UI (settings that only make sense per-shader, not per-session):

• MV_SIGN — if the image doubles or smears while moving, flip a component.
• Validation — Validate motion vectors and its four tests (static hypothesis, luma, depth, consistency) with their thresholds. The defaults are the tuned ones; the usual reason to touch them is diagnosis. Setting Depth tolerance to 0 does not mean "strict" — it rejects effectively every vector, which is stable but motionless.
• Use geometry vectors — experimental, off, not recommended. Fits a camera model from the provider's flow + depth and derives static pixels' vectors from geometry. It removes the flame/flicker warping by construction, but the fit is noisy frame to frame and the HUD, which is not part of the 3D world, gets camera vectors it should not have.
• DLSS 5 Feed – debug view technique — nine views: the vectors/depth being sent (static scene = grey, motion = colour), the provider's confidence map, the validation mask alone and over the image, which test fired, and the three geometry views. The depth view applies a display-only contrast curve so reversed and far-heavy hardware depth is visible; DLSS5_Depth itself stays raw.

Preprocessor definitions on the shader (overlay → Preprocessor definitions → reload effects):

Machines with more than one GPU (32-bit games, cross-process fence import failed). The 64-bit host opens the default adapter; the game may be running on another one. D3D12 fences cannot be shared across adapters, so the import fails and the feed stops with that message. Force the game and dlss5-feed-host64.exe onto the same GPU (Windows Settings > Display > Graphics, or the NVIDIA control panel's per-program preferred GPU); a reporter fixed Racedriver GRID exactly this way (#100).

OpenGL games under Proton / Wine (fence import failed on a single-GPU machine). Not the case above, and not fixable by moving anything to another GPU. Wine advertises GL_EXT_semaphore_win32 and GL_EXT_memory_object_win32, so the extension gate passes, but the Linux GL driver underneath only implements the file-descriptor forms of those extensions and cannot import a D3D12 fence handle; glImportSemaphoreWin32HandleEXT fails and the feed stops (#121). The D3D11, D3D12 and Vulkan transports are unaffected on the same machine. Since 1.16.0-beta.7 the log names this case, prints the GL error, and probes whether a D3D12 texture imports (memory-import probe: ...) -- that one line decides whether a slower CPU-synchronised fallback is possible at all there, so please include it in a report.

Common cases:

• "unknown technique" for DLSS5_Feed / your provider — the shaders are not in reshade-shaders\Shaders\, or the runtime is D3D9 and they cannot compile (see the D3D9 section).

• Image is static-sharp but smears when moving — no vectors are reaching DLSS. The overlay's Motion vectors section says which of the four causes it is: the provider is not installed, it is installed but disabled, it failed to compile (DRME on ReShade 6.8 — use LumeniteFX Kernel instead), or a different provider is enabled than the one DLSS5_MV_PROVIDER selects. The MV probe … 0% non-zero line in dlss5-feed.log confirms it independently.

• Depth probe says sampled depth is flat — open DLSS 5 Feed – debug view, select the depth view, and verify that scene geometry is visible. Then use ReShade's Add-ons → Generic Depth page to select the draw call/clear that contains the scene rather than UI or an already-cleared buffer. The warning is diagnostic only; it does not guess a different buffer or disable DLSS.

• Subnautica: flat or wrong depth — this 4K D3D11 profile was contributor-verified with DLAA + neural rendering. Merge these values into the matching sections of ReShade.ini and keep every unrelated key. In PreprocessorDefinitions, append or replace only the four definitions shown below in the existing comma-separated list; do not discard other definitions:

  [DEPTH]
  DepthCopyAtClearIndex=1
  DepthCopyBeforeClears=2
  DrawStatsHeuristic=0
  FilterFormat=0
  UseAspectRatioHeuristics=3
  
  [GENERAL]
  PreprocessorDefinitions=RESHADE_DEPTH_LINEARIZATION_FAR_PLANE=1000.0,RESHADE_DEPTH_INPUT_IS_UPSIDE_DOWN=1,RESHADE_DEPTH_INPUT_IS_REVERSED=1,RESHADE_DEPTH_INPUT_IS_LOGARITHMIC=0

• Warping / smearing around flames, flickering lights or transparents — optical flow answers a lighting change with a wrong-but-confident vector. Keep validation on (default), try provider 3 (LumeniteFX Kernel) rather than Launchpad, and try preset=5 or 6 in dlss5-feed.cfg (the legacy CNN presets clamp history harder).

• Nothing happens, no dlss5-feed.log — ReShade's architecture does not match the game's (a 64-bit dxgi.dll cannot load into a 32-bit game, and vice versa).

• HDR game: highlights look wrong once the neural model is applied, and correct with it off — an HDR10 swapchain is R10G10B10A2_UNORM carrying PQ BT.2020, which is neither of the two things a neural consumer knows how to handle: it is not linear HDR, and it is not an sRGB tone-mapped picture. OptiScaler DLSS-NR gates its HDR path on the buffer format being a float one, so a 10-bit surface takes its "already tone mapped" branch whatever the IsHDR flag says — which is why setting hdr=1 changes nothing — and then composes PQ code values as if they were sRGB. PQ and sRGB disagree most at the top of the range, so the error lands in the highlights. Its own knobs cannot reach it either: in that branch paper white is pinned to 1.0, and its "guard" is a symmetric clamp on the whole composition, so at 1x it simply switches the effect off.

  The fix is hdr_bridge, on by default when the swapchain is PQ, and covering all four 64-bit transports (D3D11, same-device D3D12, Vulkan, OpenGL). It hands the consumer linear light in FP16, which is what its HDR path is looking for. Confirm it in dlss5-feed.log:

  [feed] swapchain colour space: PQ BT.2020 (HDR10)
  [feed] HDR10 bridge ON (the swapchain is PQ BT.2020 and the backbuffer is 10-bit): …
  [feed] feature ready: … (HDR …) … [HDR10 bridge: the backbuffer is PQ, this is linear light]
  

  and in OptiScaler.log, Init Flag IsHdr: true with colour transform on (linear HDR) rather than off (frame already tone mapped).

  To check the bridge itself is faithful, set mode=1: the transport runs and DLSS does not, so the frame makes the whole PQ → linear → PQ round trip and comes back. It should be indistinguishable from having no add-on loaded. Measured worst-case error over the full 10-bit range is 0.06 of one code value, so anything visible there is a bug worth reporting.

• D3D12CreateDevice failed 0x887E0003 / the session never opens (issues #61, #81) — 0x887E0003 is D3D12_ERROR_INVALID_REDIST, and it is not about your GPU, driver or this add-on. A game whose exe exports D3D12SDKVersion/D3D12SDKPath (Unity titles commonly do) points Direct3D 12 at a game-local D3D12\ folder — the Agility SDK redist — for every device created in that process, ours included. If that folder is empty, or holds a D3D12Core.dll of a version the game did not ask for, every create in the process fails with this code. Everything else looks healthy, which is what makes it confusing: the shaders compile, the consumer arms, and only the device create goes wrong.

  The test that settles it: rename the game's D3D12 folder to D3D12_off and relaunch. If the game still starts and the session opens, that was it. If the game refuses to start without it, the redist is genuinely in use and damaged — verify the game's files through its launcher. Nothing in this project can work around it, because the redirection applies process-wide before our first call. Since 0.14.0-beta.3 the log names the code and reports what that folder contains, and Verify-DLSS5Feeder.ps1 warns about it before you launch.

• "ran out of video memory" with dgVoodoo — raise VRAM in dgVoodoo.conf; the default 256 MB is a virtual limit unrelated to your real GPU.

• Vulkan game: "the Vulkan interop entry points are missing" — the add-on's vkCreateDevice hook did not get to add the KHR external-interop extensions; the lines right above it in dlss5-feed.log say whether the hook was not installed, never reached, or what the driver refused. Fallback: launch via layer\run-with-feed-layer.bat (see layer/README.md); feed-vk-layer.log next to the DLL shows what it added.

• OpenGL game: "the OpenGL interop extensions are missing on the rendering GPU" — the log line above it names the exact extension that was absent and prints GL_RENDERER. If that says anything other than an NVIDIA GPU, the game is rendering on the wrong adapter: force it onto the NVIDIA one (Windows Settings ▸ Display ▸ Graphics) and restart it. There is no fallback for this and there cannot be one — DLSS itself needs that GPU.

• 32-bit game: "the host64\ folder is from a different release" — the add-on and the helper speak a versioned protocol (v2 added the OpenGL client kind, v3 the Vulkan one). Reinstall both halves from the same release rather than mixing them.

• NVIDIA driver 616.64: the helper runs but no neural frame ever arrives (issue #54) — with renodx-dlss5.addon64 v4.6 or v4.7 as the neural consumer, every DLSS evaluate faults inside the driver's own NGX runtime on this driver. host64\dlss5-feed-host.log names it exactly:

  [host] evaluate raised 0xC0000005 (reading address FFFFFFFFFFFFFFFF) in D3D12Core.dll
  [host] evaluate fault stack, by module (innermost first):
         D3D12Core.dll <- nvngx_dlssnr.dll <- _nvngx.dll <- renodx-dlss5.addon64 <- dlss5-feed-host64.exe
  

  The faulting address differs from run to run (-1 above, 0xC on the next), which is what an uninitialised pointer looks like. Nothing on this side is in that chain past the call itself, and 0.14.0-beta.1 says so up front when it sees the combination. Measured here with dlss5-feed-host64.exe --test on an RTX 5090, same files throughout, changing only the consumer:

  neural consumer in host64\	driver 616.56	driver 616.64
  none	—	300/300
  Deep Fried Chicken 1.4.8-alpha	—	300/300
  renodx-dlss5 v4.55 (classic engine)	—	300/300
  renodx-dlss5 "latest" (classic engine)	—	300/300
  renodx-dlss5 v4.6	—	1/300
  renodx-dlss5 v4.7	300/300	0/300

  A dash is not a pass — it is a combination nobody has run. Only v4.7 was measured on both drivers, and it is the row that flips, which is what pins the driver rather than the machine. (616.56 was this machine's driver until 2026-09-04; it cannot be re-measured here now. One real-game log on 616.86 reproduces the v4.7 failure; nothing else has been run on 616.86.)

  616.64 also changed what NGX says about the feature that path creates: the requirements query for feature 18 answered NotImplemented (0xBAD00012) on 616.56 and answers supported on 616.64. So the driver moved and the v4.6/v4.7 engine is what does not survive the move. Four fixes, any one of them: update renodx-dlss5 to v6.1 or newer (v6.1.0, v7.0.0-rc8 and v8.0.1 all pass 300/300 on driver 617.14, where v4.7 still gives 0/300; the installer downloads the newest), use Deep Fried Chicken as the neural consumer, use a classic-engine renodx-dlss5 build, or roll the driver back to 616.56. Run host64\dlss5-feed-host64.exe --test to check your own combination in about fifteen seconds.

• 32-bit game: dlss5-feed.addon64 in host64\ — it does not belong there and 0.14.0-beta.1 refuses to run when it finds itself in the helper. host64\ takes dlss5-feed-host64.exe, a 64-bit ReShade dxgi.dll, the neural consumer and the nvngx_* runtimes; the game's own folder keeps dlss5-feed.addon32. Delete the stray file — Verify-DLSS5Feeder.ps1 flags it too.

• DLSS 5 panel stuck in STANDBY (RenoDX add-on) — it missed the first create; the built-in warm-up re-creates the feature a few seconds in, which normally clears it.

• Deep Fried Chicken's tab says DISARMED, CONFLICT or FAILED — DISARMED is arm=0 in deep-fried-chicken.cfg (restart-only), or the first launch before its LoadFromDllMain entry took effect; CONFLICT means a second neural consumer (renodx-dlss5.addon64, renodx-dlss.addon64, alexs-toolkit.addon64) is loaded — remove it and fully restart. dlss5-feed.log prints the same state.

• A regular stutter every few seconds, with poor 1% lows but a normal average frame rate — first check the neural consumer's version. Deep Fried Chicken up to 1.4.7 rescanned every module in the process every 300 presented frames, which is about every 5 s at 60 fps and costs a frame each time in a host with a lot of DLLs loaded. 1.4.8 fixes it; its log then says smart discovery settled: periodic full-module fallback disabled. To confirm the cause rather than guess, set stall_log_ms in dlss5-feed.cfg to roughly one and a half frame times (25 for 60 fps) and read the STALL frame lines: they say whether the lost time was inside the NGX evaluate call, inside this add-on, or outside both. arm=0 plus a full restart is the clean A/B, because the live enabled=0 switch leaves the consumer's observation hooks installed and the scans running.

• Neural rendering stops mid-session, no crash — the overlay's Status section now names the reason next to Session: disabled, and Re-enable restarts it. If the log says the GPU did not retire allocator slot N within 2000 ms, the GPU is not keeping up rather than broken: raise gpu_timeout_ms. A single slow frame no longer stops the session — three consecutive failures do.

• OptiScaler is installed and nothing looks neural — dlss5-feed.log (or the host log) should read NGX calls are routed through OptiScaler DLSS-NR and, a few frames later, neural model (feature 18) loaded. the DRIVER answered the NGX probe means OptiScaler's redirect did not take (or [ProcessFilter] TargetProcessName names another exe); NEURAL MODEL NOT CREATED means it never built the pass and OptiScaler.log beside it says why; not a DLSS-NR fork means a stock OptiScaler, which can only upscale. Both forks (wilsjo2, Dagherbou) are recognised. See Alternative: OptiScaler DLSS-NR.

• Corruption or flicker with Smooth Motion on — see Before you install at the top of this README. The overlay says whether Smooth Motion was detected, and dlss5-feed.log records the feeding thread: frame fed from thread N, not the usual M means Present is arriving off-thread, and re-entrant frame … dropped means it arrived twice at once. Both lines are worth quoting on an issue. Turn Smooth Motion off for this game's API only, with Profile Inspector.

• Smooth Motion on, everything reports healthy, nothing looks neural — two ReShade runtimes (effect runtime … initialised (device …, window class '…'; 2 runtimes in this process)), and before 0.11.0-beta.2 the feeder could be bound to the wrong one. Update; the log then shows binding to effect runtime …: it is the one rendering DLSS5_Feed.

• Can I use DLSS Quality / Balanced / Performance instead of DLAA? No — not as a setting, and not as a future one either. Real DLSS upscaling needs the game to render smaller than the screen and jitter its camera, then hands DLSS that small frame; the feeder only ever sees the finished, screen-sized frame ReShade has, so it publishes a 1:1 DLAA contract by construction. work_resolution (D3D11) is a cost knob: the frame is downsampled, DLAA + neural rendering run on the smaller image, and the result is expanded back — that is why 50–66% looks blurry rather than like DLSS Quality. From 0.12.0 the expand-back can be AMD FSR 1 instead of a bilinear stretch (work_upscale=1, or the "FSR 1 expand-back" checkbox under the slider): much crisper at 50–75%, still bounded by the native frame. If what you want is a cheaper neural pass on a sharp frame, keep work_resolution=100 and use a consumer that can lower the neural pass's resolution by itself, such as OptiScaler DLSS-NR ([DlssNr] WorkingScale): the feeder does not run that pass and can only shrink the whole frame. Leave the DLSS 5 add-on's NREnableUpscaling at 0: with a 1:1 contract it cannot engage, and on v4.6 it parks neural rendering for the run. For games that ship DLSS already, use the game's own DLSS (or OptiScaler) instead of this feeder.

• What about adding the jitter ourselves? (work_upscale=2, D3D11, experimental) — it exists, and it is honest about its limits. The feeder shifts the downsample grid by a Halton sub-pixel offset every frame, reports that offset to DLSS, and creates the feature in Super Resolution mode (render = work size, target = native), so DLSS itself rebuilds the native frame from the jittered history. Three things it cannot change: the game still rendered every native pixel, so there is no frame-rate win on the game side; every jittered sample comes from that same native frame, so the best DLSS can converge to is the image you already had at 100%; and DLSS SR leans on motion vectors far more than DLAA — with the feeder's estimated vectors, a rejected history means a blurry low-res frame rather than a sharp native one, so expect smear in motion. Measured (Fable Anniversary, 3578x2013, Deep Fried Chicken 1.4.8): it saves nothing. At 50% work resolution DLAA + FSR 1 ran at 57–62 fps and DLSS reconstruction at 44–48 fps, the same as 100%. DLSS Super Resolution's cost follows the output size, and the neural consumer takes DLSS's resolved native output as its input (neural=3578x2013->3578x2013 in Chicken's log), so the neural pass runs on every native pixel again. The image also shimmers. That is why it is not on the overlay: it stays reachable as work_upscale=2 in the cfg for anyone who wants to repeat the experiment, and nothing more. What people actually want — render the game smaller, run DLSS 5 on that, upscale the neural result — would need a neural model trained to upscale, which is NVIDIA's to ship. The only route to a real frame-rate win today is the game rendering fewer pixels: set a lower resolution in the game and let the GPU scale it to the panel (NVIDIA Control Panel → Adjust desktop size and position → GPU scaling); the feeder then works 1:1 at that size. See docs/PLAN-PROXY-SWAPCHAIN.md for what doing that in-process would take.

• 32-bit game: changing the work resolution froze the PC for a few seconds, then DLSS never came back and the helper window stopped responding — the helper's log shows feature create did not complete, its ReShade.log shows DXGI_ERROR_DEVICE_HUNG, and every later rebuild fails with OpenSharedHandle … 0x887A0005. Before 0.12.0 the helper released the old feature and textures without waiting for the GPU, which a neural consumer that keeps a graph alive on the feature (Deep Fried Chicken) turned into a GPU hang, and a helper whose D3D12 device was removed retried against it forever. From 0.12.0 the rebuild drains the GPU first, and a helper whose device was removed says so, exits, and is respawned by the add-on on the next frame.

• 32-bit game: tex 1 CreateTexture2D failed 0x80070057, failure: shared build forever — the game's D3D11 device is feature level 10.x and cannot bind the UAV the DLSS output needs. From 0.11.0-beta.2 the helper creates the shared set instead (the log says the host will create the shared set instead); on older builds there is no workaround (mode=1 uses the same texture).

• 64-bit game: Output: … failed 0x80070057, then failure: resource build three times and stopped: repeated failures — the same refusal as the 32-bit case above, on the in-process path: Output is the only one of the four shared textures created with an unordered-access bind, and some D3D11 devices accept every other slot at the identical size and format and refuse that one. Until 0.14.0-beta.5 there was no fallback here and the session latched off (#70). From beta.5 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 — the log says shared copy without UAV, DLSS writes a private texture. The failure line now also names which call refused (CreateCommittedResource / CreateSharedHandle / OpenSharedResource1) and prints the device's feature level.

• NVSDK_NGX_D3D12_Init fails and the log blames your device or driver — check the line just above it. If NGX answered the capability query with 0xBAD00002 PlatformError, it refused a question that touches no device at all, and the problem is something else loaded into the game (an overlay, an injector, anti-cheat, another NGX consumer) rather than your GPU or driver. 0.14.0-beta.5 says that in the failure line instead of the old catch-all (#47).

• The game crashed — dlss5-feed.log (or dlss5-feed-host.log) ends with ### CRASH RECORDED ###, naming the exception, the module it faulted in and what the feeder was doing at the time, and from 0.11.0-beta.2 a dlss5-feed-crash.dmp is written next to it. Post the log and the .dmp on the issue; the last ordinary line before the crash line (the session opens in fixed steps — adapter, D3D12 device, NGX init, multithread protection, session open) pins the step.

MSVC (v143/v145) + Windows SDK. Dependencies not vendored: the NGX SDK (see external/ngx/README.md) and the Vulkan headers (see external/vulkan/README.md); the ReShade add-on headers are included under external/reshade/include (BSD-3-Clause, Patrick Mours), as is MinHook under external/minhook (BSD-2-Clause, Tsuda Kageyu) for the vkCreateDevice hook.

NGX links against the Release CRT, so the builds use /MD.

Each script picks up its toolchain through tools�cvars.bat, which asks vswhere for the latest Visual Studio install with the C++ tools and falls back to a fixed BuildTools path. Set VCVARSALL to your own vcvarsall.bat to override it.

CI — .github/workflows/build.yml builds all five targets on every pull request, fetching the NGX SDK and the Vulkan headers from their upstream repositories, and uploads the binaries as a workflow artifact. It only proves the tree compiles and links: DLSS needs an RTX GPU and a real swapchain, so nothing in the table under Status can be verified there.

• DLAA contract, optional reduced work extent on D3D11 — render resolution still equals DLAA output resolution, but the private work extent can be 50–100% of the native backbuffer and is spatially expanded afterward (bilinear, or FSR 1 with work_upscale=1). D3D12, Vulkan and OpenGL paths remain at 100%. This is not jittered DLSS Super Resolution, and a Quality/Balanced/Performance mode cannot be added: see the FAQ entry in Logs and troubleshooting.
• Estimated motion vectors → temporal artifacts in fast motion; the UI is processed with the scene (a UI mask / pre-UI colour capture is future work).
• Geometry vectors are experimental and off. The camera-model fit is derived from the provider's own flow, so it inherits that noise, and it has no way to know the HUD is not part of the scene. Doing it properly needs the game's real view-projection matrices, not a fit.
• Synthetic-jitter DLSS reconstruction (work_upscale=2) is a cfg-only experiment, not on the overlay. It turns DLSS into the expand-back for the work-resolution cost knob, and the measurement says it costs as much as 100% (DLSS SR follows the output size; the neural consumer runs on the resolved native output) and shimmers (the jitter sign convention, jitter_sign on the 64-bit add-on, was never confirmed). D3D11 only. On the 32-bit path the add-on ships the target size with each build and the grid shift with each frame (IPC v6) and the helper creates the SR feature; no covering preset means a DLAA + FSR 1 rebuild. Kept so the result can be reproduced; use FSR 1.
• A light that flickers faster than DLSS's history converges is averaged into a slow pulse. The trust mask reduces it; nothing available to a post-process feed removes it.
• Exclusive-fullscreen swapchain churn can make some games reload effects repeatedly; windowed is smoother.
• Depends on a closed-source, community-distributed neural consumer and the NGX runtime; both can change. Deep Fried Chicken is game-validated here only on 64-bit Vulkan in-process and through the 32-bit x64 helper — its other backends are source-contract compatible per its author, and it claims neither Frame Generation nor 32-bit Vulkan. OptiScaler DLSS-NR, the third option and the open-source one, is validated on the no-game helper rig (300/300 evaluates, neural pass confirmed over its DLSS, XeSS and FSR backends with Dagherbou's build, and over DLSS with wilsjo2's v0.8.8); in-game rows land in Status as they are run. With OptiScaler in the process, a game that has DLSS of its own gets that captured too — this project is for games without DLSS, and the add-on says so when it sees Streamline.
• The 32-bit and D3D9 paths are beta — see docs/PLAN-32BIT.md for the full design and known risks. Cross-process adds a small amount of scheduling jitter versus the in-process 64-bit path (not measured as a problem so far).
• 32-bit Vulkan has not run in a real game yet — the cross-bitness interop is proven by the spike pair, but nothing above it is. See docs/PLAN-VULKAN32.md.

• D3D11↔D3D12 shared-texture / fence transport adapted from NIGos' dlss5-dx11-bridge (MIT) — not re-hosted here.
• Motion vectors: interop happens purely by declaring each provider's output texture identically, so ReShade binds the same resource — the mechanism dh_uber_rt and VORT use. Thanks to LumeniteFX (Umar Afzaal), iMMERSE Launchpad (MartysMods), VORT (MIT), Jakob Wapenhensch's ReshadeMotionEstimation (CC BY-NC 4.0), the qUINT ecosystem that established the texMotionVectors convention, and AlucardDH's dh-reshade-shaders for the provider-switch pattern. No provider's files are bundled or included by this project's shader — install them from their own repositories, under their own licenses.
• DLSS 5 neural rendering: Deep Fried Chicken by Alexander — the recommended consumer, and the author who built the ABI-1 interop this feeder negotiates over (FEEDER-INTEROP-v1.md) — and the RenoDX community's renodx-dlss5 add-on, the alternative. Neither is bundled here.
• ReShade add-on API by Patrick Mours.
• dgVoodoo2 by Dege — the D3D9 translation layer that makes the DirectX 9 path possible.
• D3D12 stability findings independently confirmed by the Pizzawookiee fork's diagnostics.

MIT — see LICENSE. This covers only the code in this repository (src/, shaders/, host/); the dependencies above keep their own licenses.