| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
refactor(stft): rename op_kernel/stft.h to stft_kernel.h Co-authored-by: east_yang<yangdong_js@163.com> # message auto-generated for no-merge-commit merge: !5843 merge rename-stft-kernel-header into master refactor(stft): rename op_kernel/stft.h to stft_kernel.h Created-by: east_yang Commit-by: east_yang Merged-by: cann-robot Description: ## 关联 issue closes #3247 ## Problem math/stft 是全仓唯一一个 op_kernel 头文件与 op_host/op_api 头文件同名的算子： - math/stft/op_kernel/stft.h（AICore kernel 入口头，guard STFT_H） - math/stft/op_host/op_api/stft.h（host 侧 l0op 接口头，guard OP_API_INC_LEVEL0_STFT_H_） 当编译单元的 include path 同时包含两个目录时，#include "stft.h" 依路径顺序解析到不同文件，产生误引用甚至编译失败。其余算子的 kernel 侧头文件均带区分后缀（abs_struct.h 等），仅 stft 存在此冲突。 ## Change - op_kernel/stft.h → op_kernel/stft_kernel.h（git mv 保留历史，rename 相似度 99%） - include guard：STFT_H → STFT_KERNEL_H，文件头注释补充重命名说明 - 全仓唯一引用点 op_kernel/stft.cpp 的 include 同步更新；op_host/op_api 侧引用保持不变 - 命名与 kernel 侧既有风格一致（stft_plan_mul.h、stft_tiling.h） ## Verification - bash build.sh --opkernel --soc=ascend910b --ops=stft 编译通过 - bash build.sh --pkg --soc=ascend910b --ops=stft 完整 run 包构建通过（host + kernel 全链） - STFT kernel 产物 hash（STFT_1ea4bd0e...）与重命名前一致，纯重命名无功能影响 See merge request: cann/ops-math!5843 | 1 个月前 | |
fix(stft): 修复Cube matmul FIX写GM与Gather MTE2读GM流水线竞态导致的精度偶现失败 Co-authored-by: east_yang<yangdong48@huawei.com> # message auto-generated for no-merge-commit merge: !5236 merge fix-stft-fix-mte2 into master fix(stft): 修复Cube matmul FIX写GM与Gather MTE2读GM流水线竞态导致的精度偶现失败 Created-by: east_yang Commit-by: east_yang Merged-by: cann-robot Description: fix #2868 (第二轮修复，续已合入的 PR #5071) ### 问题 泛化批跑（-mt 20）场景下偶现 complex 输入用例（如 case918/1017，complex64 window + normalized=True + onesided=False）精度失败，NPU 输出为 1e33 量级脏数据；单跑同数据（atk 固定 seed）必 PASS。summary 显示 1100 用例中 2 例失败、通过率 99.82%。 ### 根因 PR #5071 修复了 SplitWindows(MTE3写GM) → Cube matmul 的竞态，但 matmul→Gather 之间仍存在对称竞态：StftMatmul 的 IterateAll 发射 Cube matmul 后，GatherRealAndImag 立即通过 MTE2 读取 matmul 输出 workspace，缺少 FIX 流水线写 GM 完成的同步保护。批跑并发时读到 FIX 未写完的脏内存。 ### 修复 在 fp32 与 complex64 两路径的 StftMatmul 与 GatherRealAndImag 之间增加 HardEvent::FIX_MTE2 的 SetFlag/WaitFlag 同步（与 PR #5071 的 MTE3_S 修复对称）： - op_kernel/stft_generalized.h - op_kernel/stft_generalized_complex.h ### 验证（Ascend 950PR） - case918/1017 参数构造复现脚本全 PASS - 20 并发压测：修复前 2/100 卡死，修复后 100/100 PASS、0 卡死，单轮耗时 76s → 20s - error_case_stft 5/5 PASS；mini json atk 10 连跑全 PASS See merge request: cann/ops-math!5236 | 1 个月前 | |
fix(stft): 修复Cube matmul FIX写GM与Gather MTE2读GM流水线竞态导致的精度偶现失败 Co-authored-by: east_yang<yangdong48@huawei.com> # message auto-generated for no-merge-commit merge: !5236 merge fix-stft-fix-mte2 into master fix(stft): 修复Cube matmul FIX写GM与Gather MTE2读GM流水线竞态导致的精度偶现失败 Created-by: east_yang Commit-by: east_yang Merged-by: cann-robot Description: fix #2868 (第二轮修复，续已合入的 PR #5071) ### 问题 泛化批跑（-mt 20）场景下偶现 complex 输入用例（如 case918/1017，complex64 window + normalized=True + onesided=False）精度失败，NPU 输出为 1e33 量级脏数据；单跑同数据（atk 固定 seed）必 PASS。summary 显示 1100 用例中 2 例失败、通过率 99.82%。 ### 根因 PR #5071 修复了 SplitWindows(MTE3写GM) → Cube matmul 的竞态，但 matmul→Gather 之间仍存在对称竞态：StftMatmul 的 IterateAll 发射 Cube matmul 后，GatherRealAndImag 立即通过 MTE2 读取 matmul 输出 workspace，缺少 FIX 流水线写 GM 完成的同步保护。批跑并发时读到 FIX 未写完的脏内存。 ### 修复 在 fp32 与 complex64 两路径的 StftMatmul 与 GatherRealAndImag 之间增加 HardEvent::FIX_MTE2 的 SetFlag/WaitFlag 同步（与 PR #5071 的 MTE3_S 修复对称）： - op_kernel/stft_generalized.h - op_kernel/stft_generalized_complex.h ### 验证（Ascend 950PR） - case918/1017 参数构造复现脚本全 PASS - 20 并发压测：修复前 2/100 卡死，修复后 100/100 PASS、0 卡死，单轮耗时 76s → 20s - error_case_stft 5/5 PASS；mini json atk 10 连跑全 PASS See merge request: cann/ops-math!5236 | 1 个月前 | |
refactor(stft): rename op_kernel/stft.h to stft_kernel.h Co-authored-by: east_yang<yangdong_js@163.com> # message auto-generated for no-merge-commit merge: !5843 merge rename-stft-kernel-header into master refactor(stft): rename op_kernel/stft.h to stft_kernel.h Created-by: east_yang Commit-by: east_yang Merged-by: cann-robot Description: ## 关联 issue closes #3247 ## Problem math/stft 是全仓唯一一个 op_kernel 头文件与 op_host/op_api 头文件同名的算子： - math/stft/op_kernel/stft.h（AICore kernel 入口头，guard STFT_H） - math/stft/op_host/op_api/stft.h（host 侧 l0op 接口头，guard OP_API_INC_LEVEL0_STFT_H_） 当编译单元的 include path 同时包含两个目录时，#include "stft.h" 依路径顺序解析到不同文件，产生误引用甚至编译失败。其余算子的 kernel 侧头文件均带区分后缀（abs_struct.h 等），仅 stft 存在此冲突。 ## Change - op_kernel/stft.h → op_kernel/stft_kernel.h（git mv 保留历史，rename 相似度 99%） - include guard：STFT_H → STFT_KERNEL_H，文件头注释补充重命名说明 - 全仓唯一引用点 op_kernel/stft.cpp 的 include 同步更新；op_host/op_api 侧引用保持不变 - 命名与 kernel 侧既有风格一致（stft_plan_mul.h、stft_tiling.h） ## Verification - bash build.sh --opkernel --soc=ascend910b --ops=stft 编译通过 - bash build.sh --pkg --soc=ascend910b --ops=stft 完整 run 包构建通过（host + kernel 全链） - STFT kernel 产物 hash（STFT_1ea4bd0e...）与重命名前一致，纯重命名无功能影响 See merge request: cann/ops-math!5843 | 1 个月前 | |
fix(stft): 修复STFT算子MTE3与Cube matmul流水线竞态导致的精度偶现失败 Co-authored-by: east_yang<yangdong48@huawei.com> # message auto-generated for no-merge-commit merge: !5071 merge master into master fix(stft): 修复STFT算子MTE3与Cube matmul流水线竞态导致的精度偶现失败 Created-by: east_yang Commit-by: east_yang Merged-by: cann-robot Description: ## 问题背景 fix #2868 https://gitcode.com/cann/ops-math/issues/2868 https://gitcode.com/cann/ops-math/issues/2778 STFT 算子在 atk 批跑精度测试中偶现失败：单跑成功、批跑失败用例不固定，失败时 NPU 输出在部分行的尾部帧输出 0。详细分析见 issue #2868。 ## 根因 STFT AICore kernel 内 **MTE3（UB→GM 异步拷贝，Vector 流水线）与 Cube matmul（读 GM，Cube 流水线）之间缺少跨流水线同步**。三处竞态点： 1. StftPlanMul::Process()：plan×window 写 plan workspace 后无等待，主算子 matmul 立即读 2. STFTGeneralized::Process()：SplitWindows 写 splitWindow workspace 后无等待 3. STFTGeneralizedComplex::Process()：complex 路径同样问题 首次调用时 workspace 为新分配（全 0），matmul 抢先读到未写入数据 → 输出 0；后续调用残留上次正确数据掩盖竞态 → 偶现特性。 ## 修复内容 三处 MTE3 写 workspace 后、Cube matmul 读取前插入 HardEvent::MTE3_S 事件同步： cpp event_t eventIdMTE3ToS = static_cast<event_t>(GetTPipePtr()->FetchEventID(HardEvent::MTE3_S)); SetFlag<HardEvent::MTE3_S>(eventIdMTE3ToS); WaitFlag<HardEvent::MTE3_S>(eventIdMTE3ToS); 顺带清理 stft_tiling_base 中冗余代码：删除从未使用的 l1Size/l0ASize/l0BSize/l0CSize 成员（其中 l0A/B/C 获取时误用 CoreMemType::UB）及重复的 l1SizePlatform 赋值。 ## 验证 Ascend950PR 环境验证： - 修复前：atk 批跑 5 用例通过率约 60%，失败用例轮换 - 修复后：**10 轮 × 5 用例 = 50/50 全部 PASS**；25 次逐次调用（每次不同输入）全部与 CPU 参考一致（max_diff < 1e-4），零值消失 - pre-commit 检查全部通过（clang-format/codespell/OAT 合规） See merge request: cann/ops-math!5071 | 2 个月前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 2 个月前 |