maca opt

docs/ASCEND.md

@@ -45,12 +45,21 @@ python3 -c "from flagsparse.sparse_operations import _common as c; print(c._back
 setsid timeout -s KILL 43200 python3 -u run_flagsparse_pytest.py \
   --phase both --mode normal --delivery-only --gpus 6,7 --timeout 3600 \
   --benchmark-input /home/matrix --benchmark-warmup 5 --benchmark-iters 20 \
+  --h800-reference \
   --results-dir pytest_results_ascend_delivery \
   > pytest_results_ascend_delivery.log 2>&1 < /dev/null &
 
 python3 tools/delivery_table.py pytest_results_ascend_delivery   # 跑完后：20 行结果，缺变体时退出码为 1
 ```
 
+**`--h800-reference`（不带值）**：没有 PyTorch-NPU 基线的行，用仓库自带的 H800 结果按带宽折算出加速比
+（H800 cuSPARSE 时间 × 3050/1600；H800 也没有 cuSPARSE 时间的 `sddmm_csr_f16` 用 H800 PyTorch），交付表里标
+只显示数字（`--show-baseline` 可看来源）。**有 PyTorch-NPU 基线的行不受影响。** 按 10-11 全量结果预演：有加速比的变体
+41 → 63，补上的 22 个大多在 0.001x–0.06x——昇腾上这些变体每次调用 0.3–2.4 秒（`timed=call`，PyTorch-NPU 自己
+在 legacy spmm_csr 上也要 20–44 ms），数是真的，不是折算出错。`spgemm_csr` 以前走探测脚本、测的是合成规模，
+现在改为 `tests/test_spgemm.py` 在交付矩阵上测（**未在 NPU 上跑过**），重跑后才能折算。见
+[`H800_REFERENCE.md`](H800_REFERENCE.md)。
+
 **两个 timeout 不是一回事**：外层 `timeout -s KILL 43200` 是**整条命令**的总限时（12 小时），到点
 直接强制杀掉整个进程；`--timeout 3600` 是**每个子任务**的限时，大多数算子是每个阶段（精度、性能）
 各 3600 秒，`spmm_csr` / `sddmm_csr` 的性能是逐矩阵路径，则是每个矩阵 3600 秒。外层必须写，

docs/ILUVATAR.md

@@ -201,7 +201,8 @@ setsid timeout -s KILL 14400 python3 -u run_flagsparse_pytest.py \
   `allclose` 里面）；
 - **多卡机器先确认 `--gpus 0` 真的生效**：runner 靠 `CUDA_VISIBLE_DEVICES` 选卡，CoreX 是否遵守这个
   变量未验证，跑起来用 `ixsmi` 看负载落在哪张卡；
-- **不用跑 `spsv` / `spsm` / `spgemm`**，它们不在交付清单里，`--delivery-only` 也选不到。
+- **不用跑 `spsv` / `spsm`**，它们不在交付清单里，`--delivery-only` 也选不到。`spgemm_csr` 现在是交付变体
+  （`spgemm_csr_f32_int_non_non`），命令里用 `spgemm_csr=--dtypes float32` 只跑 f32（本卡 fp64 不可用）。
 
 ---
 
@@ -231,6 +232,7 @@ setsid timeout -s KILL 43200 \
     --op-benchmark-args='spmm_csr=--dtypes float16,float32' \
     --op-benchmark-args='spmm_coo=--dtypes float16,float32' \
     --op-benchmark-args='sddmm_csr=--dtype float32' \
+    --op-benchmark-args='spgemm_csr=--dtypes float32' \
     --results-dir pytest_results_iluvatar_delivery \
   > pytest_results_iluvatar_delivery.log 2>&1 < /dev/null &
 ```
@@ -353,11 +355,14 @@ speedup_vs_h800_scaled  = h800_scaled_ms / T_FlagSparse@BI-V150      # 1.0 = 和
 ```
 
 - 自带的数据在 [`conf/h800_reference.json`](../conf/h800_reference.json)（约 1 MB，一个文件），说明见
-  [H800_REFERENCE.md](H800_REFERENCE.md)：H800 ×8，提交 `47a441e`（那轮是脏工作树），17 个算子的 7801 行，
+  [H800_REFERENCE.md](H800_REFERENCE.md)：2026-10-14 起是 H800 ×8 上**全部 65 个变体**的一轮（提交 `643e9c6`，
+  脏工作树），13 个交付算子；spsv/spsm/bsr/bell 新一轮没测，沿用 09-22 那轮（`47a441e`）并在文件里标了来源。共 20 个算子 4645 行，
   每行保留算例键、各 `*_ms` 时间、加速比和状态列。想换成自己的一轮 H800 结果，`--h800-reference 目录或json文件`
   都行；重新生成用 `python3 tools/h800_reference.py <H800 结果目录>`。
-- **有一处覆盖不到**：这轮 H800 数据里 `spmm_bsr`、`spmm_bell` 没有 cuSPARSE 时间（当时基线只有 CuPy，没有
-  BSR / Blocked-ELL 的库），所以这两个算子没有折算基线，行保持 `N/A`；`spmm_csc` 只有 240/720 行有。
+- **H800 没有 cuSPARSE 时间的**：65 个交付变体里只有 `sddmm_csr_f16_int_non_non_row`（cuSPARSE SDDMM 不支持
+  fp16），改用 H800 上 PyTorch 的时间折算。非交付的 `spmm_bsr`、`spmm_bell` 两者都没有。
+  按 10-09 的天数结果预演，换成新参照后有加速比的变体从 25 个变为 55 个；剩下的是不测的 fp64 9 个，和那轮因 TLE
+  编译失败全部 FAIL 的 `spgemm_csr`（已修，见 `debug/ILUVATAR.md` 改动记录，重跑后可折算）。
 - 每行的 `performance.csv` 会多 5 列：`h800_vendor_ms`（H800 上 cuSPARSE 的用时）、`h800_scaled_ms`（折算后的时间，
   即基线 1）、`h800_scaled_fs_ms`（天数上 FlagSparse 的实测）、`speedup_vs_h800_scaled`（加速比）、`h800_scaled_card`（用的卡）。
   `summary.json` / `summary.csv` 里交付变体的 speedup 就是这个数，`delivery_table.py` 也照常显示。

docs/MACA.md

@@ -56,13 +56,20 @@ setsid timeout -s KILL 39600 python3 -u run_flagsparse_pytest.py \
   --phase both --mode normal --delivery-only --gpus 0 --timeout 4500 \
   --benchmark-input /root/gcx/matrix --benchmark-warmup 5 --benchmark-iters 20 \
   --op-benchmark-args='sddmm_csr=--no-cusparse' \
+  --h800-reference \
   --results-dir pytest_results_metax_delivery \
   > pytest_results_metax_delivery.log 2>&1 < /dev/null &
 ```
 
 - `--op-benchmark-args='sddmm_csr=--no-cusparse'`：C550 上没有可用的厂商稀疏库，且 SDDMM 的
   `torch.sparse.sampled_addmm` 结果还是错的（7.3 节），因此只对 SDDMM 禁用该参考并改用 PyTorch。
   `--benchmark-args` 会广播给所有性能脚本，而其他脚本不一定接受 `--no-cusparse`，所以用逐算子的形式；
+- `--h800-reference`（不带值）：没有任何基线的行（例如 SDDMM 的 q4 变体，或本机 baseline 校验失败的行），
+  用仓库自带的 H800 结果按带宽折算出加速比（`h800_scaled_ms = T_cuSPARSE@H800 × 3050/1440`），交付表里只显示数字；
+  要看哪些是折算的用 `delivery_table.py --show-baseline`。**有 PyTorch 基线的行不受影响。** 这是估算，不是厂商实测，汇报时要注明；
+  `sddmm_csr_f16_int_non_non_row` 在 H800 上没有 cuSPARSE 时间（cuSPARSE SDDMM 不支持 fp16），改用 H800 上
+  PyTorch 的时间折算（`--show-baseline` 显示 `h800_pytorch_scaled`；C550 自己的 `sampled_addmm` 结果是错的，7.3 节）。
+  口径和覆盖见 [`H800_REFERENCE.md`](H800_REFERENCE.md)。
 - `--timeout 4500`：`--delivery-only` 已把 spmv/spmm 收窄到 int32 + non，但 **SDDMM 的 4 个 K 值
   不收窄**（交付名里没有 K），按 30 个矩阵实测推算全量至少 3660 秒（7.4 节；现在交付只用 10 个矩阵，这个数会小一截，没有重新实测）。只想快速出数，可以改用
   `--timeout 1200 --op-benchmark-args='sddmm_csr=--k 64'`，但那样 SDDMM 的加速比只含 K=64，和 CUDA 等
@@ -606,6 +613,31 @@ PYTHONPATH=src python -u run_flagsparse_pytest.py --phase both --mode normal --g
 
 该命令在前台运行；如需脱离终端，可由调用方以 `setsid` 或 `tmux` 包裹，命令本身不依赖后台参数。
 
+### 7.3.1 SpGEMM 本机 PyTorch CSR baseline
+
+MACA 的矩阵 runner 在 `FLAGSPARSE_MACA_VENDOR=torch` 且默认 SciPy 精度参考下，独立计时
+`torch.sparse.mm(A_csr, B_csr)`，支持 float32/float64。CSR 描述符构造在 baseline 计时窗口外；
+FlagSparse 沿用原有单次调用口径，包含 prepare 和输出写回，不因接入 baseline 改变计时范围。
+两侧使用相同输入、warmup 和 iters。基线计时后的输出必须通过 SciPy 校验，才填入 `pytorch_ms`
+及 `triton_speedup_vs_pytorch`；校验失败或调用异常只影响 baseline，不替代算子的 SciPy 精度判定。
+CSV 的 `pytorch_baseline_status`、`pytorch_baseline_format`、`pytorch_baseline_max_error`
+和 `pytorch_reason` 记录基线状态；原有 `pt_status` 在默认参考下仍表示 FlagSparse 对 SciPy 的精度结果。
+`--no-cusparse` 不禁用此 PyTorch baseline；显式设置 `FLAGSPARSE_MACA_VENDOR=none` 才不测本机基线。
+
+```bash
+env PYTHONPATH=src FLAGSPARSE_BACKEND=metax FLAGSPARSE_MACA_VENDOR=torch \
+  python3 -u run_flagsparse_pytest.py \
+  --ops spgemm_csr --phase both --mode normal --gpus 0 --timeout 2400 \
+  --benchmark-input tests/data --benchmark-warmup 5 --benchmark-iters 20 \
+  --results-dir results_metax_spgemm_<日期>
+```
+
+本节 SpGEMM 只使用本机 PyTorch CSR baseline，不开启 H800 折算。MACA 的 float32/float64
+计算路径为纯 Triton：metadata、行内排序归并、长行全局哈希、CSR 前缀扫描和结果压紧均不依赖
+TLE，也不调用 `torch.sparse.mm` 或旧的 PyTorch ESC。PyTorch 仅用于存储分配和独立 baseline；
+公共接口仍执行原有输入校验、输入 contiguous 和 out 写回。
+CUDA、ROCm 及其他后端的 baseline 路径不变。
+
 ### 7.4 交付性能：只跑交付范围（2026-09-18 实测）
 
 7.1–7.3 是**全量** sweep。交付的 20 个变体只要 `int32` 索引和 `non` 操作，而默认 sweep 远大于此，

docs/MUSA.md

@@ -45,10 +45,21 @@ mthreads-gmi                          # 单卡；跑之前确认没有别的任
 ```bash
 setsid timeout -s KILL 43200 python3 -u run_flagsparse_split_delivery.py \
   --mode normal --benchmark-input /root/gcx/matrix --timeout 3600 \
+  --h800-reference \
   --results-dir pytest_results_mthreads_split \
   > pytest_results_mthreads_split.log 2>&1 < /dev/null &
 ```
 
+- `--h800-reference`（不带值）：muSPARSE 不支持、标 `NoBaseline` 的变体（2026-10-09 那轮是 26 个），用仓库自带的
+  H800 结果按带宽折算出加速比（H800 时间 × 3050/1370），交付表里只显示数字（`--show-baseline` 可看来源）。**muSPARSE 测得到的
+  变体不受影响。** 加了这个开关，pytest 那一半会从只跑精度变成**精度 + 性能**（多一轮 Python 性能，耗时会明显变长），
+  因为 C API 的规模（SpMM `n=8`、SDDMM `k=16/64`、向量类按矩阵）在 H800 上没有对应数据，而 Python 侧和 H800 参照
+  是同一个 benchmark、同样规模。合并时按顺序取：① C API 有 muSPARSE 基线 → C API；② Python 侧有折算加速比 →
+  Python（条目里 `source: python`，原 C API 结果留在 `capi_performance`）；③ 否则用 C API 时间对 H800 同变体同矩阵
+  折算（只有 SpMV 类能对上）。日志会打印三类各补了多少、还剩哪些。`sddmm_csr_f16` 在 H800 上没有 cuSPARSE 时间，
+  用 H800 PyTorch 折算。是估算，不是厂商实测，汇报时要注明；见
+  [`H800_REFERENCE.md`](H800_REFERENCE.md)。
+
 `--timeout` 同时传给 pytest 的每个算子阶段和 C API 的 CTest（`-DFLAGSPARSE_CTEST_TIMEOUT`）。
 首次运行会从零构建 C API（`capi/build`），配置日志里应当出现
 `ctest baseline: MUSA -> /usr/local/musa/lib/libmusparse.so`；已经构建过可加 `--skip-capi-build`。