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_SECTIONis recursive, so a lock alone would let a re-entrantPresenton the same thread walk into a half-built frame. - turns on
ID3D11Multithreadprotection 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 Mis the smoking gun for this class of report, andre-entrant frame … droppedis 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 toGetBuffer(); 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.addonor 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; setNRStyle=0inReShade.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