Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[0029] Clarify 16-byte underlying allocation requirement #430

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

[0029] Clarify 16-byte underlying allocation requirement #430

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
3cc8d85
Fix DestStride must be multiple of 16.
damyanp Mar 14, 2025
b44dbd6
[0029] Clarify 16-byte underlying allocation requirement
damyanp Mar 14, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
17 changes: 12 additions & 5 deletions proposals/0029-cooperative-vector.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -234,7 +234,7 @@ Only non-packed interpretations are valid for matrices.
The base address of **matrix resource** and **matrix offset** must be 128 byte
aligned. Also note that the size of the underlying allocation is guaranteed to
be a multiple of 16 bytes ensuring that the 16 bytes access of the last
row/column of the matrix is valid memory.
row/column of the matrix is valid memory.

The **matrix stride** is 16 byte aligned.

Expand Down Expand Up @@ -318,7 +318,9 @@ interpretation** and **matrix layout** behaving as described [above]
The base address of **matrix resource** and **matrix offset** must be 128 byte
aligned. Also note that the size of the underlying allocation is guaranteed to
be a multiple of 16 bytes ensuring that the 16 bytes access of the last
row/column of the matrix is valid memory
row/column of the matrix is valid memory. Implementations may write to the
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One idea is to rewrite this as : Implemetations may need to use the padding space (e.g while using smaller types like FP16 that certain hardware might not natively support and are therefore emulated with bigger native types), so as a general rule using the padding space is undefined behavior.

Just to give the reader more information of why we have this restriction.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is more about supporting cases where there is native support for the type but it has additional alignment requirements. I think I might leave this as it is for now, can add clarification later, but that really belongs in the user documentation.

contents of the padding between the end of the matrix and the 16-byte boundary,
so developers should not use this padding space for anything else.

The **matrix stride** is 16 byte aligned.

Expand Down Expand Up @@ -359,8 +361,13 @@ The input vector is specified by **input vector**, and has `NUM` elements of
type `TY`.

The output array is accumulated to the writeable raw-buffer resource specified
by **output array resource** and **output array offset**. The base address
and **output array offset** must be 64 byte aligned.
by **output array resource** and **output array offset**. The base address and
**output array offset** must be 64-byte aligned. Also note that the size of the
underlying allocation is guaranteed to be a multiple of 16 bytes, ensuring that
there is valid memory between the end of the array and the 16-byte bounadry.
Implementations may write to the contents of the padding between the end of the
matrix and the 16-byte boundary, so developers should not use this padding space
for anything else.

[CheckFeatureSupport] can be used to determine which vector element types can be
accumulated. A list of types that are guaranteed to be supported on all devices
Expand Down Expand Up @@ -920,7 +927,7 @@ void ID3D12CommandList::ConvertLinearAlgebraMatrix(D3D12_LINEAR_ALGEBRA_MATRIX_C
* If SrcLayout is row-major or column-major, then SrcStride should be greater than the length of a row/column, and a
multiple of the element size.
* If DestLayout is row-major or column-major, then DestStride should be greater than the length of a row/column, and a
multiple of the element size.
multiple of 16.
Comment on lines 927 to +930
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it correct that both of these bullets are talking about row-major/column-major, but only dests have this stride requirement? Perhaps the 16 byte stride requirement should be unconditionally applied to the dest wording here, i.e. a new bullet that's not coupled to the row-major/column-major bit.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The stride value is ignored for non row-major/column-major layouts, so it isn't really unconditionally applied to the dest. Or am I misunderstanding your suggestion?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh right, forgot that spec detail.

* If SrcComponentType is not a supported MatrixInterpretation value as reported by CheckFeatureSupport() then
SrcComponentType should be `D3D12_LINEAR_ALGEBRA_DATATYPE_FLOAT32`.
* If DestComponentType is not a supported MatrixInterpretation value as reported by CheckFeatureSupport() then
Expand Down