GLSL: implement SPV_NV_cooperative_vector#2489
Conversation
|
I also prepared a draft for https://registry.khronos.org/vulkan/specs/latest/man/html/VK_NV_cooperative_matrix2.html before working on coopvec-nv. But I discovered that interactions of |
theHamsta
force-pushed
the
coopvec-nv
branch
8 times, most recently
from
af644be to
aedf69e
Compare
| uint32_t component_type_id = 0; | ||
| uint32_t component_count_id = 0; | ||
| } coopVecNv; | ||
|
|
There was a problem hiding this comment.
Should this be merged to one union or stay multiple consecutive struct fields?
| auto matrix_stride_id = length >= 6 ? ops[6] : 0; | ||
| //void coopVecOuterProductAccumulateNV(const coopvecNV<T, M> v1, const coopvecNV<T, N> v2, | ||
| //T[] buf, uint offset, uint stride, | ||
| //int matrixLayout, int matrixInterpretation); |
There was a problem hiding this comment.
Should I remove the verbatim parameters from SPIRV and GLSL spec?
There was a problem hiding this comment.
Those comments should just be removed, yes.
| // CoopVec-Nv can be used with integer operations like SMax where | ||
| // where spirv-opt does explicit checks on integer bitwidth | ||
| auto component_type = get<SPIRType>(type.coopVecNv.component_type_id); | ||
| type.width = component_type.width; |
There was a problem hiding this comment.
This could also be handled on the respective integer operations where it could defer to the bitwidth of the component type instead of the coop-vec
theHamsta
changed the title
SPV_NV_cooperative_vectorSPV_NV_cooperative_vector
https://github.khronos.org/SPIRV-Registry/extensions/NV/SPV_NV_cooperative_vector.html The implementation tries to follow the code for SPV_EXT_cooperative_matrix. The extension could be mapped in a follow-up to the following HLSL proposal https://github.com/microsoft/hlsl-specs/blob/main/proposals/0026-hlsl-long-vector-type.md
| EXTRA_SUB_EXPRESSION_TYPE_AUX = 0x20000000 | ||
| }; | ||
|
|
||
| const std::vector<std::tuple<uint32_t, const char *>> COOPVEC_COMPONENT_TYPE_NAMES = { |
There was a problem hiding this comment.
This should just be a static const array of POD struct inside the function that uses it.
Having a global const of non-POD types requires global initialization which really should be avoided if we can help it.
HansKristian-Work
left a comment
HansKristian-Work
left a comment
There was a problem hiding this comment.
I'll just pull this in locally and fix what I need to fix.
|
Merged. |
2 participants
This is on top of #2488 since replicated composites often occur in the initialization of cooperative vectors. This should stay in draft status until all issues with the previous PR are resolved.
I tried to roughly follow the implementation of
SPV_EXT_cooperative_matrix. Though I might not have tracked all dependencies of the instructions correctly. This is my first time working with spirv-cross, so some concepts are still unfamiliar to me. I tested the implementation on shaders in https://github.com/jeffbolznv/vk_cooperative_vector_perfThere is a roughly equivalent proposal for HLSL to which this SPV extension could be mapped: https://github.com/microsoft/hlsl-specs/blob/main/proposals/0026-hlsl-long-vector-type.md