We are reporting a reproducible failure that strongly points to an NVIDIA Vulkan driver defect. Creating a second compute pipeline causes an otherwise correct shader dispatch to fail with VK_ERROR_DEVICE_LOST (-4). The second pipeline is never bound or dispatched. Both pipeline creations succeed; the error appears when waiting for the first shader’s fence.
The standalone C++/SPIR-V reproduction fails on two independent machines, with RTX 4090 and RTX 4070 SUPER GPUs. It contains no game code, textures, rendering or swapchain. Independent host and shader implementations retain the failure, and the validation checks below have found no preceding application violation. The evidence supports driver investigation; the exact internal defect remains unconfirmed.
Minimal reproduction
- Create compute pipeline A with a 512-uint (2 KiB) private array.
- Optionally create pipeline B from the same shader with a larger private array.
- Dispatch only A: 1,095 workgroups of 64 threads.
- Wait for its fence and compare all 70,080 outputs with an independent CPU oracle.
Expected: A produces identical correct output whether B exists or not. Every private-array element is initialized and its accesses are bounded. The application allocates only a 128-byte input buffer and a 280,320-byte output buffer. Each case uses a fresh process/device; the native host requests Vulkan 1.1.
Results
B sizes are source private-array sizes, not total driver allocations. Every pass verifies all 70,080 outputs with zero mismatches.
| GPU / Windows build / driver | A alone | B = 16 KiB | B = 32 KiB | B = 49,920 bytes |
|---|---|---|---|---|
| RTX 4090 / Win10 19045 / 616.92 | Pass | Pass | Device loss | Not tested |
| RTX 4070 SUPER / Win10 19045 / 616.56 | Pass | Pass | Pass | Device loss |
| GTX 1080 / Win11 26200 / 582.66 | Pass | Pass | Pass | Not tested |
The 4070 SUPER’s larger-array result was confirmed with the tester’s background CUDA applications closed. Cross-PC runs use the same executable and A shader, with validation/fault reporting disabled and implicit Vulkan layers filtered out.
On the 4090, identical inputs also reproduce the same pass/fail boundary after installing Vulkan developer driver 597.11 and rebooting, then again after restoring 616.92. That driver comparison did not resolve the failure.
Main diagnostic clue
On the 4090, queried topology is 128 SMs x 1,536 maximum resident threads = 196,608. Measured heap usage after B creation follows this relationship in six cases:
heap0_usage = 415674368 + ((B_array_bytes * 196608) modulo 4294967296)
Two sizes were predicted before testing:
| B array bytes | Reported heap usage after B creation | A outcome |
|---|---|---|
| 21,824 | 4,706,447,360 bytes | Pass |
| 21,856 | 417,771,520 bytes | Device loss |
The reported heap budget was approximately 24.5 GB. NVML also observed a much smaller memory-use increase in the failing case, although neither API exposes the actual scratch allocation. This suggests possible sizing/truncation or addressing trouble; it does not establish the internal cause.
The simple topology-based prediction did not generalize to the 4070 SUPER. Its 56 SMs x 1,536 threads predicted a pass at 49,920 bytes, but that case failed. The planned 49,984-byte case was consequently skipped. We have not measured its pipeline memory usage and do not claim a universal threshold.
Controls already performed on the 4090
- Separate Rust/wgpu Vulkan host and separately hand-written, validated SPIR-V retain the failure contrast.
- Core, synchronization and GPU-assisted validation find no preceding application violation; deliberate invalid controls demonstrate detection. Host ASan also passes the valid test. These checks do not prove exhaustive correctness.
- A passes before B is created and fails afterward, even if B is destroyed before the next dispatch. Creating B on a separate logical device avoids the failure.
- A separate CUDA/PTX implementation verifies all outputs, including a larger workload with over 4 GiB reported memory-use increase. Its compiler and resource management differ, so this is supporting evidence, not proof of Vulkan’s cause.
The synthetic package contains source, executable, shaders, hashes, logs and run instructions. The frozen test needs Python 3.9+ and the installed driver; no SDK/compiler is required. A failing case can reset the GPU.
Please reproduce this failure and investigate the driver’s private-memory allocation and addressing after pipeline creation. Please confirm whether it matches an existing driver issue and whether a corrected driver or supported application-side solution is available. If you identify invalid API usage in the supplied reproduction, please point to the specific operation or requirement.
vulkan-unused-pipeline-repro-public-v1.zip (216.3 KB)