onnxruntime
4c4d4923 - [XNNPACK EP] Read Gemm M from the input tensor at Compute time (#31189)

Commit
19 days ago
[XNNPACK EP] Read Gemm M from the input tensor at Compute time (#31189) Fixes #31153 `Gemm::Gemm` cached the row count from the static `NodeArg` shape, and `dim_value()` returns 0 for a symbolic dim, so `M_ = dim(0).dim_value() > 1 ? dim(0).dim_value() : 1` turned a dynamic M into 1. `Compute()` then used that cached `M_` for both the output shape and the `xnn_reshape_fully_connected_nc_*` row count, so the kernel produced a `[1, N]` output and multiplied only the first row. `Compute()` now reads M from `A->Shape()`, which is what the XNNPACK reshape API wants anyway. `M_` is removed since nothing else used it. The `transA = 1` path is unchanged: M still comes from `A->Shape()[1]` and `K_` is still passed as the row count. Verified on x86_64 Linux (Ubuntu 20.04, gcc 13, Release, `--use_xnnpack`): - The reporter's repro script fails on `Reshape` with `Input shape:{1,16}` before the change and runs clean after. - New `XnnpackEP.TestGemm_DynamicM` fails before and passes after. It feeds `[10, 3]` to a symbolic-M Gemm and compares against the CPU EP. - `onnx_test_runner -e xnnpack` on a symbolic-M Gemm with four data sets (M = 10, 1, 7, 32) against numpy-computed outputs: 3 of 4 fail before, 4 of 4 pass after. This covers re-reshaping the cached operator across runs, not just one M. - Full `onnxruntime_provider_test`: 5587 ran, 5461 passed, rest skipped, exit 0. Not verified: Android ARM64 (the reporter's platform, no device here), and the fp16 branch, which has no test coverage before or after. Both take the same one line of row-count plumbing. Two adjacent things I left alone because they are out of scope for this issue, but reviewers may want to know: `IsOnnxNodeSupported` still accepts `transA = 1`, which looks broken independently of M (for a `[K, M]` A the kernel passes `K_` as the row count against a K-input-channel operator, which only lines up when `M == K`), and it still accepts rank-1 A while the constructor indexes `shapeA->dim(1)`. Thanks to @whousemyname for the report, which pinpointed the exact line and both candidate fixes. Co-authored-by: guptaishaan <guptaishaan@users.noreply.github.com>
Author
Parents
Loading