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.4 and supersedes it. Built from branch beta/v0.9.0-beta.1.
dlss5-feed.log line 1 will say dlss5-feed 0.9.0-beta.1 so you can confirm which build you are on.
What changed since the 0.8.0 line: the two features that rode along unmerged through those betas — guide diagnostics (#18) and the OpenGL extension-string fix (#29) — are now merged into main. What is on trial in this beta is the Vulkan work and renodx v4.7 support.
1. Vulkan external-memory ownership transfers — new in 0.9.0
Any 64-bit Vulkan game. This changes the frame path every Vulkan user is on, and it is the least-proven thing in this zip.
The imported D3D12 images are VK_SHARING_MODE_EXCLUSIVE. The Vulkan external-memory model is explicit that ownership must be released to VK_QUEUE_FAMILY_EXTERNAL before the other API writes and re-acquired afterwards, or each side can keep reading its own cached view. The feeder never performed those transfers. It now does, on both the 64-bit and 32-bit-DXVK paths, and tracks the game's graphics queue family from vkCreateDevice in order to.
Also new: the output can be routed home through an imported D3D12 shared buffer rather than the image. At least one driver/format pair never propagated D3D12 image writes into the imported VkImage's view; a buffer carries no opaque tiling or compression metadata that can fall out of sync.
Please report Vulkan results either way. If a Vulkan game worked in 0.8.0-beta.4 and does not here, say so loudly — that is the regression this beta is looking for.
2. DLSS 5 add-on v4.7 support — #27
v4.7 keeps the v4.5+/v4.6 engine and reworks its own colour path: the Control-style soft-clip/paper-white codec is replaced by a reversible bridge that picks SDR sRGB, linear HDR BT.709 or PQ BT.2020 from the contract it is handed, with a diffuse-white-in-nits control, a new global-tone strength and a fenced D3D12 workset pool. Everything it decides on — the IsHDR create flag and the colour format — is already in what this feeder publishes, so the contract itself needed no change.
The v4.55 pin is gone. The README now says which add-on to install — Krish's renodx-dlss5 from the #DLSS5 channel, not ShortFuse's renodx-dlss, which builds the contract itself and replaces this feeder rather than working with it — and tables what the feeder does about each generation.
Two detection bugs fixed on the way: the old raw 11-byte marker match would also match EnableHooks inside an unrelated message, so any build carrying that string read as v4.5+; and the version resource cannot separate v4.6 from v4.7 (both report 0.2026.0828.0517), so the add-on's own v4.6/v4.7 banner is read instead, falling back to the resource for older builds.
No game row has verified a v4.6 or v4.7 run end to end yet — the compatibility work is static. Report runs in #27.
3. OpenGL: capped extension strings — PR #29, by @imminaa — now merged
NVIDIA's per-application profiles cap the extension string reported to old engines: id Tech 3 and its descendants copy glGetString(GL_EXTENSIONS) into a fixed 4 KB buffer, so the driver truncates what it advertises and GL_EXT_memory_object falls off the end. Affected users were told the interop was missing on hardware that plainly has it, and sent to hybrid-laptop advice that is a dead end on a desktop card.
An unadvertised extension is now a question rather than a verdict: the feeder creates a real memory object and a real semaphore, and only a probe that also fails counts as absence. A wrong-GPU hybrid laptop still fails, with the same message as before. dlss5-feed.log now always carries an extension query: line reporting how both enumerations behaved — quote it in any OpenGL report.
4. Guide diagnostics + one-pass guides — PR #18, by @rubicoul — now merged
Unchanged from the 0.8.0 betas. 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. Use the DLSS5_Feed.fx from this zip.
5. NVIDIA Smooth Motion — #1, #10
Unchanged from beta.4, and still one data point (Metro 2033 Redux, D3D11) with none at all on Vulkan. The full explanation is in the beta.4 notes and applies here verbatim.
6. 32-bit Vulkan / DXVK — #15
Still unproven in a real game. Now also carries the ownership transfers from item 1.
Known not working: Detroit: Become Human (Demo), 64-bit Vulkan
DLSS runs and frames are delivered, but the displayed image freezes on stale content far longer than a one-frame lag explains. Eight deploy-and-play cycles ruled out DLSS/NGX itself, renodx's NR pass, the HDR/format detection, image-import coherence and queue-family ownership — including a passthrough test that swaps the whole evaluate for a plain byte copy and still reproduces it — without reaching the cause. The ownership transfers in item 1 came out of that hunt and did not fix it. Leading open theory: a minImageCount=3 swapchain-image desync rather than a transport ordering bug.
enabled=0 in dlss5-feed.cfg is the recommended setting for this title. The full investigation and what to try next is in PLAN-DETROIT.md.
Upgrading
From any 0.8.0 beta: nothing to do beyond replacing the files. The game↔helper pipe protocol is still v3, so 0.8.0-beta.1 through 0.9.0-beta.1 are all protocol-compatible.
From 0.7.0, 32-bit games only: the 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 refuses to run and says so in the log. 64-bit games are unaffected.
Reporting
Vulkan, any 64-bit title → a new issue, saying it is 0.9.0-beta.1 · Smooth Motion on D3D11/D3D12 → #1 · Smooth Motion on Vulkan → #10 · DLSS 5 add-on v4.6/v4.7 → #27 · 32-bit Vulkan → #15 · anything else → a new issue.
Worth including: game, resolution, API, the MV probe / Depth probe lines from dlss5-feed.log, the extension query: line on OpenGL, and for Smooth Motion runs the fed from thread lines. For 32-bit games also host64\dlss5-feed-host.log and host64\ReShade.log.