v0.2.0

The bridge as a ReShade add-on (v0.2 line, prerelease)

dlss5-vk-bridge.addon64 is the same bridge as v0.1.14, hosted by ReShade instead of the Vulkan loader. Drop it next to the DLSS 5 add-on it feeds and ReShade loads both: no registry entry, no ENABLE_DLSS5_VK_BRIDGE, no Steam restart, and no other Vulkan process on the machine ever sees the bridge. ReShade 6.6 or newer with add-on support is required (the add-on targets add-on API 18).

What is different under the hood, and why it matters for testing:

• ReShade's events replace the layer's hooks: the device, every queue with its capabilities, and every command buffer as it begins, executes secondaries and is submitted. The NGX hooks, the private D3D12 session and the per-frame sandwich are unchanged.
• ReShade reports a submit before it goes down, so the add-on queues nothing behind the game's work; a frame slot retires through the event at the tail of its own sandwich. Only the in-frame handoff (sync = 1, the mode that makes the result visible) exists in this host; sync = 0 is ignored with a log line.
• An add-on has no instance or physical device it may use. Memory properties are read once through a private, one-call VkInstance created with every implicit layer disabled (you will see it in a loader log as a second instance created from the render thread), and each shared-texture import also asks the driver which memory types the handle allows.
• The add-on stands down, with a log line, if the layer build is loaded in the same process or a second copy of itself is. [DLSS5_VK_BRIDGE] in ReShade.ini overrides dlss5-vk-bridge.cfg key by key.

This host has not been run in a game yet. It compiles, the code has been read against ReShade 6.8's Vulkan hooks, and it ships now so people who already run the RenoDX setup can try it without touching the registry. If you try it: uninstall the layer first (see the README), then attach dlss5-vk-bridge.log (next to the .addon64) and ReShade.log to an issue, working or not. The layer build in this release is functionally the v0.1.14 layer and stays the field-verified reference; v0.1.14 remains the full release.

Files

• dlss5-vk-bridge-0.2.0-addon.zip: dlss5-vk-bridge.addon64 (the ReShade add-on host)
• dlss5-vk-bridge-0.2.0-layer.zip: dlss5-vk-bridge.dll + dlss5-vk-bridge.json (the Vulkan layer host, unchanged behaviour)

SHA-256

544f0e3f9317c7c62136ae34b59adb13ad18a1f43c138104f329b5deba186a04  dlss5-vk-bridge.addon64
40b767624f763b419ef73676efe177dda0492bdb2a7f5319225e170b51ef7317  dlss5-vk-bridge.dll
9d3f5e480c178331bca4f928568e5d1dea4fe84bcbbacbe019fe8a5adfd0d7f6  dlss5-vk-bridge.json

v0.1.14

No blit before the queue family is known (issue #3)

loroid's v0.1.13 retest of Indiana Jones and the Great Circle still froze after the first bridged frame, and the log shows why. The first sandwich is recorded before any submit has been seen, so the queue-family guard added in v0.1.13 could not engage yet -- and that frame carried a vkCmdBlitImage (the game's RGBA16F motion vectors into the bridge's fixed RG16F alias). idTech 8 runs its DLSS pass on a compute-only family (queue flags 0xE), where a blit is not a legal command. The original v0.1.12 log already showed the GPU never reaching the event set right behind that blit.

• The motion-vector alias now mirrors the game's format for RG16F, RG32F, RGBA16F and RGBA32F, so the input is a plain vkCmdCopyImage (DLSS reads .xy). Only an unlisted format still falls back to a blit into RG16F; the rebuild log names any format that needs one.
• Which family runs the DLSS pass is learned from the very first evaluate's own submit, during the 3-second Frame Generation grace, with nothing recorded into that command buffer. A frame that would need a blit while the family is still unknown re-arms that probe and goes out untouched instead of recording one.
• The async path's first-frame log line now says the work is queued, not done.

Field-verified: loroid's retest on Indiana Jones and the Great Circle (RTX 5080, driver 616.56, 1080p to 4K) learned the family before the first frame was touched, bridged 100 frames with none skipped, and the add-on's neural-rendering pass evaluated inline on every bridged frame. This is the first full release; earlier versions stay prereleases.

SHA-256

366818cb86d85ee50639ca60664a3a9c64be8b97dca88fbfa949d5eb68ae86be  dlss5-vk-bridge.dll
9d3f5e480c178331bca4f928568e5d1dea4fe84bcbbacbe019fe8a5adfd0d7f6  dlss5-vk-bridge.json

v0.1.13 — submit matching, non-blocking frame path (idTech 8 / issue #3)

Pre-release, like every release so far. Fixes the freeze after the first bridged frames in Indiana Jones and the Great Circle (idTech 8) reported in #3, and hardens the frame path for any engine that records and submits its DLSS pass from another thread or another queue family.

What was wrong

The bridge assumed the first vkQueueSubmit after the DLSS evaluate hook carries the command buffer it had recorded into. idTech 8 records and submits its DLSS pass from another thread, on the async-compute queue family, with unrelated submits in between. The worker was armed by the wrong submit and timed out, and the hook's blocking waits then ran against a sandwich that had not executed yet, leaving the GPU parked for good.

Changes

• vkQueueSubmit / vkQueueSubmit2 now match every submit against the command buffers the bridge has work in (following vkCmdExecuteCommands when the pass lives in a secondary). Only a match gets the bridge's fence queued behind it; other submits are only counted.
• The sync worker is armed when the sandwich is recorded, from a recording-order queue. A third VkEvent after the copy-back tells the bridge when a slot has retired, so no submit has to be seen at all. Re-recording a command buffer the bridge had work in releases its slot as discarded.
• The frame path never waits on the GPU or the worker any more: no free slot, or a rebuild while work is in flight, forwards that frame untouched. Resources are rebuilt only when nothing is in flight.
• Per-frame NGX scalars (jitter, sharpness, exposure, subrects, reset) are captured at record time, so a pipelined frame keeps its own values.
• Depth reported with a wrong aspect (idTech: COLOR on D24_UNORM_S8_UINT) is derived from the format and sampled through a bridge-made depth-only view, so DLSS gets depth in this game.
• Blits are refused on a queue family without graphics; the log now names the family the DLSS pass is submitted on, with its flags.

Log lines to look for

• the DLSS command buffer is submitted on queue family N (...)
• first frame bridged: in-frame sandwich armed
• first D3D12 evaluate completed inside the game's frame
• depth format 129 (aspect 0x2) fed through the compute conversion pass via a bridge-made depth-only view

Default dlss5-vk-bridge.cfg (sync = 1, mode = 0, game_eval = 1) is the configuration to test with.

SHA-256

868751b4d0f9ec7e6d741df37c31be21530450bd3e2ca2d19f7779909aee1958  dlss5-vk-bridge.dll
9d3f5e480c178331bca4f928568e5d1dea4fe84bcbbacbe019fe8a5adfd0d7f6  dlss5-vk-bridge.json

v0.1.12 — transient faults survive; FG refusal, standard shape

The v0.1.11 forensics answered on their first field log (#1). Both findings shipped here.

The "add-on stuck on STANDBY until relaunch" one-off: solved, and survivable

The fault behind it is not in the bridge and not in NGX — it is inside ReShade itself:

[hook]   audit: every hooked entry point is loaded and in the expected state; the fault is not a patch-integrity problem
[hook] forwarded NGX Vulkan evaluate raised 0xC0000005
[hook]   fault site: ReShade64.dll+0x1EAF11 (00007FFCA867AF11)
[hook]   access violation: reading address 0000000000000440

A neighbouring interposer having a transient (a null object read at +0x440) during a forwarded evaluate — with the game demonstrably rendering on fine after the containment, twice on record. Standing the bridge down for the whole session over that cost the add-on the session. Now the first contained fault only pauses bridged frames for 5 seconds and resumes — forwarding runs untouched throughout, and the game_eval=0 skip is gated off for the duration. A second fault stands the bridge down for the session, as before. "Relaunch to fix" becomes "wait five seconds".

The mid-game FG switch, round two

v0.1.11's refusal fired exactly as designed — and X4 crashed anyway: its own Frame Generation enable path does not survive being told no. This release fails the create in the most standard way NGX has (FeatureNotSupported instead of the generic failure code, the returned handle nulled) in case the error routing is code-sensitive. Worth one retest; expectations moderate. If it still crashes, the rule is simply that FG is a launch-time choice, never a mid-game one — the game's own error path can't do better, bridge or no bridge.

And for clarity, since it came up in the thread: FG and the DLSS 5 add-on can never run at the same time. FG on at launch = normal FG, add-on inactive, for that whole session — by design, not a bug.

No install changes: replace dlss5-vk-bridge.dll, keep the registry registration from the README.

Contents

dlss5-vk-bridge-0.1.12.zip — the layer DLL + manifest (keep them in the same folder):

file	sha256
dlss5-vk-bridge.dll	c1bef7753e39b96a8803024fe47d3f734c3240b2155fe1ba356fc101cd50c685
dlss5-vk-bridge.json	9d3f5e480c178331bca4f928568e5d1dea4fe84bcbbacbe019fe8a5adfd0d7f6

Built by CI on windows-latest (MSVC, x64) from this tag.

v0.1.11 — mid-game FG switch refused, fault forensics

Two changes, both born from the X4: Foundations thread (#1).

The mid-game FG switch: refused instead of crashed

Flipping Frame Generation ON from the menu while the bridge is active crashed the game — twice in the #1 logs, after 3000 and 2000 bridged frames. FG pairs every present with that frame's DLSS evaluate; a session history full of bridged frames is something its bookkeeping cannot absorb, and standing aside at that moment only protects the frames that haven't happened yet.

v0.1.11 refuses that create outright: the FG feature never comes into existence, nothing crashes, and the bridge keeps working. The log states the refusal and why; FG waits for the next launch. Launching with FG enabled is unchanged — there the create lands before the bridge has touched a single frame, and the bridge stands aside for the whole session.

The per-launch choice stays, minus the crash:

• FG off at launch → DLSS 5 add-on active all session; a mid-game FG flip now just logs a refusal.
• FG on at launch → normal FG, bridge inactive.

Fault forensics

One v0.1.10 launch had a forwarded evaluate raise 0xC0000005 (~a second in; gone after relaunch) — and the log recorded only the exception code, which pins nothing. Every contained fault now logs:

• the faulting instruction's module+offset — or a callout that it lies in no loaded module (which alone convicts a jump into freed code),
• what the access violation was reading/writing/executing and at what address,
• an audit of every hooked NGX entry point, taken before the lifted patches go back on: is each module still loaded, are the entry bytes in the expected state — the tripwire for another interposer rewriting the same exports.

If that one-off ever returns, one log pins it.

No install changes: replace dlss5-vk-bridge.dll, keep the registry registration from the README.

Contents

dlss5-vk-bridge-0.1.11.zip — the layer DLL + manifest (keep them in the same folder):

file	sha256
dlss5-vk-bridge.dll	11fe6a68245447a035a523b6e81d2e73fe64d3dce01dc7fd33c85fdf7cec510c
dlss5-vk-bridge.json	9d3f5e480c178331bca4f928568e5d1dea4fe84bcbbacbe019fe8a5adfd0d7f6

Built by CI on windows-latest (MSVC, x64) from this tag.

v0.1.10 — wait out the DLSS bring-up burst

v0.1.9's Frame Generation stand-aside lost its race by 7 milliseconds. The X4: Foundations retest (#1) caught it on camera, and this release closes the window for good.

What the retest showed

The reporter's experiment — launch with DLSS off, enable it from the menu — produced the perfect trace. The game brings its DLSS features up in a burst: SuperSampling is created first, evaluates start flowing immediately, and the FrameGeneration feature is created a few milliseconds later. The v0.1.9 log shows the whole thing:

[21:18:56.537] [bridge] first frame bridged: in-frame sandwich armed
[21:18:56.544] [bridge] the game is creating an NGX Frame Generation feature (DLSS-G). The bridge stands aside ...
[21:18:56.545] [bridge] first D3D12 evaluate completed inside the game's frame

The latch worked — 7 ms after the bridge had already armed on the burst's first evaluate and touched a frame. The minidump confirms the consequence is byte-for-byte the v0.1.8 crash: the identical instruction in sl.dlss_g.dll (+0x3d320, null dereference in FG's present-time bookkeeping) at FG's next present. One touched frame is all it takes.

Changed

• The first bridgeable evaluate now only starts a clock. For 3 seconds (a 400x margin over the observed gap) every frame is forwarded untouched — no session, no shared resources, not a single recorded command. A FrameGeneration create landing anywhere in that grace means the bridge never touched a frame of the session. With FG off, bridging simply begins 3 seconds late, and the log says so.

One residual stays, documented in the README: enabling FG from the menu of a session that has already been bridging past the grace can still collide on the single transition frame — the latch protects every frame of the relaunch. That one can't be closed from outside FG.

For X4

• FG on (from boot or enabled in the menu): stable, bridge inactive, log explains.
• FG off: the bridge engages 3 s after DLSS starts evaluating. Whether that is stable — and whether the DLSS 5 add-on's output shows up — is the data point everything above was clearing the way for.

No install changes: replace dlss5-vk-bridge.dll, keep the registry registration from the README.

Contents

dlss5-vk-bridge-0.1.10.zip — the layer DLL + manifest (keep them in the same folder):

file	sha256
dlss5-vk-bridge.dll	e0a8536d28981ed93797899d5a9e662f2f9d26972b9da771af3d9e3f090da263
dlss5-vk-bridge.json	9d3f5e480c178331bca4f928568e5d1dea4fe84bcbbacbe019fe8a5adfd0d7f6

Built by CI on windows-latest (MSVC, x64) from this tag.

v0.1.9 — stand aside while DLSS Frame Generation is active

The X4: Foundations minidump (#1) moved the story forward: v0.1.8's fix worked — the layer loaded once, survived all three instances, and completed its first bridged evaluate inside the game's frame, further than X4 had ever gotten. The crash that followed was somewhere new, and this release deals with it.

What the minidump shows

The faulting instruction is not in the bridge. It is in sl.dlss_g.dll — Streamline's DLSS Frame Generation plugin (v2.7.30.0): a null dereference (0xC0000005 reading offset 0x28 of a null object) in FG's present-time bookkeeping, reached from the game's vkQueuePresentKHR through sl.interposer → sl.common → sl.dlss_g → the NVIDIA driver and back into sl.dlss_g. The bridge appears nowhere in the crashing stack — but the dump is timestamped the same second as the log's first D3D12 evaluate completed inside the game's frame. One bridged frame, then FG died at the next present.

That is not a coincidence. Frame Generation pairs every present with that frame's DLSS evaluate and interpolates at present time. The bridge breaks both halves of the pairing: it stalls the game's queue mid-submit (the sync sandwich) and runs a second, private DLSS evaluate in the same process every frame. FG's internal bookkeeping cannot be repaired from the outside.

Changed

• The bridge now stands aside whenever DLSS Frame Generation is active. It hooks NVSDK_NGX_VULKAN_CreateFeature/CreateFeature1 (observation only — every call is forwarded untouched) and latches the moment the game creates a FrameGeneration feature. That is the earliest reliable signal: it always happens before FG's first frame, so the latch is in place before the first frame the bridge would otherwise touch. (Module presence is not such a signal — Streamline preloads nvngx_dlssg.dll to probe support; both X4 logs show it resident before any VkInstance existed.) Latched, the bridge forwards everything and bridges nothing, and the log says exactly why. A launch with Frame Generation disabled in the game's settings bridges as before.
• The hook-forwarding contract grew up with the new class: forwarding an evaluate lifts only the evaluate patches, so a feature create landing mid-forward is still observed (it serialises on the same critical section); forwarding a create lifts every patch; both classes are depth-counted so nested forwards reinstall only at the outermost return. A create that faults reports failure to the game rather than success — success would hand it a garbage feature handle.

For X4 specifically

Two retests would settle it, in order of interest:

1. Frame Generation ON (as you play now): the game should no longer crash; the log will show the stand-aside line and the bridge will do nothing — with FG on, the DLSS 5 add-on will not affect X4 for now. FG coexistence is future work, and it needs exactly this kind of report to happen.
2. Frame Generation OFF (game restarted after the change): the bridge engages. Whether that is stable — and whether the add-on's output shows up — is the next data point. If it crashes with FG off, the dump will point at the next layer of the story; please send it.

No install changes: replace dlss5-vk-bridge.dll, keep the registry registration from the README.

Contents

dlss5-vk-bridge-0.1.9.zip — the layer DLL + manifest (keep them in the same folder):

file	sha256
dlss5-vk-bridge.dll	f4822e178749c82270c082df3be8b16ac947cc2bb4c238966b4efe1ad5931ef0
dlss5-vk-bridge.json	9d3f5e480c178331bca4f928568e5d1dea4fe84bcbbacbe019fe8a5adfd0d7f6

Built by CI on windows-latest (MSVC, x64) from this tag.

v0.1.8 — the real X4 fix: pin the layer against loader unload cycles

The real fix for the X4: Foundations crash (#1). The v0.1.7 diagnosis was incomplete — thanks to the retest log, the actual bug is now identified with certainty, and it was never about how the evaluate was forwarded.

Fixed

• The layer could be unloaded and reloaded mid-launch, poisoning its own hooks (X4: Foundations, #1). The retest log shows the bridge DLL loading three times in one launch: X4 creates and destroys several Vulkan instances back to back, and the Vulkan loader unloads implicit layers whenever the last instance is destroyed. Each unload left the bridge's 14-byte patches in the NGX modules jumping into a dead mapping; each reload landed at the same address and read its predecessor's still-installed jump back as the "original bytes" of the export. From then on, forwarding the game's evaluate "restores" a jump straight back into the bridge's own detour — infinite self-recursion, 0xC00000FD, in both X4 reports (the v0.1.6 log shows the same double-load tell). v0.1.7's lift-all-patches change couldn't help, because the saved "original" was the detour jump; the process died before the exception path could even write its log line, which is why the v0.1.7 log just stops.
  The fix is the one every patch-writing DLL needs: the bridge now pins itself in the process on first load, so the loader's unloads become no-ops and one load's patches, watcher thread and layer state outlive every instance the game creates. On top of that, if an evaluate entry is ever found already carrying one of the bridge's own jumps, it is refused rather than adopted as "original bytes", with a loud log line.
• vkQueueSubmit2KHR could fail a working submit (v0.1.7 regression). v0.1.7 started intercepting vkQueueSubmit2KHR but resolved the forward pointer only by its core name — legitimately null on devices where synchronization2 comes from the KHR extension rather than core Vulkan 1.3. The layer then answered a perfectly valid submit with VK_ERROR_FEATURE_NOT_PRESENT, before the game's first evaluate. The dispatch now falls back to the KHR name (and likewise vkWaitSemaphoresKHR for timeline waits), and vkGetDeviceProcAddr claims vkQueueSubmit2/KHR only when there is a real pointer to forward to.

No install changes: replace dlss5-vk-bridge.dll, keep the registry registration from the README. One visible difference: the log now shows a single loaded line per game launch instead of one per instance — that's the pin working.

If X4 still crashes with this build, the log alone may not be enough (the process can die faster than a line can be written) — please also attach the Windows Event Viewer entry (Windows Logs → Application, source Application Error: exception code and faulting module) along with dlss5-vk-bridge.log.

Contents

dlss5-vk-bridge-0.1.8.zip — the layer DLL + manifest (keep them in the same folder):

file	sha256
dlss5-vk-bridge.dll	780053e7cf2e6f0848ee27b441146ffc5745e2833384a70d566d0b50b9269451
dlss5-vk-bridge.json	9d3f5e480c178331bca4f928568e5d1dea4fe84bcbbacbe019fe8a5adfd0d7f6

Built by CI on windows-latest (MSVC, x64) from this tag.

Status: working on the verified titles; the X4 crash mechanism is now understood end to end and closed by construction. Retests very welcome.

v0.1.7 — field-report fixes: forwarding crash, Ray Reconstruction, launch safety

A bug-fix release for the first field reports from other titles. Three reports, three root causes found in source: the X4: Foundations crash (#1), Ray Reconstruction coming out noisy under RTX Remix, and No Man's Sky refusing to launch. Nothing about the verified happy path (RTX 5090 / Baldur's Gate 3 Vulkan) changes.

Fixed

• Crash while forwarding the game's evaluate (X4: Foundations, #1). The bridge patches every module exporting NVSDK_NGX_VULKAN_EvaluateFeature, but while forwarding a call it only lifted the patch on the module being called. The NGX modules forward into each other, so the call could re-enter a still-patched export and recurse until the stack overflowed (0xC00000FD — exactly the log's last line). Forwarding now lifts all patches for its duration. A caught stack overflow also restores the stack guard page (_resetstkoflw), and any exception raised by a forwarded evaluate now disables the bridge and removes every patch, so the game keeps rendering unbridged instead of going down.
• Ray Reconstruction mirrored as if it were super sampling (RTX Remix). DLSSD (Ray Reconstruction) evaluates travel through the same NGX entry point with the same Color/Depth/MV/Output resources, so the bridge mirrored them onto its private super-sampling feature — upscaling the still-noisy input and copying it over the game's denoised frame. That is the "noisy, as if denoising is off" report, verbatim. The bridge now recognises evaluates carrying denoiser inputs (DLSSD.*, normals/roughness/albedo/hit-distance keys) and stands aside: Ray Reconstruction renders exactly as it does without the bridge (it just is not bridged — see the README's limitations). The log names the key that identified the frame.
• A game failing to start with the layer registered (No Man's Sky, RTX 4090). No log to go by, but the layer had several ways to break a launch all on its own, and every one found is fixed: instance extensions were appended without checking the driver advertises them, and the timeline-semaphore feature struct was injected even when its extension is absent (either fails the create call outright); physical devices were queried through whichever instance was created last (undefined across instances — launchers and overlays create several); the dispatch tables only ever appended, so a throwaway probe device could fill them and the real device went untracked, after which vkQueueSubmit failed and vkGetDeviceQueue returned garbage. Slots are now recycled, untracked handles are forwarded down the chain instead of refused, vkQueueSubmit2KHR is intercepted, and — the safety net — a create call that still fails with the layer's additions is retried with the application's own arguments untouched, so the worst case is "launches, bridge inactive" rather than "won't launch".
• Clean quit: destroying the Vulkan device the bridge is attached to now tears the bridge down first instead of leaving imported memory and semaphores dangling.

The rule these fixes enforce is now stated in the README: an implicit layer is loaded into every Vulkan process on the machine and must never be the reason one of them fails to start. If a game still won't start, setx ENABLE_DLSS5_VK_BRIDGE 0 (and a full Steam restart) turns the layer off without uninstalling — please open an issue with the log.

No install changes: replace dlss5-vk-bridge.dll, keep the registry registration from the README. The config file is unchanged.

Contents

dlss5-vk-bridge-0.1.7.zip — the layer DLL + manifest (keep them in the same folder):

file	sha256
dlss5-vk-bridge.dll	cc2a5ab635dd7def0133f4fe6c3b9f2a21fb83c8ca30443a1984514e1d295ea3
dlss5-vk-bridge.json	9d3f5e480c178331bca4f928568e5d1dea4fe84bcbbacbe019fe8a5adfd0d7f6

Built by CI on windows-latest (MSVC, x64) from this tag.

Status: working, hardened. Retest reports for X4, RTX Remix RR, and No Man's Sky are very welcome — with dlss5-vk-bridge.log if anything still misbehaves.

v0.1.6 — opt-in single-evaluate mode, politer worker

v0.1.5 was confirmed working on hardware (RTX 5090, driver 610.74, Baldur's Gate 3 Vulkan): the DLSS 5 add-on detours the bridge's private D3D12 evaluate and the neural result is visible in-game, ~135 fps sustained. This release banks that win — one opt-in performance option, a politer worker, and documentation that describes the verified design. Default behaviour is identical to v0.1.5.

Added

• game_eval = 0 (config; default 1 = unchanged). In steady state the in-frame sandwich overwrites the game's DLSS output before anything reads it — so the game's own Vulkan evaluate is a second full DLSS pass for pixels nobody ever sees. Setting game_eval = 0 skips it while the bridge is provably healthy, recovering most of the bridge's frame cost. The gate closes on any wobble (a failed or timed-out worker frame, a resolution change gone wrong), and the real evaluate is forwarded again on the very next frame; worst case is a single frame repeating the previous bridged result. Try it once the log shows clean heartbeats.

Changed

• The sync worker's input poll (there is no host-blocking wait on a VkEvent) now backs off in stages — pause-spin through the expected sub-frame wait, yield when it drags, sleep once clearly stalled — instead of hammering SwitchToThread for up to a second. Healthy frames keep their latency; pathological frames stop burning a core.
• README and header comments now describe the in-frame sandwich as the design (with the hardware verification recorded) rather than the asynchronous copy-back it replaced in v0.1.5.

No install changes: replace dlss5-vk-bridge.dll, keep the registry registration from the README. An existing dlss5-vk-bridge.cfg lacks the game_eval key; the default (1) applies automatically.

Contents

dlss5-vk-bridge-0.1.6.zip — the layer DLL + manifest (keep them in the same folder):

file	sha256
dlss5-vk-bridge.dll	4ef12e3b9d5f9d0508432275ae67fbea0c8081420ae975767c4961cbd8ceb13f
dlss5-vk-bridge.json	9d3f5e480c178331bca4f928568e5d1dea4fe84bcbbacbe019fe8a5adfd0d7f6

Built by CI on windows-latest (MSVC, x64) from this tag.

Status: working. Defaults behave exactly like the hardware-confirmed v0.1.5; game_eval = 0 is the one new switch and it is opt-in.