[Web] Shall we accept Uint16Array for 'float16' if Float16Array is available

[Honry]

Describe the issue

The Float16Array has been enabled by default in latest Chrome Canary, in ort-web, the float16 data type will be map to Float16Array at here now, while we are still using Uint16Array as workaround input data, thus the code will go into following exception.

tensor-impl.ts:265 Uncaught (in promise) TypeError: A float16 tensor's data must be type of function Float16Array() { [native code] }
    at new Tensor (tensor-impl.ts:265:19)

This would break all apps that are still using Uint16Array as workaround for float16, shall we accept both Uint16Array and Float16Array for a period of time?

@fs-eire, @guschmue

To reproduce

Create ORT float16 CPU tensor with Uint16Array data:

new ort.Tensor('float16', new Uint16Array([0]), [1]);

Urgency

No response

ONNX Runtime Installation

Released Package

ONNX Runtime Version or Commit ID

1.20.1

Execution Provider

'wasm'/'cpu' (WebAssembly CPU)

[fs-eire]

This is indeed a problem.

I think the behavior may need to be splitted into 2 discussions:

• for model output, the problem is ORT-web need to decide which one to use. I think we can keep the behavior for output: if Float16Array is available, we use it; otherwise use Uint16Array.
• for model input, we can loose the limit as suggested. When Float16Array is available, we should still accept Uint16Array for input data for a while.

[xenova]

Ran into this issue myself too, which #23817 aims to fix (i.e., use Float16Array if available)