fix(musa): backport torch.mm/bmm out_dtype semantics (torch_musa < 2.13.0) - #116
Merged
Merged
Conversation
yeahdongcn
force-pushed
the
xd/musa-100046-mm-out-dtype-created
branch
from
September 20, 2026 07:57
42acb8d to
61bae3d
Compare
yeahdongcn
changed the title
yeahdongcn
force-pushed
the
xd/musa-100046-mm-out-dtype-created
branch
from
September 20, 2026 09:51
61bae3d to
e3f3cb5
Compare
yeahdongcn
marked this pull request as ready for review
September 20, 2026 09:51
yeahdongcn
force-pushed
the
xd/musa-100046-mm-out-dtype-created
branch
from
September 20, 2026 10:03
e3f3cb5 to
04c06bb
Compare
|
LGTM |
…13.0) On the affected torch_musa stack the vendored `aten::mm.dtype` / `aten::bmm.dtype` overloads are registered but do not write their result: `torch.mm(..., out_dtype=)` returns a correctly shaped fp32 tensor that is silently all zeros, and `bmm` returns non-zero wrong values. Measured on 2.11.0.post1+musa5.2.0; plain and invalid arguments behave correctly, so only the promoted path is affected. The wrappers are armed below `2.13.0`, the release torch_musa committed to fix the overloads in - a vendor commitment, not a measurement of ours - and nothing is installed from 2.13.0 on. An unknown or unparsable __version__ ranks lowest in version_of and therefore stays armed, so a stack we cannot read is never assumed fixed. Once 2.13.0 is released and verified fixed here the shim is deleted; if the fix slips the bound moves to the newly committed release. The backport promotes the operands to fp32 and accumulates there, reusing the plain overloads, so it assumes nothing about the vendor kernel; every gate compares against an inline literal (no version constants), invalid dtype combinations are forwarded verbatim so the vendor error text stays byte-identical, and `_version.version_of` stays as the parse-failure-safe comparator. Correctness is decided per process by a three-valued, lazy probe: it runs only on the first promoted call, caches only deterministic verdicts, warns once when it cannot decide, and refuses to probe inside a CUDA/MUSA graph capture (the verdict then resolves on the next eager call, which is why a graph captured before the first eager call must be re-captured on a fixed stack). Verified on S5000: focused 307 passed/4 skipped, full 554 passed/19 skipped, gate table 2.10.0..2.12.0 armed and 2.13.0+ unarmed, capture safety, a no-shim control showing the all-zero/wrong-value defect, and the end-to-end A/B with byte-identical outputs (COMPARABLE, +0.044 ms). See the ticket for the full evidence list. Version unified on 0.1.89 as a true replace-all: every `0.1.x` literal in the tree now reads 0.1.89, including the C++ mirror in csrc/ops.h (was 0.1.0), the recorded benchmark history entry (was 0.1.86) and the example extension setup (was 0.1.0); a tree-wide grep for any other `0.1.x` literal returns nothing.
yeahdongcn
force-pushed
the
xd/musa-100046-mm-out-dtype-created
branch
from
September 21, 2026 02:08
04c06bb to
62a32ec
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What / Why
torch.mm/torch.bmmwithout_dtype=returned a correctly shaped fp32 tensor on MUSA whose contents were never written:mmsilently all zeros,bmmnon-zero wrong values. Measured ontorch_musa 2.11.0.post1+musa5.2.0; CUDA accumulates in fp32, so MUSA silently disagreed with CUDA.Change
2.13.0, the release torch_musa committed to fix the overloads in (a vendor commitment we have not verified); an unknown or unparsable__version__ranks lowest and stays armed.Verification
Focused
307 passed / 4 skipped, full544 passed / 19 skippedon S5000; gate table2.10.0..2.12.0armed,2.13.0/2.13.0.post1unarmed,not-a-versionarmed; two-tree branch diffPARITY_IDENTICAL; independent MUSA recheck ingenerated/MUSA-100046/verify-2026-09-20/, end-to-end A/B with byte-identical outputs.Not covered / notes
*_Dtypeoverload keep raising onout_dtype=; that is the binding's contract, not a defect this repairs.2.13.0commitment is unverified by us: if the fix does not land, a>= 2.13.0stack installs no wrapper and the silent zeros can return. The compatibility table records this, and the shim is deleted once2.13.0is verified fixed.