Hi NVIDIA Vulkan team,
I have a minimal reproducer for what appears to be an incorrect coordinate mapping issue in `VK_NV_cooperative_matrix2` when using:
```glsl
coopMatLoadTensorNV(mat, data, elementOffset, layout, tensorViewTranspose, decodeFunc)
Summary
The tested input is a Q4_K quantized block matrix whose physical layout stores K blocks first:
[K_block, M]
For a logical matrix element (m, k), the expected Q4_K block location is:
k_block = k / QUANT_K
idx = k % QUANT_K
block = k_block * M + m
The reproducer directly constructs this [K_block, M] input buffer. Therefore the test focuses only on the CM2 read path: whether coopMatLoadTensorNV + tensorViewTranspose + decode callback supplies correct blockCoords and coordInBlock values to the decode callback.
Expected behavior
For each cooperative-matrix component, the hardware path should match the software reference path:
HW path: coopMatLoadTensorNV + tensorViewTranspose + decode callback
SW path: coopMatPerElementNV(row, col) + manual Q4_K address calculation
Expected: hw_val == sw_val
The decode callback expects coordinates equivalent to:
blockCoords[0] = k_block
blockCoords[1] = m row
coordInBlock[0] = offset within the Q4_K block along K, range 0..255
coordInBlock[1] = 0
Actual behavior
On my system, the HW path produces many mismatches against the SW reference path.
Environment:
GPU: NVIDIA GeForce RTX 4080
Driver: 610.47.0.0
Vulkan SDK: 1.4.341.1
OS: Windows
Example result:
RESULT: *** FAIL ***
Total mismatches: 63056
block_k=0 : 15928 mismatches <-- FAIL
block_k=128 : 15376 mismatches <-- FAIL
block_k=256 : 15368 mismatches <-- FAIL
block_k=384 : 16384 mismatches <-- FAIL
Example mismatch detail:
tid=128 block_k=0 comp=0
HW: blockCoords=(0,0) coordInBlock=(0,16) read block=0 idx=0 val=0.0
SW: row=16 col=0 k_block=0 m=16 read block=16 idx=0 val=3.0 delta=-3.0
For the same cooperative-matrix component, the SW reference expects row=16, col=0, therefore it reads block=16, idx=0. However, the HW decode callback receives blockCoords=(0,0), coordInBlock=(0,16), which makes it read block=0, idx=0.
This suggests that the callback coordinate mapping does not match the expected tensor-view interpretation. Some runs also show invalid-looking coordinate values such as 0xffffffff, and earlier experiments found that accessing the callback buffer-reference parameter can cause VK_ERROR_DEVICE_LOST.
Reproducer
I attached a zip file containing:
nv_cm2_transpose_bug.comp
nv_cm2_transpose_bug.cpp
nv_cm2_transpose_bug.spv
nv_cm2_transpose_bug_report_en.md
Build commands:
glslc --target-env=vulkan1.3 -o nv_cm2_transpose_bug.spv nv_cm2_transpose_bug.comp
cl /EHsc /std:c++17 /I"C:\VulkanSDK\1.4.341.1\Include" nv_cm2_transpose_bug.cpp ^
/link /LIBPATH:"C:\VulkanSDK\1.4.341.1\Lib" vulkan-1.lib
Run:
nv_cm2_transpose_bug.exe
Request
Could NVIDIA please confirm whether this is a driver bug in VK_NV_cooperative_matrix2 / GL_NV_cooperative_matrix2, specifically for this combination?
col-major [K_block, M] tensor layout
+ tensorViewNV transpose
+ block-quantized decode callback
Expected fix/behavior:
- The decode callback should receive spec-compliant
blockCoordsandcoordInBlockvalues when the tensor layout uses block size, such as Q4_KQUANT_K=256. - Coordinate mapping should remain correct when
tensorViewNV<2, false, 1, 0>transpose view is used. - The callback buffer-reference parameter should point to a valid block, and accessing its fields should not cause
VK_ERROR_DEVICE_LOST. - After the fix, this reproducer should print
RESULT: PASS.
Thanks.
nv_cm2_transpose_bug_issue_package.zip (18.7 KB)