Skip to content

Add bfloat16 and float8e4m3 to the spec - #956

Open
mklimenko-nv wants to merge 1 commit into
webmachinelearning:mainfrom
mklimenko-nv:low-precision-fp-spec
Open

mklimenko-nv wants to merge 1 commit into
webmachinelearning:mainfrom
mklimenko-nv:low-precision-fp-spec

Conversation

@mklimenko-nv

@mklimenko-nv mklimenko-nv commented Sep 14, 2026

Copy link
Copy Markdown

This PR adds WebNN spec wording to support bfloat16 and float8e4m3, according to #938

Detailed changes:

  • MLOperandDataType: new values "bfloat16" and "float8e4m3", plus a definition list describing every value. float8e4m3 is the OCP OFP8 E4M3 encoding (1/4/3 bits, bias 7, no infinities, max 卤448, NaN = S.1111.111), mirroring the PyTorch float8_e4m3fn and ONNX FLOAT8E4M3FN. Neither new type is a required data type for any operation, support is discoverable through opSupportLimits().
  • Per-operator tables: bfloat16 is added to the allowed data types wherever float16 is allowed. The required columns are untouched. float8e4m3 is allowed on dequantizeLinear (input, zeroPoint), quantizeLinear (zeroPoint, output) and cast, and is implicitly allowed on operands whose allowed types are any. It is intentionally not listed on compute operators: fp8 compute is expressed through the Q/DQ pattern and realized by backend fusion, which a Note next to the enum spells out.
  • cast(): the behavior table gains bfloat16 and a float8e4m3 target column. Conversions to float8e4m3 saturate (out-of-range and infinite values become 卤448, NaN is preserved), matching OFP8's saturating mode and the ONNX Cast default. NaN handling is now stated in every float-source cell.
  • ConvertToFloat (used for MLNumber casting) takes the data type instead of a bit length and handles the two new formats, RNE and saturation match OFP8 1.1 Appendix A.
  • quantizeLinear / dequantizeLinear: states the type promotion (arithmetic happens in the scale/input float type) and the float8 formula cast(input / scale + cast(zeroPoint, input.dataType), zeroPoint.dataType). The quantizeLinear emulation branches on integer vs. floating point output and clamps to the output type's range instead of a hardcoded 0...255. A note points out that fp8 quantization is typically symmetric (zeroPoint = zeros).
  • Buffer compatibility appendix: bfloat16 <-> Uint16Array, float8e4m3 <-> Uint8Array (native-endian bit patterns; Uint8Array remains the generic view for any type). validate buffer with descriptor needed no change since it is table-driven. The stale "Float16Array is Stage 3" note is refreshed.
  • Bibliography: adds OCP OFP8 Revision 1.1 (January 2026).

Also fixed while here: the isNaN/isInfinite tensor-limits table said any while the method steps restricted to floating point types; the table now matches the steps.


Preview | Diff

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants