Lossless Scaling bridge v0.3.0-pre.2 initializes DLSS-NR v0.2.18 on RX 9060 XT but never submits a HIP job

[Nikbis]

dlss5-amd-swapper-issue-2026-09-17.zip

Summary

The Lossless Scaling route captures the selected source, creates its D3D12 swapchain on the intended Radeon, loads DLSS-NR-on-AMD v0.2.18, matches HIP to that same GPU, and reports engine init ok. However, it never completes a neural network job and the HIP timing log contains no API-call rows. After about 67 seconds the bridge exits safely without publishing its ready file.

This is reproducible with both a game and a controlled animated browser page, so it does not appear to be specific to the game or to selecting the wrong source window.

Environment

• Windows 11 x64, build 26100
• Lossless Scaling 3.2.1
• DLSS5 AMD Swapper release v0.3.0-pre.2
• Bridge log schema reports bridge_version=0.3.0-pre.2
• DLSS-NR-on-AMD v0.2.18, build b7e0bab9
• AMD driver 32.0.31035.1003
• Display/capture GPU and selected HIP device: Radeon RX 9060 XT 16 GB, gfx1200, 16 CUs
• Second installed GPU: Radeon RX 9070 XT 16 GB, gfx1201, 32 CUs
• HIP_VISIBLE_DEVICES=0; the runtime sees only the RX 9060 XT and explicitly reports that it matches the bridge D3D12 adapter
• Neural branch capped at 480 pixels high; native visible output retained
• User-supplied nvngx_dlssnr.dll build 310.8.0.0

Steps to reproduce

1. Install the v0.3.0-pre.2 Lossless Scaling bridge from the manager.

2. Select the RX 9060 XT with HIP device index 0.

3. Keep the stock asynchronous Lossless Scaling runtime configuration:

   [DlssNrOnAmd]
   Enabled=1
   UseFsrInputs=0
   Inline=0
   Scale=0.03125
   LocalStructure=1
   LocalTone=1
   SkinStructure=1

4. Open an animated browser page and press Scale in Lossless Scaling.

5. Wait for the bridge readiness check.

Expected result

The runtime completes at least one neural job, the bridge publishes its ready file, and processed output becomes available.

Actual result

The runtime reaches:

env: swapchain 912x480 format 28, 2 buffers, swap effect 4, windowed
env: adapter 0: AMD Radeon RX 9060 XT (...)
env: HIP device 0: AMD Radeon RX 9060 XT, arch gfx1200, 16 CUs, 16304 MB  <- the adapter the game renders on
env: using HIP device 0 (matches the game's D3D12 adapter): AMD Radeon RX 9060 XT, arch gfx1200, 16 CUs, 16304 MB
engine init ok

No later neural-job line appears. The HIP timing file contains only its headers, with no call rows. The bridge then reports:

DLSS-NR runtime did not become healthy before visible output: runtime log has no completed network job yet

The auto-scale log records that the child exited before publishing its ready file and deactivates original scaling.

Control tests already performed

• Reproduced with DLSS-NR-on-AMD v0.2.17 and v0.2.18.
• Reproduced with the stock async color-only configuration (Inline=0).
• Reproduced with an explicit diagnostic color-only profile using UseDepth=0, Temporal=0, Interop=1, and Inline=1.
• Reproduced while the source remained in the foreground.
• Reproduced with a controlled animated browser source. Its captured neural dimensions changed to 912x480, while the game test used 854x480, confirming that the selected source was actually captured.
• The RX 9060 XT is both the D3D12 adapter and the only HIP-visible device in the primary tests, so there is no logged adapter mismatch.
• The extracted model contained all 153 expected tensors, and the generated weights file was stable across the tests.

Attached text evidence

• latest-runtime-sanitized.log
• latest-hip-timing-sanitized.log
• auto-scale-final-run-sanitized.log
• bridge-error-sanitized.txt
• environment-and-hashes.md

No proprietary DLL, generated weights, paid Lossless Scaling file, private manifest, or machine-specific path is attached.

Question

Could this be a stalled handoff between DlssNrBridge.exe and the compatibility runtime after engine initialization? Is there an additional bridge diagnostic that would show why no neural work reaches HIP, or a newer bridge build that should be tested specifically with runtime v0.2.18?

[eikkapine]

Thanks for the detailed reproduction and sanitized logs. They confirm that initialization succeeds on the selected adapter, but they do not yet identify why that runtime stops before a completed neural job.

I published v0.3.0-pre.3, with these changes relevant to this report:

• Fixed missing startup timing evidence: the old bridge only flushed buffered HIP timing after readiness. A failed startup could therefore leave a header-only file even if HIP calls occurred. The bridge now drains those samples during startup and on exit.
• Added bridge-startup.log: it records capture/Present counts, Present HRESULT and occlusion, feed visibility, engine/job state and HIP wait progress, so we can distinguish submission, hooking and runtime-wait problems. It also identifies the bridge version and selected processing mode.
• Updated modern-runtime configuration: v0.3.x uses Async instead of the legacy Inline switch. Lossless Scaling setup now explicitly writes Async=1, PreUpscale=0, UseFsrInputs=0, while retaining Inline=0 for older runtimes. The bridge rejects incompatible modes early. Upstream v0.3.1 also includes a revised wait method intended to reduce stalls.

To retest, close Lossless Scaling, run the new manager, then run its Lossless Scaling setup/update with your compatibility version.dll and legitimate neural DLL. Replacing the manager alone does not deploy the new bridge. Use the ordinary Scale workflow and keep the selected adapter unchanged; please leave asynchronous operation enabled. Testing the new bridge with your existing v0.2.18 first would give a useful diagnostic baseline, followed by v0.3.1 with its matching runtime files through setup.

If it still fails, please attach the new bridge-startup.log, runtime log and HIP timing log from nr-bridge/runtime, plus the final auto-scale error. Save the startup log before another launch because it is overwritten. Please sanitize any personal paths in other logs; no DLLs or weights are needed.

Builds, CPU/regression tests, packaging/rollback checks and UI checks passed. I have not reproduced your RX 9060 XT runtime session, so I am keeping this issue open until a fresh run confirms resolution. The v0.3.x configuration correction is separate from your original v0.2.18 stall, and I am not treating engine init ok as proof of completed neural rendering.

[Nikbis]

I completed both requested retests with DLSS5 AMD Swapper v0.3.0-pre.3, using the same controlled animated browser source and RX 9060 XT / HIP device 0. Each configuration was launched only once.

1. Existing upstream runtime v0.2.18

This still reaches the original health timeout, but the new diagnostics show that capture and presentation remain healthy throughout the run.

Final state after 66.733 seconds:

phase=health_timeout
captured=1616
feed_presents=1817
feed_occluded=0
last_present_hr=0x0
feed_visible=1
runtime_log=1
engine_initialized=1
render_hook_failure=0
completed_job=0
fatal=0
hip_progress_available=1
hip_active_waits=0
hip_returned_waits=0

Across all 65 startup samples, hip_active_waits, hip_returned_waits, completed_job, render_hook_failure, feed_occluded, and fatal remained zero. The runtime log ends at engine init ok, and the flushed HIP timing log contains only its eight header lines.

2. Matching upstream runtime v0.3.1

The v0.3.1 runtime is loaded correctly (build 11142f69), matches the RX 9060 XT D3D12 adapter, and reaches engine init ok. However, the bridge terminates it as runtime_failure after only 6.538 seconds:

phase=runtime_failure
captured=122
feed_presents=321
feed_occluded=0
last_present_hr=0x0
feed_visible=1
runtime_log=1
engine_initialized=1
render_hook_failure=0
completed_job=0
fatal=1
hip_progress_available=0
hip_active_waits=0
hip_returned_waits=0

The fatal flag is already 1 in the first startup sample, before engine initialization. The runtime log contains no actual crash, device removal, kernel failure, or zero-output line. The only apparent fault-related text is this informational v0.3.1 startup line:

DRED enabled (page-fault reporting; breadcrumbs off): a device removal will name the faulting allocation

The final bridge error is:

DLSS-NR runtime is not healthy: runtime log contains a fatal GPU/kernel/fault/crash/zero-output marker

This appears to be a false positive caused by matching page-fault or faulting in the informational DRED line. Because the bridge aborts almost immediately, this run cannot yet establish whether the revised v0.3.1 wait method resolves the original v0.2.18 stall.

The v0.3.1 startup log also reports:

hip_host_timing=unsupported_or_already_observed_imports

Could the fatal-marker parser exclude the informational DRED line, and can the HIP progress instrumentation support the revised v0.3.1 wait path? I can repeat the v0.3.1 test after that early abort is corrected.

The attached archive contains the complete sanitized logs for both single-run tests, separated into v0.2.18 and v0.3.1. It contains no DLLs, weights, manifests, captures, or machine-specific paths.

dlss5-amd-swapper-issue-3-combined-retests-2026-09-20.zip

[eikkapine]

Your reading of the v0.3.1 run is correct, and both diagnostic defects are now fixed in #5 (merged as ae126bc). Thank you for the two single-run tests and the separated logs; the fatal=1 in the very first startup sample was what identified the first defect.

1. The fatal-marker parser rejected informational text. The bridge searched the whole runtime log for the substrings fault and crash. v0.3.1's DRED notice contains both "page-fault reporting" and "faulting allocation", so the bridge ended a healthy startup as runtime_failure before the engine could complete a job. A loaded crashpad_handler would have tripped the same check, and the zero-output rule matched 100.00% and zero from unrelated lines, including the zero-copy interop mode.

The check now matches the runtime's own report lines — FAULT:, job N GPU errors, invalid kernel file, and a single-line 100.00% ... zero that excludes zero-copy — which is what the manager's log parser already required. probe/run_probe.ps1 carried the same substring pattern and was corrected with it. Genuine FAULT: and GPU-error reports still abort as before.

2. HIP instrumentation did not cover the revised wait path. Two separate causes, both of which your logs show:

• StartHipHostTiming required all six named HIP imports to be present and unmodified and returned unsupported_or_already_observed_imports otherwise, discarding the entire trace including the work-progress hints. That explains hip_progress_available=0 on v0.3.1, whose wait method does not import the same set as v0.2.18. It now observes whichever of those imports the runtime actually uses, requiring only a kernel launch plus one wait API, and writes an observed_imports= line into the HIP timing header so an absent wait API is visible rather than silent.
• Only hipDeviceSynchronize published the worker-wait hint. A runtime that waits on its stream or on an event therefore reported hip_active_waits=0 and hip_returned_waits=0 even while instrumentation was active — which is the more useful explanation of your v0.2.18 run, where hip_progress_available=1 yet all 65 samples stayed at zero. Every wait wrapper now publishes the hint. Completion of a sampled GPU kernel timing stays tied to device-wide waits, so no other wait reads event timestamps, and no wait, stream or kernel is added.

Verified by the bridge tests (new cases cover the DRED, crashpad, zero-copy, FAULT:, per-job GPU error and zero-output lines), a /W4 compile of the HIP branch, the C# smoke tests, 52 Python direct-game tests and the publication check. I have not reproduced your RX 9060 XT session, so none of this is evidence about the original v0.2.18 stall; it only removes two diagnostics that were hiding it.

These changes are in the bridge, so a new manager alone will not deploy them. Please hold the retest until I publish a v0.3.0-pre.4 package; I will post here when it is available. The same procedure then applies — run the Lossless Scaling setup/update so the new bridge is deployed, keep asynchronous operation and the selected adapter unchanged — and the useful evidence is bridge-startup.log, the runtime log and the HIP timing log from nr-bridge/runtime, saved before the next launch. The HIP timing header will now name the observed imports, which will tell us whether the v0.3.1 wait path is visible at all before we interpret its wait counts.

Keeping this issue open until a v0.3.1 run on your machine either reaches a completed neural job or stalls with the HIP hints populated.