wgsl: Convert quantizeToI32/U32 to use Math.trunc

[zoddicus]

Another small bump (~5%) to be gained through using a builtin instead of trampolining through a TypedArray.

---

Requirements for PR author:

• All missing test coverage is tracked with "TODO" or .unimplemented().
• New helpers are /** documented */ and new helper files are found in helper_index.txt.
• Test behaves as expected in a WebGPU implementation. (If not passing, explain above.)

Requirements for reviewer sign-off:

• Tests are properly located in the test tree.
• Test descriptions allow a reader to "read only the test plans and evaluate coverage completeness", and accurately reflect the test code.
• Tests provide complete coverage (including validation control cases). Missing coverage MUST be covered by TODOs.
• Helpers and types promote readability and maintainability.

When landing this PR, be sure to make any necessary issue status updates.

[ben-clayton]

Despite the function's comment, quantizeToI32 wasn't rounding to closest, but was rounding towards zero:

const F = 0.7;

const quantizeToI32Data = new Int32Array(new ArrayBuffer(4));
quantizeToI32Data[0] = F;
var message = `${quantizeToI32Data[0]}, ${Math.round(F)}`;

console.log(message)

This is a change of behaviour. Have you checked that all the places that call this expect the new behaviour?

[zoddicus]

Changed these to use Math.trunc to replicate the behaviour. I have run all of the tests under webgpu:shader,execution,expression,* and the unittests, so I think this should be fine.

[jiangzhaoming]

The spec said In other words, floating point to integer conversion rounds toward zero, then saturates in the target type.

On the other hand, if all tests are passed no matter using Math.round or Math.trunc, does it imply that some tests on this fp-int conversion is missing?

[ben-clayton]

Approving this change, but I agree with:

On the other hand, if all tests are passed no matter using Math.round or Math.trunc, does it imply that some tests on this fp-int conversion is missing?

It sounds like we could do with some more unit tests, and probably some more CTS cases.

[zoddicus]

Looking at the call sites of these functions, since it has been awhile since I worked with this code. They are only being used as filtering/cleanup of initial input values, i.e. I want you to run CTS on this set of numbers, and these functions are used to fix up the values to be the correct type of integer. They are not being used to adjust things internally in the framework to make sure that results comply with the WGSL rounding rules.

This is why the specific rounding rule doesn't affect if the test is passing, changing it just changes the set of inputs being tested on, not the expected result for a specific value.