GPU device lost on GTX 1080 Ti (Windows 10, driver 582.66) while the viewer was out of focus #209

New issue

Open

opened 2026-09-30 19:40:28 +00:00 by sky_line · 0 comments

sky_line commented

2026-09-30 19:40:28 +00:00

Owner

Report

A user with a GTX 1080 Ti on Windows 10, NVIDIA driver 582.66, got a GPU driver loss (device lost / driver reset). The viewer was out of focus (in the background) when it happened.

Context

Pascal (1080 Ti): no hardware ray queries, so the RT paths are off and it runs shadow maps. It's also our heaviest per-pixel load relative to its capability (see the #123 / #124 timings on a 1080 Ti).
Out of focus: the viewer yields 40 ms per frame when unfocused (BackgroundYieldTime), so it presents at ~22 fps. Worth checking whether anything behaves differently in the background:
- swapchain acquire timeouts;
- fence waits;
- resize / minimise and swapchain recreation;
- the texture streamer or residency catching up with larger uploads;
- a long single submission tripping Windows TDR (2 s default).
Related: #135 (handle VK_ERROR_DEVICE_LOST gracefully), #136 (GPU breadcrumbs, now in), #107 (Windows abrupt exits).

To collect from the user

Slipstream.log from the session: the [vkgfx] GPU breadcrumbs line and the last VK_ERROR_DEVICE_LOST / breadcrumb pass names before the loss (which pass the GPU was in).
Windows Event Viewer, System log: nvlddmkm events (ID 13 / 14 / 153) and Display TDR events (ID 4101) around the time.
What else was running: other 3D apps, overlays (Overwolf, Discord, GeForce Experience), a second monitor with video.
Settings: graphics preset / quality level, shadows, upscaling, TAA, draw distance, whether the window was minimised or just unfocused.
Reproducibility: does it happen again when alt-tabbed for a while, and does it also happen in the foreground?

Leads

If the breadcrumbs point at one pass, check its worst-case cost on Pascal (probe capture, shadows, particles, texture uploads) and split long work.
Check the background path doesn't queue several frames of work at once after the 40 ms sleep, e.g. multiple pending probe captures or texture batches in one submit.
Windows TDR is 2 s: any single queue submission approaching that on a 1080 Ti is the likely trigger.

## Report A user with a **GTX 1080 Ti** on **Windows 10**, NVIDIA driver **582.66**, got a GPU driver loss (device lost / driver reset). The viewer was **out of focus** (in the background) when it happened. ## Context - **Pascal (1080 Ti):** no hardware ray queries, so the RT paths are off and it runs shadow maps. It's also our heaviest per-pixel load relative to its capability (see the #123 / #124 timings on a 1080 Ti). - **Out of focus:** the viewer yields 40 ms per frame when unfocused (`BackgroundYieldTime`), so it presents at ~22 fps. Worth checking whether anything behaves differently in the background: - swapchain acquire timeouts; - fence waits; - resize / minimise and swapchain recreation; - the texture streamer or residency catching up with larger uploads; - a long single submission tripping Windows TDR (2 s default). - **Related:** #135 (handle VK_ERROR_DEVICE_LOST gracefully), #136 (GPU breadcrumbs, now in), #107 (Windows abrupt exits). ## To collect from the user - **Slipstream.log** from the session: the `[vkgfx] GPU breadcrumbs` line and the last `VK_ERROR_DEVICE_LOST` / breadcrumb pass names before the loss (which pass the GPU was in). - **Windows Event Viewer**, System log: `nvlddmkm` events (ID 13 / 14 / 153) and `Display` TDR events (ID 4101) around the time. - **What else was running:** other 3D apps, overlays (Overwolf, Discord, GeForce Experience), a second monitor with video. - **Settings:** graphics preset / quality level, shadows, upscaling, TAA, draw distance, whether the window was minimised or just unfocused. - **Reproducibility:** does it happen again when alt-tabbed for a while, and does it also happen in the foreground? ## Leads - If the breadcrumbs point at one pass, check its worst-case cost on Pascal (probe capture, shadows, particles, texture uploads) and split long work. - Check the background path doesn't queue several frames of work at once after the 40 ms sleep, e.g. multiple pending probe captures or texture batches in one submit. - Windows TDR is 2 s: any single queue submission approaching that on a 1080 Ti is the likely trigger.

sky_line referenced this issue from a commit

2026-10-04 06:45:16 +00:00

#135 VK: one device-lost state, detection at every surfacing point, no abort

sky_line referenced this issue from a commit

2026-10-04 06:45:16 +00:00

#135 Device lost: report block, message box, clean exit, restart, next-launch notice

sky_line added this to the Slipstream project

2026-10-06 15:04:15 +00:00