[0031] Preliminary Draft of the HLSL changes for CoopVec #432
Conversation
llvm-beanz
changed the title
| ``` | ||
|
|
||
| > Note we need to support RWByteAddressBuffer and ByteAddressBuffer if we want | ||
| to use MatrixRef for both Mul and OuterProductAccumulate. How do we do this? |
There was a problem hiding this comment.
Curious for @tex3d's feedback here, but I wonder if we should have MatrixRef and RWMatrixRef as separate types to clarify usage and align with existing HLSL conventions?
The other approaches I can think of aren't particularly clean and would complicate our future desire to support separate compilation.
Co-authored-by: Chris B <[email protected]>
Co-authored-by: Chris B <[email protected]>
Co-authored-by: Chris B <[email protected]>
Co-authored-by: Chris B <[email protected]>
Co-authored-by: Chris B <[email protected]>
Co-authored-by: Chris B <[email protected]>
Co-authored-by: Chris B <[email protected]>
|
|
||
| The base address of **Buffer** and the **StartOffset** must be 64 byte aligned. | ||
|
|
||
| `dx.linalg.InterpretedVector` |
There was a problem hiding this comment.
It's not clear to me that this is actually necessary. For input types that are converted to a destination type prior to math, specifying the conversion target as an "interpretation" is confusing - and also seems unnecessary given the lack of precision requirements. For input types that are bit-packed, HLSL has an explicit scalar type to use instead, e.g. uint8_t4_packed, which could then be composed as a native vector type without this kind of wrapper.
|
Moved to #439, where parts of this PR will be shamelessly included in that one. |
This draft adds the various HLSL fuctions and classes in the
dx.linalgspace needed for the cooperative vector feature. This PR is a first draft with all these functions defined, not all the details are filled out.