0.8.0-beta.4 — public test build: NVIDIA Smooth Motion compatibility (#1, #10)

Test build. Please try it and report back — this is asking for help, not announcing a feature.

It contains all of 0.8.0-beta.3 plus NVIDIA Smooth Motion compatibility, and supersedes it. Built from branch beta/v0.8.0-beta.4 — PR #18 still rides along unmerged, which is the point.

dlss5-feed.log line 1 will say dlss5-feed 0.8.0-beta.4 so you can confirm which build you are on.

---

1. NVIDIA Smooth Motion compatibility — #1, #10 — new in beta.4

If you use Smooth Motion, this is what beta.4 exists for — and the Vulkan case is the one nobody has reported back on.

The README has carried a bare "not compatible with Smooth Motion" line for a while, with no explanation. Investigating it found a real bug on this side, and it is fixed here.

What Smooth Motion actually is: not a pure driver feature. The driver injects NvPresent64.dll into the game, which hooks CreateDXGIFactory*, wraps the game's IDXGISwapChain, and calls Present more than once per game frame from its own pacer thread. ReShade's effect chain — and therefore this feeder — runs inside Present. So one caller per frame quietly became several, possibly concurrent ones.

The feeder was not thread-safe. It had exactly one lock in the whole add-on, and it was for the log file. The state struct, the D3D12 allocator ring, the shared textures and the game's D3D11 immediate context were all unsynchronised. This build:

• serializes the whole per-frame path — one lock plus a re-entrancy guard, at the single dispatch point all four backends (D3D11/D3D12/Vulkan/OpenGL) go through. The guard is not redundant: a CRITICAL_SECTION is recursive, so a lock alone would let a re-entrant Present on the same thread walk into a half-built frame.
• turns on ID3D11Multithread protection on the game's immediate context, restoring whatever the game had set on teardown.
• logs the feeding thread id and any change of it — frame fed from thread N, not the usual M is the smoking gun for this class of report, and re-entrant frame … dropped is the other one. Please quote these lines if you report anything.
• detects Smooth Motion and says so in the overlay and the log.

Independently: the feed no longer stops permanently after one slow frame. BeginCommands waited 2 s for the GPU and, on timeout, disabled the add-on for the rest of the session — with the overlay's Re-enable button as the only way back. That is the best explanation for the "neural rendering silently stops, no crash" half of #1. Now a timeout fails that frame, three consecutive failures stop the feed, and the overlay shows the reason next to the Re-enable button instead of pointing you at a log file. New dlss5-feed.cfg key gpu_timeout_ms (default 2000, clamped 100–60000) raises the wait on a contended GPU.

Status: one data point. Metro 2033 Redux (64-bit D3D11) with Smooth Motion active boots, opens a session, and delivers frames at the same per-frame cost as before the lock (0.52 ms vs 0.50 ms) — but Present stayed single-threaded in that game, so the new guard is armed and never fired. That is one game on one machine, and the Vulkan report (#10) has no data at all. Please add yours.

If it still corrupts or flickers, turn Smooth Motion off for that game's API only rather than globally — NVIDIA Profile Inspector, Smooth Motion - Enabled APIs (0xB0CC0875), a bitfield defaulting to 7: clear 1 for DX12, 2 for DX11, 4 for Vulkan. Smooth Motion - Debug Bars (0xB01B8B02) draws coloured bars on generated frames and will tell you whether the bad frames are the generated ones — that is the single most useful thing you can attach to #10.

Two Smooth Motion crashes that are NOT this feeder

Both kill the game 1–2 s into boot, before the feeder ever feeds a frame, so they look like anything but their real cause:

• The Luma HDR add-on. It reads GetCurrentBackBufferIndex() and passes it to GetBuffer(); under Smooth Motion's flip-model wrapper the index rotates, GetBuffer(1) fails, and the unchecked null result is dereferenced. Fix submitted upstream: Filoppi/Luma-Framework#184. Until it lands, remove the Luma .addon or turn Smooth Motion off for that game.
• NRStyle=2, RenoDX v4.6's own setting, changed from its overlay panel and applied at the next launch. Crashes at boot even with Luma gone. This build warns when it sees it; set NRStyle=0 in ReShade.ini's [RenoDX.DLSS5] section to recover.

2. DLSS 5 add-on v4.6 support — #27

Unchanged from beta.3. Detects v4.6 (NRToggleKey marker), keeps the lazy-adoption engine path, writes safe [RenoDX.DLSS5] defaults when unset, and unbinds v4.6's new global hotkeys inside host64. v4.55 remains the known-good pin — working setups lose nothing by staying put. Details in the beta.3 notes.

3. Guide diagnostics + one-pass guides — PR #18, by @rubicoul

Unchanged from beta.2 — MV probe / Depth probe lines every 600 frames, and the shader emits motion vectors, trust mask and raw depth in one MRT pass instead of two. If your image changes at all, that is a bug — please say so. Details in the beta.2 notes.

4. 32-bit Vulkan / DXVK — #15

Unchanged from beta.1, still unproven in a real game. Full picture in the beta.1 notes.

---

Upgrading

32-bit games only: the game↔helper pipe protocol is v3, as in all 0.8.0 betas — addon32 and the host64\ exe must both come from a 0.8.0 zip; mixing with 0.7.0 refuses to run and says so in the log. beta.1 through beta.4 are protocol-compatible with each other. 64-bit games are unaffected.

Reporting

Smooth Motion on D3D11/D3D12 → #1 · Smooth Motion on Vulkan → #10 · DLSS 5 add-on v4.6 → #27 · Guide diagnostics → PR #18 · 32-bit Vulkan → #15 · anything else → a new issue.

Worth including: game, resolution, API, the MV probe / Depth probe lines from dlss5-feed.log, and for Smooth Motion runs the fed from thread lines plus whether the overlay shows the Smooth Motion notice.

READ-ME-FIRST.txt in the zip has the install layout and the list of files you have to source yourself (they are not redistributable).

🤖 Generated with Claude Code

https://claude.ai/code/session_01RtiH9eMwBhjd4DPpKG7stc

0.8.0-beta.3 — public test build: DLSS 5 add-on v4.6 support (#27)

Test build. Please try it and report back — this is asking for help, not announcing a feature.

It contains all of 0.8.0-beta.2 plus support for the v4.6 build of renodx-dlss5.addon64, and supersedes it. Built from branch beta/v0.8.0-beta.3 — PR #18 still rides along unmerged, which is the point.

dlss5-feed.log line 1 will say dlss5-feed 0.8.0-beta.3 so you can confirm which build you are on.

---

1. DLSS 5 add-on v4.6 support — #27 — new in beta.3

Anyone on any API can help here, and this is what beta.3 exists for.

The RenoDX Discord now distributes a v4.6 build of the DLSS 5 neural-rendering add-on. The README pins v4.55 because newer builds were reported to conflict — but static analysis of the v4.6 binary found no remaining structural conflict with the contract this feeder publishes, so this build adds support instead of a taller fence:

• Detects v4.6 (NRToggleKey marker in the binary) and keeps the lazy-adoption engine path — no warm-up re-create. dlss5-feed.log says v4.6+ … engine, and the overlay shows the generation.
• Writes safe [RenoDX.DLSS5] defaults when unset: NeuralUplift=1, NREnableUpscaling=0, EnableHooks=2. Upscaling stays off because it can never engage — this feeder always publishes a 1:1 DLAA contract — and v4.6 pairs its WIP upscaling path with a rejection latch that would park NR on the native path for the whole run. Anything you set yourself is left alone.
• Unbinds v4.6's new global hotkeys inside host64 (32-bit games): they are polled with GetAsyncKeyState, so a gameplay F5 — a quicksave in half the world's games — would silently fire GPU-readback screenshots, or toggle NR off, inside a background process with no visible feedback.

Older add-on builds are untouched: every guard is keyed to a marker only the newer builds carry, or writes a config key older builds never read. Working v4.55 setups lose nothing by staying put.

To test: swap in the v4.6 renodx-dlss5.addon64 (game folder for 64-bit, host64\ for 32-bit) and play. Good signs: the add-on's overlay reaches ACTIVE - NR INJECTED and ReShade.log shows inline feature 18 evaluation succeeded. Report either way in #27 — the two things analysis could not verify are v4.6's new binding-state tracker arming against this feeder's command list, and its per-feature failure latch across feature rebuilds.

2. Guide diagnostics + one-pass guides — PR #18, by @rubicoul

Unchanged from beta.2 — MV probe / Depth probe lines in dlss5-feed.log every 600 frames, and the shader emits motion vectors, trust mask and raw depth in one MRT pass instead of two. If your image changes at all, that is a bug — please say so. Details in the beta.2 notes.

3. 32-bit Vulkan / DXVK — #15

Unchanged from beta.1/beta.2, still unproven in a real game. Full picture in the beta.1 notes.

---

Upgrading

32-bit games only: the game↔helper pipe protocol is v3, as in all 0.8.0 betas — addon32 and the host64\ exe must both come from a 0.8.0 zip; mixing with 0.7.0 refuses to run and says so in the log. beta.1, beta.2 and beta.3 are protocol-compatible with each other. 64-bit games are unaffected.

Reporting

DLSS 5 add-on v4.6 → #27 · Guide diagnostics → PR #18 · 32-bit Vulkan → #15 · anything else → a new issue.

Worth including: game, resolution, API, the MV probe / Depth probe lines from dlss5-feed.log, and for v4.6 runs the add-on's own overlay status line.

READ-ME-FIRST.txt in the zip has the install layout and the list of files you have to source yourself (they are not redistributable).

🤖 Generated with Claude Code

https://claude.ai/code/session_01J84wQTqqm4ar6YvTiHqJy3

0.8.0-beta.2 — public test build: guide diagnostics (#18) + 32-bit Vulkan (#15)

Test build. Please try it and report back — this is asking for help, not announcing a feature.

It contains all of 0.8.0-beta.1 plus PR #18, and supersedes it. Built from branch beta/v0.8.0-beta.2, not from main — neither change has been merged, which is the point.

dlss5-feed.log line 1 will say dlss5-feed 0.8.0-beta.2 so you can confirm which build you are on.

---

1. Guide diagnostics + one-pass guides — PR #18, by @rubicoul

Anyone on 64-bit D3D11 or D3D12 can help here, and this is where testing is most useful.

dlss5-feed.log now reports every 600 frames what DLSS actually received, not just what was wired up:

MV probe (centre 64x64, frame N): mean |mv| ... M% non-zero
Depth probe (4x 32x32, frame N): min ... max ... mean ... variance ... M% finite

The depth line is new. It answers a question nothing else could: is your depth buffer really reaching DLSS, or has ReShade's Generic Depth latched onto a UI layer or an already-cleared buffer? A flat warning is diagnostic only — nothing gets disabled and no buffer gets guessed.

The shader now emits motion vectors, the trust mask and raw depth in one MRT pass instead of two. The values handed to DLSS are unchanged; this removes a redundant fullscreen pass. If your image changes at all, that is a bug — please say so. No FPS claim is being made: one pass is real work saved, but not measurable against frame-to-frame noise.

The depth debug view also got a display-only contrast curve, so reversed and far-heavy hardware depth is actually visible. DLSS5_Depth itself stays raw.

Use the DLSS5_Feed.fx from this zip for the one-pass change. The old shader still works with this add-on, so you can swap only the .fx if you want to isolate the two.

2. 32-bit Vulkan / DXVK — #15

Only relevant if you have a 32-bit game on DXVK. Nothing above the transport has run in a real game yet. The cross-bitness interop underneath is verified on hardware; everything above it is a first attempt. Install ReShade as a Vulkan layer (DXVK owns the dxgi/d3d9/d3d11 DLL names), and if the log says the Vulkan interop entry points are missing, try layer-x86\run-with-feed-layer32.bat. Full detail in the beta.1 notes.

---

Upgrading from 0.7.0

32-bit games only: the game↔helper pipe protocol changed in 0.8.0 (v2 → v3). The addon32 and the host64\ exe must both come from this zip; mixing with 0.7.0 will refuse to run and say so in the log. 64-bit games are unaffected. beta.1 and beta.2 are protocol-compatible with each other.

renodx-dlss5.addon64 must be v4.55 — newer builds now overlap this project and conflict.

Reporting

Guide diagnostics → PR #18 · 32-bit Vulkan → #15 · anything else → a new issue.

Worth including: game, resolution, API, and the MV probe / Depth probe lines from dlss5-feed.log.

READ-ME-FIRST.txt in the zip has the install layout and the list of files you have to source yourself (they are not redistributable).

0.8.0-beta.1 — 32-bit Vulkan (DXVK) test build

Test build for #15 — 32-bit Vulkan via DXVK. Pre-release: this has never run in a real game.

What is proven, and what is not

The cross-bitness interop underneath it is verified on real hardware (RTX 5090). A 64-bit D3D12 process creates a shared texture and two shared fences, a 32-bit Vulkan process imports all three, and data round-trips in both directions — spike-vkhost64.exe + spike-vkclient32.exe. All seven KHR interop extensions are present on the 32-bit ICD, and a D3D12 committed texture imports both with and without storage usage. That was the part that could have turned out to be impossible, and it is not.

Nothing above the transport has run in a game. Not DXVK's vkCreateDevice against the add-on's in-process hook, not ReShade x86 as a Vulkan layer, not the BGRA8 swapchain path. Treat this as a first attempt.

How it works

The texture-creation direction flips, exactly as it did for OpenGL: the host creates the shared set and duplicates the handles into the game, because D3D12 cannot open memory that Vulkan exported. src/feed_vk.h and src/feed_vk_hook.h are the 64-bit add-on's own headers, compiled x86; the D3D12 middle moves out to host64\.

Both halves must come from this release

The pipe protocol changed (v2 → v3), for FeedBuildAck::output_fmt — when the host owns the texture it owns the output format too, since only its D3D12 device can be asked whether this GPU does typed UAV stores to BGRA8, and DXVK swapchains are almost always BGRA8. Mixing these files with v0.7.0 will refuse to run and say so in the log.

Install

See READ-ME-FIRST.txt in the zip. Short version: ReShade 6.8+ with add-on support installed as a Vulkan layer (DXVK owns the dxgi.dll/d3d9.dll names), dlss5-feed.addon32 next to the exe, a full host64\ folder, and a motion-vector provider. renodx-dlss5.addon64 must be v4.55 — newer builds now overlap this project and conflict.

If dlss5-feed.log says the Vulkan interop entry points are missing, the fallback is layer-x86\run-with-feed-layer32.bat.

Also in this release

Alex's Toolkit detection in the 64-bit add-on and the host: they now report the active DLSS 5 pass count, and what a multi-pass cascade costs temporally.

Everything else is unchanged from v0.7.0. The 64-bit add-on is included for completeness only; it is not used on the 32-bit path.

DLSS5-Feeder v0.7.0 - OpenGL support (tested in one game: Worms Ultimate Mayhem, 32-bit)

OpenGL games are now supported, in both bitnesses — the last renderer that still disabled itself. Everything else is unchanged from v0.6.1.

Read this before you get excited

This has been tested end-to-end in exactly one game: Worms Ultimate Mayhem, 32-bit OpenGL, at 4K. That is one data point, not a games table.

The 64-bit OpenGL path shares the same header, the same transport and the same code path, and its interop is proven on hardware by the bundled spike — but no 64-bit OpenGL game has been run. One question is genuinely still open there: whether the DLSS 5 add-on arms its NGX hooks in a process where ReShade loads as opengl32.dll rather than dxgi.dll. On the 32-bit path that question does not arise, because the add-on lives in the 64-bit helper process, where it is long proven. If you try a 64-bit OpenGL game, ReShade.log will tell you: look for D3D12 NGX hooks installed.

Only LumeniteFX Kernel has been shown to compile under ReShade's GLSL code generation. The other four motion-vector providers are untested on OpenGL.

---

Install

Same pieces as any other 64-bit game, with one difference: ReShade for OpenGL is a local opengl32.dll next to the game exe — pick OpenGL in ReShade's installer and tick "Enable loading of add-ons". No layer, no hook, no registry entry, and no AddonPath setting: add-ons load from ReShade's own directory, which is the game folder.

ReShade 6.8 or newer is required. This add-on needs add-on API version 20; a 6.7.x install offers 14 and will silently refuse to load it. If nothing appears in the overlay, check the first line of ReShade.log.

For a 32-bit OpenGL game, install the x86 ReShade plus dlss5-feed.addon32 and the host64\ folder, exactly as in the existing 32-bit instructions. Install both halves from the same release — the protocol version changed (see below) and mismatched halves now refuse each other with a message instead of misbehaving.

Hybrid laptops: force the game onto the NVIDIA GPU. On the integrated GPU the interop extensions do not exist and the feed disables itself saying so — DLSS could not have run there anyway.

How it works, and why it is not just the Vulkan path again

The DLSS evaluate still runs on a private D3D12 device, because the DLSS 5 add-on only hooks D3D12 NGX entry points. What is new is how the frame crosses: D3D12 creates the shared textures and fences, OpenGL imports them. That direction is forced — GL memory objects are import-only, there is no memory-object export in GL_EXT_external_objects_win32.

Two things differ sharply from the Vulkan transport:

The whole per-frame GL side is raw. On Vulkan, a ReShade api::fence is a VkSemaphore, which let that path hand its imports back to ReShade and keep every queue operation inside ReShade's own locks. On OpenGL an api::fence is documented as "an opaque value" — there is nothing to hand back. So the GL path issues zero ReShade API calls per frame beyond its texture lookups. That 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 fires the technique event while it is itself issuing GL commands on that same thread and context. Our calls interleave in program order — there is no lock to bypass, and no barriers are needed at all.

No device hook and no layer. Vulkan bakes extensions in at vkCreateDevice, which is why that path needs an inline hook and ships a fallback layer. OpenGL has no creation-time opt-in: the interop extensions are either in the current context's extension string or they are not, and if they are not, the frame is not being rendered on an NVIDIA GPU. OnCreateDevice needed no OpenGL branch at all.

Protocol v2 (32-bit path)

The 32-bit OpenGL path reuses the same interop header compiled x86, over the existing helper-process protocol — with one change the API forces: the host creates the shared textures, since a GL process cannot export one.

• FeedHello gains client_kind, so the host knows which direction to use.
• FeedBuildAck gains the host-duplicated texture handles and their allocation sizes — a client with no D3D12 device cannot ask for those itself.
• A v2 host still reads a v1 client's shorter hello, and both sides refuse a version they do not understand rather than misparsing it.

The D3D11 32-bit path is untouched and still creates its own textures.

What the sRGB trap did not do

glBlitFramebuffer decodes and encodes sRGB while GL_FRAMEBUFFER_SRGB is enabled, which is exactly the shape of the washed-out image fixed on Vulkan in v0.6.1 (#11). The state guard forces it off for our blits so the bytes move raw, and the build logs the render target's colour encoding. In Worms it reports GL_TEXTURE_2D / GL_LINEAR, so the trap does not arise there and the gl_srgb escape hatch the plan reserved was not needed and is not implemented. If you hit a washed-out OpenGL game, that log line is the first thing to report.

Also in this release

• Two new spikes, spike-gl64.exe and spike-gl32.exe, which round-trip a texture and a fence between D3D12 and OpenGL — in-process and cross-process — through the same header the add-on ships, so a PASS is a PASS for the shipped code. They need an NVIDIA GPU to run, none to compile, and CI builds them on every pull request.
• Measured cost in Worms Ultimate Mayhem at 4K: 0.13 ms/frame of game CPU in steady state.

Files

File	For
dlss5-feed.addon64	64-bit games (D3D11, D3D12, Vulkan, OpenGL)
dlss5-feed.addon32 + dlss5-feed-host64.exe	32-bit games (D3D11, OpenGL) — the helper goes in host64\
DLSS5_Feed.fx	required by both, into reshade-shaders\Shaders\
feed-vk-layer.zip	Vulkan fallback, only if the log says the interop entry points are missing

renodx-dlss5.addon64, nvngx_dlssnr.dll and nvngx_dlss.dll are not redistributed here — see the README.

DLSS5-Feeder v0.6.1 - freeze fix, Vulkan colour fix, adjustable work resolution

First non-beta release of the 0.6 line, covering everything since v0.6.0-beta.1 (11 commits).

---

Applying DLSS 5 settings could freeze the whole machine (32-bit path)

Hitting Apply to the DLSS 5 host could wedge the GPU hard enough to take the entire desktop with it, needing a hard reset. If you have ever seen this, upgrade.

The game queues a GPU-side Wait(fence_out, n) every frame before the host has signalled it. Applying settings closed the pipe and terminated the host without draining that wait, and the host's serve loop broke out on pipe close without signalling the frame it had been asked for. Nothing could ever satisfy the wait, so everything queued behind it — Present included — stalled until the driver gave up. Because the wedged queue owned the fullscreen swapchain, the desktop stopped compositing rather than just the game: nvlddmkm 153 (UCodeReset TDR), repeated resets, and a failed shutdown.

Both sides are fixed:

• The host drains its own queue and signals fence_out to UINT64_MAX on every exit from its serve loop, releasing any wait the game could hold — including for a frame message it never got to read.
• The feed drains the last submitted frame before closing the pipe, while the host is still alive to signal it, and now releases both fences on every close. That also fixes a second instance of the same wedge: a crash-driven respawn used to keep waiting on the dead host's fence forever while ignoring the new one.
• Game exit drains too.

Washed-out image and lifted blacks on Vulkan (#11)

The copy home was always vkCmdBlitImage, chosen because it tolerates a format difference — but a blit converts, and that conversion is sRGB-aware. A linear-typed output blitted into a VK_FORMAT_*_SRGB swapchain got a linear→sRGB encode applied on top of frames that were already encoded, so everything came back brighter with visibly lifted blacks.

The bytes now go home untouched: the output keeps the backbuffer's channel order, layout comparison ignores the transfer function (an _SRGB backbuffer and a UNORM output are interchangeable for a raw copy), and the Vulkan path takes vkCmdCopyImage whenever the layouts match. D3D12 benefits too — its copy_resource was outright invalid across format families. Since typed UAV stores to B8G8R8A8_UNORM are an optional D3D12 feature, the format resolver probes for UAV_TYPED_STORE and falls back to RGBA where the device lacks it. A startup log line records which copy path was chosen.

Verified in The Surge 2 (the original report), regression-checked in DOOM (2016) Vulkan.

Adjustable work resolution (#19)

DLSS can now run at a fraction of the native resolution while the game and its backbuffer stay native-sized — a 50–100% slider, on both the 64-bit and 32-bit paths. Thanks to @Phroster for the original implementation.

Two things landed on top of it:

• Every value below 100% did nothing. The feed hit an early return before building anything, so DLSS disappeared entirely and only 100% ever worked. Neither colour source could actually be sampled: DLSS5_ColorInput : COLOR is a semantic texture whose binding is null, and ReShade's backbuffer has no D3D11_BIND_SHADER_RESOURCE. The frame is now copied into a texture we own and downsampled from that — one extra copy, only on the sub-100% path. Verified in Metro 2033 Redux at 50/67/73/90%.
• Ported to the 32-bit path, on the same terms and with no host changes (FeedBuild already carries the size over the pipe). Motion vectors scale with the resolution ratio; depth is point-sampled so interpolation across a silhouette cannot invent geometry. Verified in Fable Anniversary at 3578x2013.

At 100% nothing changes on either path — no staging texture is allocated and the blit samples 1:1.

The DLSS 5 panel now matches the add-on it drives

The overlay exposed 7 of the add-on's 16 settings, used sliders where the add-on has dropdowns, and invented its own labels and ranges — which is how an out-of-range NRStyle could be written into your host config.

It now mirrors the add-on one-for-one — same order, same labels, same dropdown entries and grouping:

• New settings: Enable Upscaling, NR Preset, Skin Structure Strength, Scene Paper-White Scale, HDR Transfer Strength, Color Strength, Depth Convention, Motion Scale X/Y.
• Dropdowns instead of sliders: NR Style (Default / Natural / Cinematic), NR Preset (Default / Preset #1–#3), Depth Convention (Use game NGX flag / Force normal / Force inverted).
• NR Intensity is a float slider, not an integer one.
• Settings you never touch are no longer written at all, so the feed's defaults cannot overwrite the add-on's own. An out-of-range stored value is flagged in the panel.
• New Reload from host button.

Applying no longer steals focus

The host asks DXGI to leave its window alone (MakeWindowAssociation) and parks it at the bottom of the Z-order; the feed restores the game's foreground window once the replacement host connects.

The restart is also advertised as up to 15 s rather than 2 s — which is what the pipe wait has always actually budgeted for, since the replacement host re-initialises NGX and reloads the ~165 MB DLSSNR model before it can serve a frame.

Build and CI

• Every pull request now builds all five targets on a hosted Windows runner — both add-ons, the host, the Vulkan layer and the spike — fetching the NGX SDK and Vulkan headers from upstream, and uploading the binaries as an artifact. Compile-and-link only: nothing in the README's games table can be verified without an RTX GPU and a real swapchain.
• The build scripts enter the toolchain through tools\vcvars.bat (vswhere first, %VCVARSALL% honoured, VS 18 BuildTools as fallback) instead of hardcoding that path five times. .gitattributes pins *.bat to CRLF, since cmd.exe mis-parses labels in LF-only batch files.
• The NGX import library is now taken from lib/Windows_x86_64/x64/ exactly — an alphabetical find|head was picking the vs2010 one and dying in LNK2038 CRT mismatches.

Documentation

The README covers the 0.6 motion-vector provider system, with LumeniteFX Kernel as the recommended 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 does not compile on ReShade 6.8, yet ReShade still lists it as enabled. This release detects that and says so in the overlay and the log.

Upgrading

Replace dlss5-feed.addon32 and host64/dlss5-feed-host64.exe together — the freeze fix needs both halves. 64-bit and Vulkan users need dlss5-feed.addon64 (or the layer) for the colour fix.

Full Changelog: v0.6.0-beta.1...v0.6.1

DLSS5-Feeder v0.6.0-beta.1 - motion-vector providers, validation, LumeniteFX

Beta. This build changes how motion vectors reach DLSS: several providers are now supported, the vectors are validated before DLSS sees them, and the add-on tells DLSS which pixels not to trust. The README has not been updated for it yet — the instructions below are the documentation for this beta.

Use LumeniteFX Kernel as the motion-vector provider

This is the configuration the beta was tuned on, and the one to use:

1. Install LumeniteFX (from its own repository — nothing of it is bundled here): copy its Shaders\ content (the lumenite_*.fx files and the include\ folder) into reshade-shaders\Shaders\, and Textures\lumenite_bluenoise256.png into reshade-shaders\Textures\.
2. Put this release's DLSS5_Feed.fx into reshade-shaders\Shaders\ (replace the old one) and dlss5-feed.addon64 next to the game exe (replace).
3. In the ReShade overlay, expand DLSS 5 Feed and, in its Preprocessor definitions, set
   DLSS5_MV_PROVIDER = 3, then reload effects. The shader's panel now reads "Motion vector provider: LumeniteFX Kernel".
4. Enable "LUMENITE: Kernel 2.0" above DLSS 5 Feed. Disable any other motion-vector technique (DRME, Launchpad, VORT).
5. Leave the Validation settings at their defaults (they are the tuned ones: luma test off, depth 0.10, consistency 1.4 px, static-hypothesis test on). Leave "Use geometry vectors" off — it is experimental (see below).

Check: dlss5-feed.log should contain DLSS5_MV_PROVIDER=3 (LumeniteFX Kernel) -> Lumenite_Kernel (enabled) and, later, an MV probe … N% non-zero line with a non-zero percentage while you move. The add-on's overlay page (Add-ons → DLSS 5 Feed → Motion vectors) shows the same in red if something is off.

Other providers still work with the corresponding definition value — 0 texMotionVectors (qUINT, dh_uber_motion), 1 iMMERSE Launchpad, 2 VORT, 4 LumeniteFX QuantMotion — but Kernel is the recommended one for this beta.

ReshadeMotionEstimation (DRME) does not compile on ReShade 6.8 (cannot sample from texture that is also used as render target). It still shows up 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; if you followed that, this is why motion looked unstable. The add-on now detects this case and says so in the overlay and the log.

What changed

Motion-vector providers — DLSS5_Feed.fx binds one provider's output texture, chosen at compile time with the DLSS5_MV_PROVIDER definition (the same mechanism dh_uber_rt and VORT use). Only the selected provider's texture is allocated; nothing of any provider is included. Launchpad mode files Launchpad's per-frame optical-flow request itself, so it works without RTGI running.

Validation — every provider is optical flow: it answers a lighting change (flicker, flames) with a vector that points at whatever happened to match, and DLSS then warps history in from there. The shader now reprojects each vector into the previous frame and checks it — depth (disocclusion), vector consistency (fire, smoke) and a static-hypothesis test that asks, on illumination-normalised structure, whether "did not move" explains the pixel better than the vector does (the flickering-wall case). Vectors that fail are zeroed; the pixel is flagged in a new DLSS5_Mask texture that the add-on passes to DLSS as its bias current colour mask on all three transports (D3D11, native D3D12, Vulkan). Debug views show the mask and which test fired.

Diagnostics — the overlay page states the provider mode, the provider found and its state, and every mismatch in red: shader compiled for one provider while another is enabled; provider installed but disabled; provider failed to compile (read from ReShade's log). An MV probe samples the vectors actually handed to DLSS every 600 frames and logs mean/max magnitude and the non-zero share, so "is DLSS getting anything?" has an objective answer.

Experimental, off by default: geometry vectors. The shader can fit a per-frame camera model from the provider's flow + depth (robust least squares over a sparse grid) and derive every static pixel's vector from geometry instead of pixels, consulting the provider only for moving objects. It works in principle and kills the flame/flicker warping by construction, but the fit is still noisy frame to frame and the HUD — which is not part of the 3D world — gets camera vectors it should not have. Left in for people who want to try it (Use geometry vectors), with three debug views; not recommended yet.

Unchanged from 0.5.2: the in-process Vulkan vkCreateDevice hook (no launcher needed), the layer as fallback, 32-bit/D3D9 paths. The 32-bit add-on reads the same shader but does not pass the mask to the host yet.

Downloads — 64-bit games: dlss5-feed.addon64 + DLSS5_Feed.fx. 32-bit (and D3D9) games: dlss5-feed.addon32 + DLSS5_Feed.fx + dlss5-feed-host64.exe. Vulkan games missing the interop extensions: feed-vk-layer.zip (fallback only).

DLSS5-Feeder v0.5.2 - Vulkan works without the launcher

Vulkan games now work with no launcher, no bat, and no extra download.

The layer is no longer part of the happy path

The Vulkan transport imports the feeder's D3D12 fences and textures into the game's own VkDevice. That needs the KHR external-interop extensions plus the timelineSemaphore feature, and Vulkan fixes all of them at vkCreateDevice. v0.5.1 shipped VK_LAYER_feed_vk and a launcher bat for this, on the stated premise that nothing in-process could add them after the fact.

That premise was wrong about when the add-on is loaded. ReShade's Vulkan layer calls load_addons() inside its own vkCreateInstance hook and fires create_device from there — before the game ever calls vkCreateDevice. So the add-on now hooks vulkan-1.dll's exported vkCreateDevice itself and appends whichever of the extensions the driver supports, switching timelineSemaphore on. The loader hands out 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.

If the driver refuses the extended list, the call is retried with the app's untouched create info — the hook can never be the reason a game refuses to start. dlss5-feed.log names every extension and where it came from.

For Vulkan games this means: just install the add-on like a 64-bit D3D11/D3D12 game. feed-vk-layer.zip remains as the out-of-process fallback for the case where the hook cannot run, and the log says which case you are in.

DOOM (2016) needed this too

Worth correcting the v0.5.1 notes, which listed DOOM as "all present — nothing to do". Its own vkCreateDevice asks for 2 extensions and the hook adds 7. v0.5.1 only worked there because ReShade's device hook happens to add external_memory_win32 and timeline_semaphore below us. The interop gap was never a Tekken 3 Recomp special case — it is the normal state of affairs, which is why this belongs in the add-on rather than in a component you have to know to download.

Fixed: the per-extension log lines were lying

Present in the v0.5.1 layer as well. The "did the app already ask for this?" test ran against the vector being appended to, so by the time the per-extension lines were written, every extension just added reported as (app) instead of ADDED — on exactly the lines you read when diagnosing a failure. It now tests against the original VkDeviceCreateInfo. Behaviour was always correct; only the log was wrong. Both the add-on and the layer are fixed.

Notes

• MinHook (BSD-2-Clause, Tsuda Kageyu) is now vendored under external/minhook and built into the add-on; build.bat handles it.
• The hook is removed on DLL unload — ReShade refcounts add-on loading per Vulkan instance, so a game that creates a probe instance, destroys it, then creates the real one reloads the add-on in between.
• D3D11, D3D12 and 32-bit paths are unchanged; the hook only arms on a Vulkan create_device.

Downloads — 64-bit games: dlss5-feed.addon64 + DLSS5_Feed.fx. 32-bit (and D3D9) games: dlss5-feed.addon32 + DLSS5_Feed.fx + dlss5-feed-host64.exe. Vulkan games: same as 64-bit; add feed-vk-layer.zip only if the log tells you to. Full steps in the README.

DLSS5-Feeder v0.5.0 - Vulkan support, no third-party shader code

⚠️ iMMERSE LaunchPad is no longer required or supported

DLSS5_Feed.fx no longer #includes or calls into LaunchPad — that requirement is gone. The
shader now reads exactly one interface, the community-standard texMotionVectors texture, so any
provider that writes it works. Use ReshadeMotionEstimation
by Jakob Wapenhensch (CC BY-NC 4.0) instead — enable its DRME technique above
DLSS 5 Feed in the effect list, same as LaunchPad was placed before. qUINT_motionvectors and
other texMotionVectors providers work too.

If you're updating an existing install: remove MartysMods_LAUNCHPAD.fx and the MartysMods\
folder (no longer read), install ReshadeMotionEstimation instead, and swap which technique is
enabled above DLSS 5 Feed. DLSS5_Feed.fx itself must be replaced with this release's copy.

Every earlier release's DLSS5_Feed.fx asset has also been updated in place to this LaunchPad-free
version.

---

Vulkan support — DLSS 5 neural rendering now reaches Vulkan games (proven in DOOM 2016). The DLSS 5 add-on only hooks D3D12, so the evaluate still runs on a private D3D12 device; the transport imports the shared D3D12 fences/textures into the game's Vulkan device with raw external-memory/semaphore calls, then wraps them back into ReShade's own fence handles so queue signal/wait stay inside ReShade's locks. No system-wide Vulkan layer needed.

Stability

• Fixed a hang on quitting Vulkan/D3D12 games: NGX calls after the game's device starts tearing down (which the DLSS 5 add-on also does at that moment) could throw on a foreign thread and wedge the exit. The add-on now never calls back into NGX once the device or process is dying.
• Detects the installed renodx-dlss5.addon64 version: newer ("v45+") builds rescan every present and adopt missed features lazily, so the warm-up re-create is skipped automatically, and EnableHooks=2 (NGX-only) is written if unset.
• New preset config key: a DLSS render-preset hint (E/F legacy CNN presets clamp history harder; J/K are the transformer presets) — useful against warping around transparents like dust or flames.

32-bit games: tune the DLSS 5 host's neural-rendering settings directly from the game's own ReShade panel (a new "DLSS 5 host settings" group in DLSS5_Feed.fx) — no more switching to the separate helper window for routine tuning.

Full install steps, per-API details and troubleshooting are in the README.