Summary
The NVIDIA Vulkan driver crashes with SIGSEGV during vkCreateComputePipelines when the SPIR-V
module declares both OpCapability CooperativeMatrixKHR and OpCapability GroupNonUniformArithmetic
(or other GroupNonUniform* capabilities from subgroup operations).
Environment
- GPU: NVIDIA GeForce RTX 5080
- Driver: 595.58.3.0
- Vulkan: 1.4.x
- OS: Linux (Ubuntu)
- SPIR-V generator: naga v29 (Rust shader compiler)
Reproduction
A compute shader that uses both cooperative matrix operations (coopLoadT, coopMultiplyAdd,
coopStoreT) and subgroup operations (subgroupAdd) in the same module causes the crash.
The shader compiles fine through vkCreateShaderModule — the SIGSEGV occurs in
vkCreateComputePipelines.
The equivalent WGSL source uses:
enable wgpu_cooperative_matrix;
enable subgroups;
The generated SPIR-V declares:
OpCapability CooperativeMatrixKHR
OpCapability GroupNonUniform
OpCapability GroupNonUniformArithmetic
OpCapability Float16
Validation
- spirv-val (via VK_LAYER_KHRONOS_validation) reports no errors related to the
subgroup/cooperative matrix combination. The only warnings are pre-existing ArrayStride
issues on Workgroup variables (VUID-StandaloneSpirv-None-10684), which are tolerated by
the driver in shaders that don't use subgroups.
- The same shader works correctly on AMD (RADV) where cooperative matrix is not available
(subgroup ops alone work fine).
- Removing either enable subgroups; (and the subgroupAdd call) or
enable wgpu_cooperative_matrix; (and the cooperative matrix calls) individually
makes the shader compile and run without issues on NVIDIA.
Workaround
Split subgroup and cooperative matrix operations into separate shader modules. Use workgroup
shared memory + barrier-based tree reduction instead of subgroupAdd within cooperative
matrix shaders.
Impact
This prevents fusing RmsNorm normalization (which benefits from subgroup-cooperative reduction)
into cooperative matrix matmul kernels (which need tensor core access). The workaround of using
workgroup-level reduction with 64 threads requires 7 barriers per row, making the fused kernel
~57% slower than the unfused path.
Related
Summary
The NVIDIA Vulkan driver crashes with SIGSEGV during
vkCreateComputePipelineswhen the SPIR-Vmodule declares both
OpCapability CooperativeMatrixKHRandOpCapability GroupNonUniformArithmetic(or other GroupNonUniform* capabilities from subgroup operations).
Environment
Reproduction
A compute shader that uses both cooperative matrix operations (
coopLoadT,coopMultiplyAdd,coopStoreT) and subgroup operations (subgroupAdd) in the same module causes the crash.The shader compiles fine through
vkCreateShaderModule— the SIGSEGV occurs invkCreateComputePipelines.The equivalent WGSL source uses:
Validation
subgroup/cooperative matrix combination. The only warnings are pre-existing ArrayStride
issues on Workgroup variables (VUID-StandaloneSpirv-None-10684), which are tolerated by
the driver in shaders that don't use subgroups.
(subgroup ops alone work fine).
enable wgpu_cooperative_matrix; (and the cooperative matrix calls) individually
makes the shader compile and run without issues on NVIDIA.
Workaround
Split subgroup and cooperative matrix operations into separate shader modules. Use workgroup
shared memory + barrier-based tree reduction instead of subgroupAdd within cooperative
matrix shaders.
Impact
This prevents fusing RmsNorm normalization (which benefits from subgroup-cooperative reduction)
into cooperative matrix matmul kernels (which need tensor core access). The workaround of using
workgroup-level reduction with 64 threads requires 7 barriers per row, making the fused kernel
~57% slower than the unfused path.
Related
subgroupBroadcastgfx-rs/wgpu#6902 — naga subgroup capability emission issue