Vulkan RayQuery + descriptor heap: stable on 610.88, GPU page faults on 616.x / 617.x; Nsight Graphics dies at vkCreateDevice

Gaming and Visualization Technologies APIs Vulkan
, ,
1

Hi,

I’m seeing what looks like a driver regression with Vulkan ray query on recent Game Ready drivers, and I wanted to check whether others hit the same thing before I invest in a minimal standalone repro.

Setup

  • Custom Vulkan engine (not Unreal/Unity)
  • NVIDIA GPU (Windows)
  • Vulkan 1.3+ with:
    • VK_KHR_ray_query
    • VK_KHR_acceleration_structure
    • VK_EXT_descriptor_heap (bindless resource heap; acceleration structures bound as descriptors and indexed from shaders)
    • VK_KHR_unified_image_layouts
  • Fragment shaders use RayQuery / TraceRayInline against a bindless TLAS (shadow / occlusion style queries). Compute also uses RayQuery in some passes (e.g. AO).
  • Worlds recreate / grow TLASes when content is loaded and unloaded (editor-style open/close of scenes).
  • Khronos validation layers: no validation errors (standard, synchronization, GPU-assisted) leading up to the crash.
  • Nsight Aftermath GPU crash dumps available on the failing drivers.

Driver matrix

Driver Result
610.88 (latest 610.x I tested) Stable — I cannot reproduce the crash after extended stress
616.x Intermittent GPU crash / device lost
617.14 (latest I tested) Same class of crash

Same binary, same content, same workflow. Only the driver changes.

Crash behavior (617 / 616)

  • VK_ERROR_DEVICE_LOST
  • Aftermath: Error_DMA_PageFault
  • Faulted warp is typically a fragment shader doing RayQuery (Proceed / traversal), not a random CPU-side assert
  • Fault addresses are often not any acceleration-structure base I logged. Examples:
    • 0x000000003f800000 (IEEE bit pattern for 1.0f)
    • previously also unmapped / garbage VAs such as 0xc60025000
  • Markers at fault time often show render passes that use RayQuery (e.g. translucent / OIT path and ambient occlusion) as active or recently finished

So this does not look like a simple “app freed a buffer and validation missed it” fingerprint; the SM appears to be traversing nonsense addresses during RayQuery.

Nsight Graphics

Nsight Graphics has never been able to capture this application since the current renderer landed. The likely culprits are the newer extensions I enable, especially VK_EXT_descriptor_heap and VK_KHR_unified_image_layouts (alongside ray query / acceleration structures). It fails during Vulkan device creation, before rendering. That has been true across drivers I’ve tried, so I’m treating it as a tooling/extension support gap rather than part of the 610 to 616 crash regression. It does mean I can’t use Nsight to debug the RayQuery page faults on 616+.

Aftermath in-process crash dumps still work when enabled.

What I’m asking

  1. Are there known RayQuery / descriptor-heap / bindless AS issues on 616+ that were not present on 610.x?
  2. Is Nsight Graphics expected to support apps that enable VK_EXT_descriptor_heap and VK_KHR_unified_image_layouts (with ray query) on current drivers, or are device-create failures a known limitation?
  3. Any recommended isolation (e.g. specific extensions, VK_NV_* diagnostics, or a minimal pattern NVIDIA wants for a bug report)?

I can work on a small headless Vulkan stress sample (bindless TLAS slot + fragment RayQuery + create/destroy/grow loop) and gfxreconstruct captures if that is the preferred path. Shipping the full editor is not practical, but the failure is deterministic enough across drivers that a reduced case should be possible.

Thanks.