jlrouzies-fr/DLSS5-Feeder v0.6.0-beta.1

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

on GitHub

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).