Сlarify rounding #2140
Сlarify rounding #2140
Conversation
munrocket
commented
Sep 24, 2021
munrocket
commented
- Solving inlined into spec issue (currently UB)
- Making WGSL more clear about a*b+c expression in GLSL way (Paragraph 4.7.1 Range and precision)
|
munrocket marked as non substantive for IPR from ash-nazg. |
| @@ -6292,7 +6292,7 @@ the following exceptions: | |||
| of NaNs and infinities. | |||
| * Implementations may ignore the sign of a zero. | |||
| That is, a zero with a positive sign may behave like a zero a with a negative sign, and vice versa. | |||
| * No rounding mode is specified. | |||
| * Rounding mode is round-to-nearest even, but implementation may truncate results to zero. | |||
There was a problem hiding this comment.
This sounds strange to me. So is this line normatively saying what the rounding is, or is it basically "implementation defined" still?
There was a problem hiding this comment.
Maybe change implementation -> hardware?
There was a problem hiding this comment.
No, I mean - this says there are 2 possible behaviors: rounding to even and truncation to zero. Aren't those conflicting?
There was a problem hiding this comment.
I suppose we can't guarantee round-to-nearest-even for all cases, because sometime it works like round to zero (or truncation in other words). DX11 have term hardware so probably it fit better here too. From DX11: "hardware is allowed to truncate results to 32-bit rather than perform round-to-nearest-even"
There was a problem hiding this comment.
ok, I was thinking about round() builtin, not general rounding.
FYI, we can't talk about "hardware" directly in the spec.
There was a problem hiding this comment.
Yea, so this is some kind of trade off.
There was a problem hiding this comment.
The reason no rounding mode was specified is because underlying implementations are unconstrained that way.
Are you trying to constrain it to exactly one of two possibilities: round-to-even and round-to-zero?
There was a problem hiding this comment.
This is just editorial PR. But I wanted to constraint it as a superset of Spir-V, MSL and DX. Or even better to specify that it is loosely round-to-nearest.
Firefox/Chrome is doing well and hope Safari will do it in the same way. But according to spec 2+2=666 is legit rounding and I think it is a good counterexample to fix this.
| @@ -6292,7 +6292,7 @@ the following exceptions: | |||
| of NaNs and infinities. | |||
| * Implementations may ignore the sign of a zero. | |||
| That is, a zero with a positive sign may behave like a zero a with a negative sign, and vice versa. | |||
| * No rounding mode is specified. | |||
| * Rounding mode is round-to-nearest even, but implementation may truncate results to zero. | |||
There was a problem hiding this comment.
The reason no rounding mode was specified is because underlying implementations are unconstrained that way.
Are you trying to constrain it to exactly one of two possibilities: round-to-even and round-to-zero?
| @@ -6310,9 +6310,6 @@ The <dfn>correctly rounded</dfn> result of the operation for floating point type | |||
|
|
|||
| </div> | |||
|
|
|||
| That is, the result may be rounded up or down: | |||
| @@ -6419,8 +6416,9 @@ However, the result may not be the same when computed in floating point. | |||
| The reassociated result may be inaccurate due to approximation, or may trigger | |||
| an overflow or NaN when computing intermediate results. | |||
|
|
|||
| An implementation may reassociate and/or fuse operations if the optimization is | |||
| at least as accurate as the original formulation. | |||
| <dfn noexport>Fusing</dfn> occur when two floating-point operation performed in one step. | |||
There was a problem hiding this comment.
The example of multiply-then-add is s less general than the original statement.
Also, the original statement constrains accuracy. So I think this part of the change is not good.
WGSL meeting minutes 2021-09-28
|
|
Thanks for review. |
