qsmla: adapt Shared-B TransB usage to pto-spec #257 (compile fix for TileOP-API >= 748ac69) - #141
Closed
CYR-Firework wants to merge 2 commits into
Closed
CYR-Firework wants to merge 2 commits into
CYR-Firework wants to merge 2 commits into
Conversation
TileOP-API PTO-ISA#104 (01d62c4) redefined the cooperative Shared-B TransB control as a physical-storage-shape declaration per pto-spec #257 (ASL BundleMatrixSharedBPrimarySchemaLegal): TransB=0 -> physical [N, K] (K contiguous) TransB=1 -> physical [K, N] (N contiguous) QSMLA stages both K and V as SharedMatrixRight<kvdtype, kTk, kTd> (one KV token per row, D contiguous), so: - QK (Q @ K^T): the physical [kTk, kTd] layout IS the [N, K] form for the K^T operand -> drop transpose_b() (TransB=0) - PV (P @ V): the same physical layout is the [K, N] form for the V operand (N contiguous) -> add transpose_b() (TransB=1) Without this adaptation the kernel fails the compile-time effective-K and cooperative-D shape static_asserts against TileOP-API >= 748ac69. Verified with SuperScalarModel fix/gfrun-shared-tmatmul-layout-257 @ 6a60fb5 (the model-side TransB fix, de3ea07f), TileOP-API 64ef554, LLVM 10abd6e+: gfrun 4-PE on swa_small / csa_small / ori_sparse_small all 32768/32768 (100%) with max_abs bitwise identical to the pre-PTO-ISA#104 baselines. Refs: PTO-ISA/pto-spec#255, pto-spec#257, LinxISA/Linx-TileOP-API#103, LinxISA/Linx-TileOP-API#104, LinxISA/Linx-TileOP-API#122
|
Codex usage limits have been reached for code reviews. Please check with the admins of this repo to increase the limits by adding credits. |
Same convention as mega_moe_sim.cpp: write the pass value to the test-finisher address after BENCHEND so gfsim --dump-memory can complete (requires SuperScalarModel#665 finisher observation fix). Numerical verification remains gfrun R2=0. Not part of PR#141 (which only contains the TransB adaptation); this is a separate local commit for gfsim performance collection.
This was referenced Sep 16, 2026
Contributor
Author
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
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.
Summary
TileOP-API #104 (
01d62c4) redefined the cooperative Shared-BTransBcontrol as a physical-storage-shape declaration per pto-spec #257 (ASLBundleMatrixSharedBPrimarySchemaLegal):[N, K](K contiguous)[K, N](N contiguous)The QSMLA kernel still used the legacy math-transpose-flag reading, so since TileOP-API
748ac69it fails the compile-time effective-K / cooperative-D shapestatic_asserts (template_asm.hpp:4219/4232) — QSMLA is outside the microbenchmark guard coverage, so this was not caught by the daily reports.This PR adapts the 5 call sites in
quant_sparse_flash_mla.hpp. Both K and V are staged asSharedMatrixRight<kvdtype, kTk, kTd>(one KV token per row, D contiguous), so:Q @ K^T): the physical[kTk, kTd]layout IS the[N, K]form for theK^Toperand → droptranspose_b()(TransB=0) — 4 sitesP @ V): the same physical layout is the[K, N]form for theVoperand (N contiguous) → addtranspose_b()(TransB=1) — 1 siteNote the transposition itself does not disappear — under the new contract it is carried implicitly by the physical-layout declaration (TransB=0 ⇒ the engine transposes on read), which is why the numeric results below are bitwise identical.
Verification
Environment: TileOP-API
64ef554+ SuperScalarModelfix/gfrun-shared-tmatmul-layout-257@6a60fb5(the model-side TransB adaptationde3ea07f) + LLVM10abd6e+, baseline tagops-20260914+ this patch.gfrun 4-PE (
-s softcore.multiThreadNum=4, HIF8 in / BF16 out, atol=rtol=2e-2 vs CPU golden):max_abs is bitwise identical across every baseline before and after the #257 contract change (ops-20260908 → ops-20260914), confirming the adaptation direction.
Compile: 0 errors / 0 warnings for all three
IMPLs (swa_tadd_4pe/csa_tadd_4pe/ori_sparse_tadd_4pe,QSMLA_DTYPE=HIF8, embedded inputs).References
fix/gfrun-shared-tmatmul-layout-257@6a60fb5, commitde3ea07f("fix(gfrun): adapt Shared TMATMUL layout")