DLSS Ray Reconstruction (sl.dlss_d) on Vulkan: deterministic VK_ERROR_DEVICE_LOST on the first RR evaluate frame (RTX 5090, drivers 610.88 & 616.56, SDK 2.12.0)

VK_ERROR_DEVICE_LOST inside the Vulkan DLSS Ray Reconstruction evaluate — RTX 5090, drivers 610.88 and 616.56

Bug report for NVIDIA driver / NGX review. Self-contained; no application source or
project context required. Every factual line traces to a measured, archived run;
full stderr and Streamline verbose logs for every arm are available on request.

---

1. Summary

On an RTX 5090 under Windows 11 with the Vulkan NGX/Streamline path, every DLSS
Ray Reconstruction (sl.dlss_d / kFeatureDLSS_RR) evaluate loses the device.
The first slEvaluateFeature(kFeatureDLSS_RR) returns success; the next
vkQueueSubmit fails VK_ERROR_DEVICE_LOST, on the frame that first evaluates RR.
The fault is deterministic and identical across two driver branches (610.88 and
616.56), three nvngx_dlssd.dll generations (310.7.0.0, 310.7.128.0 including the
DLSS 4.5 RR model, and 310.7.129.0 — NVIDIA's OTA RR-4.5 revision), all RR presets
(eDefault, D, E, F), and both render modes (Performance and DLAA) — every RR arm
through the Streamline 2.12.0 path. Device-diagnostic checkpoints place the fault
inside NGX's own recorded commands, between the begin and end markers that bracket the
DLSS-RR evaluate submission, on the graphics queue (no checkpoints recorded on the
compute queue). A shipped DirectX 12 path-tracing title with Ray
Reconstruction runs stably on the identical machine and driver, so the RR model, the
NGX runtime and the GPU are all healthy — the Vulkan RR evaluate path is the
isolated suspect.

---

2. Environment

• GPU: NVIDIA GeForce RTX 5090.

• OS: Windows 11 Home 10.0.26200.

• API: Vulkan (built against Vulkan SDK 1.4.350.0 headers). All runs
  windowed; the engine has no exclusive/borderless-fullscreen mode.

• Drivers tested: 610.88 (the original investigation driver) and 616.56
  (GeForce Game Ready WHQL, released 2026-08-26). The fault reproduces identically on
  both.

• Streamline SDK: 2.12.0. All plugins report 2.12.0 PRODUCTION in sl.log
  (sl.common, sl.dlss, sl.dlss_d, sl.dlss_g, sl.interposer, sl.reflex,
  etc., all v2.12.0.0). Integration uses manual hooking
  (eUseManualHooking | eUseFrameBasedResourceTagging | eDisableCLStateTracking).

• RR DLL versions tested (nvngx_dlssd.dll), each proven loaded from sl.log:

  FileVersion	provenance / identity	load proof (sl.log / NGX log)
  310.7.0.0	DLSS SDK checkout build (the RR DLL that shipped before the 4.5 model)	NGXSecureLoadFeature ... version: 310.7.0; on RR arms preset 6 "reverts to default" on this build
  310.7.128.0	DLSS 4.5 RR model build (shipped in the MW4 beta files); Authenticode Valid, MD5 3CFE1807BB7798115E335A3B03EBAF31 matching the DLSS Swapper manifest	NGXSecureLoadFeature ... nvngx_dlssd.dll version: 310.7.128; Built with APP_NAME = app_transformer_dlssd; NgxRayReconstruction::FillCreationParams ... Using Default Overriden Preset Preset_F
  310.7.129.0	NVIDIA's OTA RR-4.5 revision, one build newer than 310.7.128; FileVersion 310,7,129,0, FileDescription NVIDIA DLSS - DVS PRODUCTION, Authenticode Valid, signer CN=NVIDIA Corporation, SHA-256 4B43BC85D7F3C023F864D5FC2D8402F5A1E807A3DCBAF48E83A9DA57B4CB5349, 79,687,792 bytes	NGXValidateSnippetMetaData:1562 Snippet version : 310.7.129; NGXSecureLoadFeature:1499 ... nvngx_dlssd.dll version: 310.7.129; NGXLoadConfig app_E658700=310.7.129

  Note on the OTA revision: 310.7.129 does not load by default in this stack — the
  Streamline preferences do not pass eLoadDownloadedPlugins, and sl.log states
  OTA'd plugins will not be loaded!. For the 310.7.129 arms the DLL was manually
  placed into the Streamline bin/x64 directory as nvngx_dlssd.dll and its load
  confirmed from sl.log (line above); it was restored to 310.7.128.0 afterward.

---

3. Failure signature

• [sl-rr] ray reconstruction evaluating prints (RR is armed and the evaluate is
  entered). slEvaluateFeature(kFeatureDLSS_RR) #1 succeeds; the next
  vkQueueSubmit returns VK_ERROR_DEVICE_LOST.
• The single recovery line emitted is, verbatim:
  Recovered from vkQueueSubmit failed: VK_ERROR_DEVICE_LOST; vkDeviceWaitIdle(frame recovery) failed: VK_ERROR_DEVICE_LOST; swapchain recreation required: Vulkan device reconstructed: generation=2.
• Deterministic: exactly 2 VK_ERROR_DEVICE_LOST occurrences (one recovery
  line) per 60-frame RR arm, device reconstructed at generation=2, on every RR arm and repetition across
  both drivers (100% reproduction; all RR arms at 1280x720). On the same defect
  family's SR side, present-mode sweeps (FIFO / MAILBOX / IMMEDIATE) and window-size
  variation did not affect the fault, and no run showed timing or thermal sensitivity.
• Exit-code caveat (important for any reproducer): the application has device-loss
  recovery, so the process exits 0 and keeps rendering degraded. "It did not crash"
  is not a pass. The verdict is a stderr grep for DEVICE_LOST and a count of the
  recovery lines.
• The only other stderr string on a faulting RR arm is the expected post-loss teardown
  [dlss] eval parameter allocation failed; DLAA disabled. Zero Vulkan validation
  errors, zero VUIDs, zero OOM across every run.

---

4. Reproduction matrix

All rows below are 616.56 measurements. 60-frame batteries, 1280×720. DL = count
of VK_ERROR_DEVICE_LOST occurrences in stderr. Every RR arm matches its recorded
610.88 value (the fault predates the 616.56 update).

Ray Reconstruction — every arm faults (nvngx_dlssd.dll 310.7.128.0 held constant):

arm	config	preset	DL	verdict
A8	RR four-flag, Performance	eDefault	2	device lost, gen=2 (evaluate armed)
A9	RR four-flag, DLAA	eDefault	2	device lost, gen=2
A10	RR, Performance	D (4)	2	device lost
A11	RR, Performance	E (5)	2	device lost
A12	RR, Performance (FillCreationParams → Preset_F, 310.7.128 confirmed loaded)	F (6)	2	device lost

Ray Reconstruction — official pairing, 616.56 + nvngx_dlssd.dll 310.7.129.0 (OTA):

arm	config	preset	DL occ.	verdict
R1	RR four-flag, Performance	D (4)	2	FAULT, gen=2
R2	RR four-flag, Performance	E (5)	2	FAULT, gen=2
R3	RR four-flag, Performance (310.7.129 load proven in sl.log)	F (6)	2	FAULT, gen=2
R4	RR four-flag, Performance	eDefault	2	FAULT, gen=2
R5	RR four-flag, DLAA	eDefault	2	FAULT, gen=2

So RR faults across three DLL generations × four presets × two modes × two driver
branches, with no surviving arm. Every RR arm ran through the Streamline surface; the
raw-NGX surface was exercised for Super Resolution (§5.1), not RR.

Profile-adjacency data point (DLSS Super Resolution, same session, same machine).
This is offered because it may localize the faulting unit: on the SR path (a distinct
NGX feature from RR), transformer profiles J and K fault the device identically,
while the adjacent transformer profile M (13) runs clean everywhere tested on
616.56 (on 610.88 the neighbouring L (12) — one enum value above the faulting
K (11) — was clean while K faulted). Same integration, same tags, same dimensions,
same driver:

arm	config	preset	DL	verdict
A1	SR DLAA (FillCreationParams → Preset K)	eDefault→K	2	device lost
A2	SR DLAA	K (11)	2	device lost
A3	SR Performance @ 0.667	K (11)	2	device lost
A4	SR Performance @ 0.667	J (10)	2	device lost
A5	SR Quality	M (13)	0	clean
A6	SR DLAA	M (13)	0	clean
A16	raw-NGX DLAA (no Streamline)	M (13)	0	clean
A17	SR Quality M + Frame Generation 2×	M	0	clean (generation ACTIVE: status=0x0)

For SR, pinning transformer preset M is a full application-side workaround. RR has no
such escape: sl::DLSSDPreset exposes only D/E/F and all three fault. This is why this
filing concerns RR specifically — SR is worked around in shipping code, RR is not.

---

5. Why the driver, not the application

Each step below was measured; together they exhaust the application-side variables.

1. Two integration surfaces × byte-different DLL builds → one matrix (DLSS feature
   family). For DLSS Super Resolution the identical fault matrix reproduces through
   raw NGX (our own motion-vector / constants / jitter plumbing) and through
   Streamline 2.12.0 manual hooking (Streamline's own mvec, frame tokens,
   slSetConstants / slSetTagForFrame), and through byte-different DLL builds — two
   integrations and two DLLs isolating the shared component (the driver's Vulkan NGX
   path) and exonerating the application layer. RR itself was exercised through the
   Streamline surface across three DLL revisions (§4); its application-side exoneration
   rests on points 2–5 below and the in-GPU localization (§6).
2. API validation-clean. After two genuine early integration bugs were found and
   fixed (a missing TRANSFER_DST usage on an NGX transient; a NULL attachment in a
   consumer pass), the full Vulkan validation layer runs clean on the identical
   resolution replumb with NGX absent (the messenger cannot coexist with NGX init). No
   VUIDs, no validation errors, no OOM appear on any faulting run.
3. Its own optimal settings. The feature is created at the DLL's own
   NGX_DLSS_GET_OPTIMAL_SETTINGS dimensions and still loses the device at its own
   recommendation. Nothing remains to vary application-side in the create parameters.
4. Reset-flag negative. Forcing sl::Constants::reset = eTrue on every evaluate
   (declaring no temporal connection to the prior frame) does not bypass the fault —
   RR still loses the device after evaluate #1. This excludes the "stale/invalid history
   contents" class of explanation; the reset flag never reaches the faulting operation.
5. Disarmed control. With no DLSS/Streamline env armed, runs are byte-silent (no
   NGX or Streamline lines in stderr) and never lose the device -- 60-frame controls
   bracketing the battery, run twice.
6. Residency negative. Pinning VK_EXT_memory_priority priority 1.0 on every DLSS
   input/output/transient allocation (memory-priority=1 confirmed live) reproduces the
   fault identically with pinning on, off, and combined. This pins the priority of the
   application-tagged DLSS input/output/transient allocations; it does not reach
   the DLL-internal history allocation NGX creates during the evaluate, and the broader
   pageable/device-wide priority arm was not run. The UE5.5-class
   "resources evicted mid-evaluate" (WDDM demotion) hypothesis is therefore narrowed,
   not excluded: raising the priority of the resources the application owns does not
   help. No application-side lever we can reach — bias, preset, reset flag, mode enum, or residency —
   moves it.

---

6. In-GPU localization — the fault is inside NGX's recorded work

With VK_NV_device_diagnostic_checkpoints and VK_NV_device_diagnostics_config
enabled and vkCmdSetCheckpointNV markers bracketing the Streamline/DLSS-RR evaluate
submission, vkGetQueueCheckpointDataNV on the graphics queue at the loss reports:

[vk-checkpoint] frame recovery: 2 checkpoint(s) on the graphics queue
[vk-checkpoint]   stage=0x00000001 marker=dlss-eval-begin   (TOP_OF_PIPE)
[vk-checkpoint]   stage=0x00002000 marker=dlss-eval-begin   (BOTTOM_OF_PIPE)
[vk-checkpoint] frame recovery: compute queue reported no checkpoints

dlss-eval-begin completed at both pipeline stages. dlss-eval-end — recorded
unconditionally after a successful evaluate, and present in the command buffer (no
[dlss] SL evaluate failed line) — was never reached by the GPU. The device
therefore died between the two markers, inside the commands Streamline/NGX recorded
for the DLSS-RR evaluate, on the graphics queue. No checkpoints were placed on or
reported from the compute queue, so this bracket localizes the fault to the graphics-queue
evaluate submission without asserting the compute queue was idle. The driver's own automatic per-draw
checkpoints (diagnostics-config=1) reported no markers of their own, so this bracket
is as fine-grained as the checkpoint path gives without NSight Aftermath.

The actionable statement is not "our vkQueueSubmit fails" but "the Vulkan DLSS-RR
evaluate faults mid-evaluate, inside NGX's recorded commands."

---

7. DirectX 12 control — the RR model and the GPU are healthy here

A mainstream shipped DirectX 12 title with path tracing and Ray Reconstruction was
run on this exact RTX 5090 / 616.56 configuration and stayed stable through extended
play: no device loss, no reset, RR active throughout. So the RR model, the NGX runtime,
and the GPU are all functional on this machine and driver. Combined with the two-branch /
three-DLL / four-preset Vulkan fault matrix (§4) and the mid-evaluate localization (§6),
this isolates the defect to the driver's Vulkan NGX/DLSS-RR evaluate path — the DX12
path on the identical stack is unaffected.

Two questions this control does not yet close, both cheap for NVIDIA or the reporter to
answer: a shipped Vulkan RR title on this box, and an application-identity arm
(exe name / VkApplicationInfo / NGX application-id) to rule out a per-app driver
profile that an unprofiled engine never receives.

---

8. Minimal deterministic repro

Headless, 60 frames, RR at Performance, presets left at eDefault (or pinned D/E/F):

VES_STREAMLINE=1 VES_SL_DLSS=1 VES_SL_RR=1 VES_DLSS=performance VES_DLSS_PRESET=-1 \
  VES_SL_LOG=<dir> \
  ves_game --muted --width 1280 --height 720 --frames 60

Verdict procedure:

1. Grep stderr for DEVICE_LOST. Non-zero count = fault. Expected on any RR arm:
   two occurrences in one recovery line, generation=2.
2. Exit code 0 is NOT a pass — device-loss recovery masks the fault at the process
   level. Ignore the exit code; read stderr.
3. Confirm RR actually armed: [sl-rr] ray reconstruction evaluating must be present
   (no line ⇒ the evaluate never ran and the arm is void).
4. VES_SL_LOG=<dir> captures Streamline's verbose log; confirm the intended DLL loaded
   (NGXSecureLoadFeature ... nvngx_dlssd.dll version: <x>) and which RR preset
   NgxRayReconstruction::FillCreationParams selected, so a DLL/preset variable cannot
   move under the arm.

Pin presets with VES_DLSS_PRESET: 4=D, 5=E, 6=F, -1=eDefault.

---

9. What NVIDIA could confirm

The remaining cheap, decisive step is a GPU crash dump on the faulting evaluate:
wire NSight Aftermath (or the VK_NV_device_diagnostic_checkpoints path already
in place) and capture the faulting kernel plus MMU/page-fault address inside the
DLSS-RR evaluate on the frame the device is lost. A named faulting shader and fault
address turns this report from a reproducible symptom into a filable driver bug and
would confirm whether the fault sits in the RR evaluate/history kernel specifically.

We can run any experiment on request; no application source access is required.

---

Appendix — upstream / release context (public sources)

• Terminology. NVIDIA's public name for this feature is DLSS Ray Reconstruction
  (DLSS 4.5, 2nd-gen transformer model; runs on RTX 20-series forward). The Streamline
  feature is sl.dlss_d / kFeatureDLSS_RR, integrated via sl_dlss_d.h
  (sl::DLSSDPreset). "DLTSS" is not an NVIDIA-published term; it appears only as an
  internal DLL symbol (NgxDltss::…) observed in the dev-DLL log.
  Sources:
  DLSS 4.5 RR announcement,
  Streamline DLSS-RR programming guide,
  NVIDIA DLSS developer page.

• Driver 616.56 fixed-issues list contains no RR/NGX/Vulkan/device-lost item — its
  only DLSS entry is a Frame Generation VSync overshoot; the rest are unrelated app/API
  fixes. Its DLSS content is game enablement (DLSS 4.5 SR/MFG/RR for new titles), not an
  NGX or Vulkan bugfix.
  Sources:
  geeks3d,
  dsogaming,
  tweaktown.

• Adjacent open Streamline issues (NVIDIA-acknowledged, no fix version or driver
  named against them, SDK still pinned at 2.12.0 with no 2.13 tag):

  • #116 — crash inside
    nvngx_dlssd.dll (release build): access violation reading 0x0 inside
    EvaluateFeature, reported on DX12, driver 610.74, at ~1.72 balanced ratio.
    An independent RR-DLL fault on the other API and an older driver branch.
  • #115 — DLSS-G internal
    resource race on Vulkan.
  • #112 — DLSS-G (Vulkan) pacer
    reuses a present-semaphore →
    VUID-vkQueueSubmit-pSignalSemaphores-00067.
  • RR DLL revision context:
    TechPowerUp RR DLL library
    (310.7.129 current).

  These are context, not this defect: #116 is a DX12 null-deref access violation, whereas
  the fault here is a Vulkan VK_ERROR_DEVICE_LOST at queue submit with the GPU
  dying mid-evaluate — a different signature. They establish that the RR DLL family is
  under active NVIDIA triage across both APIs.

Start by reproducing the Vulkan Ray Reconstruction arm through Streamline 2.12.0, then inspect sl.log, stderr, vkQueueSubmit results, and the diagnostic checkpoint markers around slEvaluateFeature(kFeatureDLSS_RR). Done means determining whether the device loss is actionable in Streamline or requires NVIDIA driver/NGX investigation; the report does not name a repository file or test to modify.