Skip to content

[0029] Clarify Rounding and Denorm behavior for Coopvec functions #564

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

Closed
wants to merge 1 commit into from
+16 −12
Closed

[0029] Clarify Rounding and Denorm behavior for Coopvec functions #564

Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
28 changes: 16 additions & 12 deletions proposals/0029-cooperative-vector.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -342,6 +342,8 @@ determine which combinations are supported. A list of combinations that are
guaranteed to be supported on all implementations can be found in
[Minimum Support Set].

See [Conversion Rules] for rounding and denorm behavior.
Copy link
Collaborator

Choose a reason for hiding this comment

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

Missing [Conversion Rules] link elsewhere (see how [Minimum Support Set] above is linked).


#### Validation

* **matrix interpretation** must be a value corresponding to one of the
Expand Down Expand Up @@ -506,17 +508,12 @@ Non-"Packed" type interpretations are used to request arithmetic conversions.
Input type must be a 32-bit or 16-bit scalar integer or a 32-bit or 16-bit
float. Integer to integer conversion saturates, float to float conversion is
implementation dependent and preserves the value as accurately as possible.
Float to integer conversion is RTNE and saturating. Integer to float conversion
is RTNE.

> TODO: These rules make sense for NN applications but diverge from HLSL
> conversion rules
> [here](https://microsoft.github.io/hlsl-specs/specs/hlsl.html#Conv).
Float to integer conversion is RTNE (round to nearest even) and saturating.
Integer to float conversion is RTNE. Given the diverse hardware used in
Copy link
Collaborator

Choose a reason for hiding this comment

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

For integer to float, what is the overflow behavior when the integer value is out-of-range of the selected float value? Is it saturating, or does it generate +/-INF? Or is it implementation defined?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It is implementation defined. Ideally that would be INF, but since we aren't specing out INF/NAN behavior due to varying hardware, this would be partial specifying INF generation which I think will make it more confusing.

accelerating these operations, denorm behavior is implementation defined.

"Packed" type conversions are bitcasts to a smaller type. The declared input type must be 32-bit unsigned integer.

> /// XXX TODO: Error handling for illegal conversions.

Examples:

Packed Case:
Expand Down Expand Up @@ -570,7 +567,10 @@ Non-Packed Case:

#### Precision Requirements

The precision for intermediate operations is implementation dependent.
The precision for intermediate operations is implementation dependent. However,
it is intended that operations take place at the precision specified by the
interpretation parameters with the possible exception of older hardware where
this might not be practical.

### Matrix Layouts

Expand Down Expand Up @@ -733,9 +733,13 @@ the operation fails and `E_INVALIDARG` is returned.

>Note about emulation: For example E4M3 and E5M2 might not be supported natively
on certain implementations, but since these are in the minimum support set,
they need to be emulated, possibly using FP16. Emulation versus native support
is an implementation detail specific to implementations and outside the scope
of this specification document.
they need to be emulated, possibly using FP16.

>Emulation versus native support is an implementation detail specific to
implementations and outside the scope of this specification document. The
flexibility to perform operations at a higher precision is allowed for older
hardware, but performing operations at the specified `interpretation`
precision is the desired behavior.

#### Support Tiers

Expand Down