Which proposal does this relate to?
linalg
Describe the issue or outstanding question.
The proposal states that loading/storing with groupshared memory will perform an automatic data conversion if the groupshared element type does not match the matrix element type.
The tint compiler (for WebGPU) will sometimes decompose groupshared memory into a generic type (e.g. 32-bit or 16-bit integers). A major motivating factor in that is an upcoming feature, buffer_view. That feature allows data type reinterpretation. Our concern is if we do not encode the same data type as the matrix element type an incorrect conversion would occur.
Would it be possible to have a way to skip conversions in the final release (say via an extra parameter)?
Additional context
SPIR-V's cooperative matrix does not care about the variable data type when loading/storing. MSL can do reinterpret casts. HLSL ByteAddressBuffer already handles reinterpretation so just the groupshared is problematic.
Which proposal does this relate to?
linalg
Describe the issue or outstanding question.
The proposal states that loading/storing with groupshared memory will perform an automatic data conversion if the groupshared element type does not match the matrix element type.
The tint compiler (for WebGPU) will sometimes decompose groupshared memory into a generic type (e.g. 32-bit or 16-bit integers). A major motivating factor in that is an upcoming feature, buffer_view. That feature allows data type reinterpretation. Our concern is if we do not encode the same data type as the matrix element type an incorrect conversion would occur.
Would it be possible to have a way to skip conversions in the final release (say via an extra parameter)?
Additional context
SPIR-V's cooperative matrix does not care about the variable data type when loading/storing. MSL can do reinterpret casts. HLSL ByteAddressBuffer already handles reinterpretation so just the groupshared is problematic.