From adbb6ed028c39d145c38203b44d5bf83f79128cf Mon Sep 17 00:00:00 2001 From: Digant Desai Date: Tue, 3 Nov 2026 06:24:27 -0800 Subject: [PATCH] [executorch][native] Suggest rounding to nearest when engines narrow values Pull Request resolved: https://github.com/pytorch/executorch/pull/24364 Rounding toward zero when narrowing f32 to f16, which Vulkan and WebGPU allow, biases every stored value toward zero, and the bias compounds across layers. The README suggests rounding to nearest, ties to even, as eager does. Authored with Claude Code. @bypass-github-export-checks @bypass-github-pytorch-ci-checks @bypass-github-executorch-ci-checks ghstack-source-id: 463657754 @exported-using-ghexport Differential Revision: [D128254885](https://our.internmc.facebook.com/intern/diff/D128254885/) --- backends/native/README.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/backends/native/README.md b/backends/native/README.md index 8a2d76ce20a..d3c9e87f283 100644 --- a/backends/native/README.md +++ b/backends/native/README.md @@ -145,6 +145,14 @@ an engine through the interfaces in `runtime/engine/Engine.h`: An engine rejects a method whose semantics it cannot fully honor. +Engines need not match eager bit for bit: accumulation precision and order, +fused multiply-add, and the accuracy of functions such as `exp` are up to each +engine. As a guideline, an engine should round to nearest when it narrows a +value for storage, with ties to even between floating-point types (f32 to f16 or +bf16), as eager does. Rounding toward zero, which some GPU APIs allow, biases +every stored value toward zero, and the bias compounds across layers instead of +averaging out. + | Engine | Source | Notes | | --- | --- | --- | | Vulkan | `runtime/vulkan/` | Builds on the ET-VK `ComputeGraph` and shaders. |