#887) #890

New issue

Open

opened 2026-10-20 16:18:41 +00:00 by sky_line · 0 comments

sky_line commented

2026-10-20 16:18:41 +00:00

Owner

Investigation ticket for later.

What we know

The crash. #886 and #887 (1.4.0 Beta 2, RTX 4070, driver 32.0.16.1714) and #782 (1.3.0.10, RTX 4070 Ti SUPER, older driver) all crash at the same place: a breakpoint trap (0x80000003) in nvgpucomp64.dll (+0x589eb2 in #886/#887).
Whose thread. The thread was started by NVIDIA's driver, and no viewer code is on its stack. No viewer pipeline creation was in flight, and the main thread was doing unrelated work.
Recovery. The #886/#887 reporter recovered on their own. The crashes stopped after a short while, which fits the driver compiling a batch of new shaders once (Beta 2 added the weather shaders) and caching them afterwards.
A related case. #876 (Intel Arc, crash in the Intel driver while compiling pipelines at login) is the same kind of problem on another vendor.
Diagnostics in place. Since b9a84bfd3f, Windows crash reports list the last 24 pipelines the viewer created, and the remaining create calls (FX resolve/graphics, VRS) have compile breadcrumbs. A repeat should name the likely shaders.

Things to investigate

What makes the driver compile on its own thread on Windows: background optimisation or recompiles, pipeline-cache misses, specialisation, deferred link? Can we keep compilation on our compile threads instead, through pipeline-cache warming, VK_EXT_pipeline_creation_cache_control and creation feedback, or creation flags?
Pre-warm at controlled times. After an update, compile every pipeline variant at login, behind the existing progress or compile budget, so the driver isn't compiling during play.
Recognise the crash on the next start. A crash in the driver's compiler DLL on a driver thread is distinctive. If one happened, the next start could choose safer options, for example:
- skip or delay optional variants;
- drop the pipeline cache files;
- lower the compile threads;
- turn off the feature whose pipelines were created last.
  Each of these should be logged, temporary and visible, following the soft-degrade policy.
Identify the shader. Use the minidump or the crash report's "pipelines created last" list to find the shader. Check whether a SPIR-V pattern sets off the trap, and if so work around it in the shader. Report it to the vendor with a reproduction.
Same approach for other vendors. Apply the same guards to #876.

Needed from reporters

If it recurs: %APPDATA%\SlipstreamViewer\logs\Slipstream.dmp and the crash report from a build after b9a84bfd3f.

Investigation ticket for later. ## What we know - **The crash.** #886 and #887 (1.4.0 Beta 2, RTX 4070, driver 32.0.16.1714) and #782 (1.3.0.10, RTX 4070 Ti SUPER, older driver) all crash at the same place: a breakpoint trap (0x80000003) in `nvgpucomp64.dll` (+0x589eb2 in #886/#887). - **Whose thread.** The thread was started by NVIDIA's driver, and no viewer code is on its stack. No viewer pipeline creation was in flight, and the main thread was doing unrelated work. - **Recovery.** The #886/#887 reporter recovered on their own. The crashes stopped after a short while, which fits the driver compiling a batch of new shaders once (Beta 2 added the weather shaders) and caching them afterwards. - **A related case.** #876 (Intel Arc, crash in the Intel driver while compiling pipelines at login) is the same kind of problem on another vendor. - **Diagnostics in place.** Since b9a84bfd3f, Windows crash reports list the last 24 pipelines the viewer created, and the remaining create calls (FX resolve/graphics, VRS) have compile breadcrumbs. A repeat should name the likely shaders. ## Things to investigate 1. **What makes the driver compile on its own thread** on Windows: background optimisation or recompiles, pipeline-cache misses, specialisation, deferred link? Can we keep compilation on our compile threads instead, through pipeline-cache warming, `VK_EXT_pipeline_creation_cache_control` and creation feedback, or creation flags? 2. **Pre-warm at controlled times.** After an update, compile every pipeline variant at login, behind the existing progress or compile budget, so the driver isn't compiling during play. 3. **Recognise the crash on the next start.** A crash in the driver's compiler DLL on a driver thread is distinctive. If one happened, the next start could choose safer options, for example: - skip or delay optional variants; - drop the pipeline cache files; - lower the compile threads; - turn off the feature whose pipelines were created last. Each of these should be logged, temporary and visible, following the soft-degrade policy. 4. **Identify the shader.** Use the minidump or the crash report's "pipelines created last" list to find the shader. Check whether a SPIR-V pattern sets off the trap, and if so work around it in the shader. Report it to the vendor with a reproduction. 5. **Same approach for other vendors.** Apply the same guards to #876. ## Needed from reporters If it recurs: `%APPDATA%\SlipstreamViewer\logs\Slipstream.dmp` and the crash report from a build after b9a84bfd3f.

sky_line added the

crash

rendering

labels

2026-10-20 16:18:41 +00:00

sky_line added this to the Slipstream project

2026-10-20 16:18:41 +00:00

sky_line referenced this issue

2026-10-21 16:50:54 +00:00

Intel Arc (Windows): crash in the Intel Vulkan driver while compiling pipelines at the login screen (since 1.3.0) #876

sky_line referenced this issue from a commit

2026-10-22 08:20:13 +00:00