A fix-only beta on top of 0.12.0. Three of the four fixes need testing by the people who reported them — the games involved are not available here.
32-bit games: take both dlss5-feed.addon32 and host64\dlss5-feed-host64.exe. The helper protocol is unchanged (still v7), so unlike the last few releases mixed halves will start without complaining — but two of these fixes live half in each binary and simply will not be there if you update only one side.
1. Feature-level 10 D3D11 games — the fallback that did not fall back (#43, #33)
0.11.0-beta.2 added a route for game devices that cannot create the shared textures: the helper creates them and keeps the DLSS output's UAV on its own side. It ran, and the game still could not open the result:
[feed32] the game's D3D11 device (feature level 10_0) refused the shared Output texture;
the host will create the shared set instead...
[feed32] OpenSharedResource1(tex 1) failed 0x80070057
Slot 1 is the DLSS output. Slot 0 is the colour input — same size, same format, and it opened. The difference was the resource flags: the code that drops the output's UAV on this route also dropped its render-target flag, so it was the only texture in the set born with no bind capability at all. Colour, depth and motion each carried ALLOW_RENDER_TARGET, and each opened. It now gets one too (the cast panel had the same hole). The game only ever creates an SRV on that texture, so the extra bind is unused and free.
This is reasoned from @PartyBreakerTF2's log, not reproduced — there is no feature-level 10 device here. So the diagnostics were widened to make the next report decisive either way: the helper now logs the exact D3D12 flags of every shared texture it creates, and the game reports every slot that fails to open instead of stopping at the first.
Needs testing: NFS Most Wanted 2012, and any other Frostbite 2 title.
2. Neural rendering toggling on and off under DXVK (#15)
@skoriandlp-arch on WoW 3.3.5a: with the default pipelined handoff the neural pass flickered on and off frame by frame on both Deep Fried Chicken and RenoDX, with the frame rate swinging between 72, 50 and 40; async_home=0 was rock solid at a flat 72.
The neural consumer keys its per-frame state to Present. The helper presents once per evaluate, and since 0.11.0-beta.2 it skips that present rather than blocking when the compositor is holding every back buffer. Skipping was the right call — blocking was the rigid 33.5 ms plateau from earlier in this same issue — but each skip makes two evaluates share one frame of the consumer's state, and the consumer answers by declining a pass. With a two-buffer swapchain at frame latency 1 the waitable object frees at most once per vblank, so above the desktop's refresh rate one present per evaluate was not merely unlikely, it was impossible: a 72 fps game on a 60 Hz desktop had to drop roughly one in six.
The helper's swapchain now has three buffers at latency 2, and a present it cannot make on the spot becomes a debt retired from its idle time — while it is blocked waiting for the game's next frame message, where a present costs the game nothing. It still never blocks anywhere, and it only does this when the game tells it the handoff is pipelined (a new client_flags bit; no protocol version change). async_home=0 behaves exactly as before.
Needs testing: WoW 3.3.5a and any 32-bit DXVK title, at the default async_home=1. dlss5-feed-host.log now reports skipped presents as a fraction of per-evaluate presents — that ratio is the measurement that confirms or kills this.
3. The feed stopping with nothing in the log (#40, and #1 on 32-bit)
Two separate holes with one symptom.
A game can run several ReShade effect runtimes. If the one the add-on is bound to has its DLSS5_Feed handle changed underneath it — an effect reload that ReShade does not report for that runtime — every render was dropped from then on, silently, until a swapchain re-init. Which is exactly why @HarmoniWay found that alt-tabbing out and back restored it. The handle is now re-checked from the render path, at most once a second, and the log says when it changes.
Separately: the 32-bit add-on was still choosing its runtime by "whichever initialised last" — the rule the 64-bit add-on replaced in 0.11.0-beta.2 for #1. So every 32-bit D3D11 game running with NVIDIA Smooth Motion has had the original #1 failure all along: a healthy-looking log and no neural rendering, because Smooth Motion's proxy swapchain gets its own runtime with its own preset. It now binds to the runtime that actually renders DLSS5_Feed, like the 64-bit side, and logs each runtime with its device and window class.
Needs testing: Atelier Sophie 2 (#40), and any 32-bit D3D11 game with Smooth Motion on.
4. Crash logs say what was touched (#44)
An access violation now records whether it was a read, a write or an execute, and at what address:
### CRASH RECORDED ### exception 0xC0000005 (reading address 0x00000000) at 00C5ED39 in ...
That line separates "the game dereferenced null" from "this add-on ran off the end of something" without anyone having to open the minidump — which is what @Daniel9132's Bayonetta dump had to be opened by hand to establish.
Also in this build
- The 32-bit add-on logs its whole configuration rather than a selection of it.
async_homein particular was missing, and it decides the entire handoff contract — no DXVK report could be triaged without asking the reporter what they had set. - New 32-bit cfg key, parse-only and deliberately not on the overlay:
host_creates=1forces the helper-creates-the-textures route on a device that does not need it. It exists so fix 1 can be exercised without a feature-level 10 game.
Tomb Raider 2013 (#38)
Not fixed here, but worth a retest on this build. The flickering reported against versions after 0.10.0-beta.2 is most likely the motion-vector validation added in 0.12.0, whose per-pixel static test could flip between frames; 0.12.0 already gave that test a one-frame memory. If it still flickers, set MV_VALIDATE to 0 in the DLSS5_Feed.fx preprocessor definitions and say so on the issue — that isolates it in one step.
Reporting
dlss5-feed.log and ReShade.log from the same run (plus host64\dlss5-feed-host.log and host64\ReShade.log for 32-bit games), and the output of Verify-DLSS5Feeder.ps1 run next to the game exe.