spvDescriptorHeapEXT fetching nested data incorrectly

[calkwong]

Issue Description

When accessing a uniform buffer from descriptor heap using spvDescriptorHeapEXT (no descriptor sets and bindings), computed addresses are potentially incorrect for nested variables.

public struct UniformBuffer
{
    public float4x4 view;
	public float4x4 proj;
	public float4x4 view_proj;
	public float4x4 inverse_view_proj;
	public float4x4 prev_view_proj;
	public float4x4 light_rot;
	public float4x4 shadow_transforms[4]; // PROBLEM HERE
	public float4 cascade_splits;
	public float4 camera_pos;
	public float4 sunlight_color;
	public float4 sunlight_dir;
	public uint skybox_id;
	public uint irradiance_id;
	public uint prefiltered_id;
	public uint brdf_id;
}

Every other fetched variable is fine, but data for shadow_transforms is always wrong.

Reproducer Code

getDescriptorFromHandle(ConstantBuffer<UniformBuffer>.Handle(uint2(index,0))).shadow_transforms[i]

Above is how I fetch the data.

Expected Behavior

This incorrect behavior only surfaced after I switched from using descriptor sets and bindings (also descriptor heap) to untyped pointers (spvDescriptorHeapEXT). Apart from changing how descriptors are fetched across the board, no shader logic was touched.
Before this change, I accessed the uniform buffer this way:

[[vk::binding(0, 0)]] public ConstantBuffer<UniformBuffer> uniforms;
uniforms.shadow_transforms[i];

In spirv, as far as I can tell the way data is laid out in the uniform buffer is exactly the same in both cases. The only difference is the source of the base pointer.
For the problematic case:

%135 = OpUntypedAccessChainKHR %_ptr_UniformConstant %_runtimearr_133 %slang_resourceHeap %uint_0
%142 = OpBufferPointerEXT %_ptr_Uniform_UniformBuffer_natural %135

Working case:

%uniforms = OpVariable %_ptr_Uniform_UniformBuffer_natural Uniform

Workarounds

With spvDescriptorHeapEXT, If I flatten the array of matrices into individual float4x4 variables, they are fetched correctly again. Alternatively, passing the buffer's address directly through push constants and fetching manually also works correctly.

Environment

• Slang v2016.10.2
• Vulkan 1.4.350
• Linux 7.0.11-1-cachyos
• NVIDIA 3070ti / Driver 610.43.02
• slangc compiler options: -capability spvDescriptorHeapEXT -spirv-resource-heap-stride 32 -matrix-layout-column-major -fvk-use-scalar-layout

[nv-slang-bot]

Triage (automated specialist pass)

Thanks for the detailed report and the SPIR-V snippets — that's enough to localize this.

• Classification: bug in SPIR-V code generation for a ConstantBuffer<T> accessed through the descriptor-heap untyped-pointer path (spvDescriptorHeapEXT → OpUntypedAccessChainKHR / OpBufferPointerEXT). High severity, P1.
• Reproduced GPU-free: on a current build (b305a4df4) this path now hard-crashes the compiler (SIGSEGV) during SPIR-V emission for any ConstantBuffer<T> fetched via getDescriptorFromHandle/.Handle — even a single scalar member — whereas the equivalent StructuredBuffer<T> heap access compiles cleanly. The wrong-offset behavior you observe for shadow_transforms[4] looks like the milder, pre-crash form of the same defect. Minimal repro:

  struct Data { float v; float4x4 m[2]; }
  uniform RWStructuredBuffer<float> outBuf;
  [vk::push_constant] uint idx;
  [numthreads(1,1,1)][shader("compute")]
  void computeMain() { outBuf[0] = getDescriptorFromHandle(ConstantBuffer<Data>.Handle(uint2(idx,0))).v; }

  slangc min.slang -target spirv -stage compute -entry computeMain -capability spvDescriptorHeapEXT → SIGSEGV.
• Root area: emitDescriptorHeapLoad in source/slang/slang-emit-spirv.cpp (the member access chain emitted off the OpBufferPointerEXT result for a uniform-buffer descriptor). For reference, the bound [[vk::binding]] ConstantBuffer layout itself is correct (shadow_transforms at offset 384, ArrayStride 64, MatrixStride 16), so this is the heap/untyped-pointer access path specifically. -spirv-resource-heap-stride is the inter-descriptor heap stride and is not implicated in the member addressing.
• Related (not a duplicate): The slang compiler does not use the ArrayStrideIdEXT decoration when utilizing spvDescriptorHeapEXT. #10265 (ArrayStride / ArrayStrideIdEXT on the spvDescriptorHeapEXT path) and Segmentation fault using DescriptorHandle<ConstantBuffer<T>> with spvDescriptorHeapEXT #11037 / Fix crash when ConstantBuffer<T>.Handle is used with spvDescriptorHeapEXT (#11037) #11211 (earlier crash on ConstantBuffer<T>.Handle via spvDescriptorHeapEXT) are the closest neighbors.
• Next: handed to engineering to fix the emit-time crash first, then verify the nested array-of-matrix offsets. Your workarounds (flatten the matrix array into individual float4x4 members, or pass the buffer address via push constant) are good in the meantime.

[nv-slang-bot]

Correction to my earlier triage note

I need to correct the crash claim above. The SIGSEGV I reported reproduces only on a build that predates PR #11211 ("Fix crash when ConstantBuffer<T>.Handle is used with spvDescriptorHeapEXT", merged 2026-05-19). The binary I tested did not include that fix — its commit is not a descendant of #11211's fix commit aaa5f89dd — so what I hit is the already-fixed #11037 defect, not a defect on current master.

On current master (with #11211):

• The compiler does not crash on this pattern.
• The descriptor-heap access emits byte-identical layout to a bound [[vk::binding]] ConstantBuffer (member offsets 0 / 384 / 640, ArrayStride 64, MatrixStride 16) and passes spirv-val — i.e. no SPIR-V emission/layout defect is reproducible for the nested float4x4 shadow_transforms[4] access via the descriptor heap.

A regression test covering your exact case (nested array-of-matrix ConstantBuffer fetched through the descriptor heap) has been added in #11484. If you can, please update to a build that includes #11211 and retest on hardware — a static (GPU-free) analysis can't rule out a runtime-only / driver issue, so a hardware retest is the way to confirm whether anything remains. Apologies for the noise from the earlier crash claim.