master

cann-robotfix(stft): 补齐 infershape 除零保护与参数有效性校验

09fc686eAdd on 9 days agoHistory

Files	Last commit	Last update
config	feat(stft): add ascend950 platform binary config Co-authored-by: east_yang<yangdong48@huawei.com> # message auto-generated for no-merge-commit merge: !4810 merge master into master feat(stft): add ascend950 platform binary config Created-by: east_yang Commit-by: east_yang Merged-by: cann-robot Description: ## 描述 <!--在这里详细描述你的改动，包括改动的原因和所采取的方法。--> 补充stft的A5 config json ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在这里提供Issue链接。--> <!-- 如果这个PR是为了解决特定的问题单，请在这里描述问题单单号。--> https://gitcode.com/cann/ops-math/issues/2548 ## 测试 <!--描述进行了哪些测试来验证你的改动。包括但不限于二级冒烟、算子泛化等。--> ## 文档更新 <!--如果这个PR包含文档的更新，请在这里指出。例如：更新了README.md文件。--> ## 类型标签 <!-- [x] 表示选中 --> - [ ] Bug修复 - [x] 新特性 - [ ] 性能优化 - [ ] 文档更新 - [ ] 其他，请描述： See merge request: cann/ops-math!4810	2 months ago
op_api	fix(docs): 修正 aclnn 头文件注释中 exector 拼写（应为 executor） Co-authored-by: gcw_LxlU8H9L<opengoodai@163.com> # message auto-generated for no-merge-commit merge: !5947 merge fix/3292-exector-typos into master fix(docs): 修正 aclnn 头文件注释中 exector 拼写（应为 executor） Created-by: gcw_LxlU8H9L Commit-by: OpenGood_WeChat;gcw_LxlU8H9L Merged-by: cann-robot Description: ## 描述 ops-math 仓 10 个两段式 aclnn 接口头文件的第二段接口 @param 注释中，参数名 executor 被拼写为 exector（少一个 u），与函数签名不一致。统一修正拼写，仅涉及注释文本，不影响任何接口与逻辑。 ## 关联的Issue 关联Issue #3292 ## 测试 - 纯注释文本修正，不涉及任何代码逻辑变化 ## 文档更新 无 ## 类型标签 <!-- [x] 表示选中 --> - [x] Bug修复 - [ ] 新特性 - [ ] 性能优化 - [ ] 文档更新 - [ ] 其他，请描述： ## AI/Agent生成声明 <!-- [x] 表示选中 --> - [x] AI辅助编写 See merge request: cann/ops-math!5947	1 month ago
CMakeLists.txt	增加A2 A3新算子支持 Co-authored-by: slx2008<shaolixin@huawei.com> # message auto-generated for no-merge-commit merge: !448 merge master into master 增加A2 A3新算子支持 Created-by: songkai111 Commit-by: slx2008 Merged-by: cann-robot Description: ## 描述 <!--在这里详细描述你的改动，包括改动的原因和所采取的方法。--> ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在这里提供Issue链接。--> <!-- 如果这个PR是为了解决特定的问题单，请在这里描述问题单单号。--> ## 测试 <!--描述进行了哪些测试来验证你的改动。包括但不限于二级冒烟、算子泛化等。--> ## 文档更新 <!--如果这个PR包含文档的更新，请在这里指出。例如：更新了README.md文件。--> ## 类型标签 <!-- [x] 表示选中 --> - [ ] Bug修复 - [ ] 新特性 - [ ] 性能优化 - [ ] 文档更新 - [ ] 其他，请描述： See merge request: cann/ops-math!448	10 months ago
stft_def.cpp	aclStft支持A5功能&优化cache机制 Co-authored-by: runqi_zhang<zhangrunqi2@huawei.com> Co-authored-by: east_yang<yangdong48@huawei.com> # message auto-generated for no-merge-commit merge: !4502 merge master into master aclStft支持A5功能&优化cache机制 Created-by: east_yang Commit-by: east_yang;runqi_zhang Merged-by: cann-robot Description: ## 描述 <!--在这里详细描述你的改动，包括改动的原因和所采取的方法。--> 一 STFT 算子新增 ASCEND950（A5）平台的 AiCore 支持； 二 将 DFT 矩阵缓存从基于"条目数上限"的简单计数策略重构为基于显存预算的 LRU 淘汰策略，并简化缓存键，从而提升缓存命中率和显存利用率，提高性能。 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在这里提供Issue链接。--> <!-- 如果这个PR是为了解决特定的问题单，请在这里描述问题单单号。--> https://gitcode.com/cann/ops-math/issues/2548 ## 测试 <!--描述进行了哪些测试来验证你的改动。包括但不限于二级冒烟、算子泛化等。--> ## 文档更新 <!--如果这个PR包含文档的更新，请在这里指出。例如：更新了README.md文件。--> ## 类型标签 <!-- [x] 表示选中 --> - [ ] Bug修复 - [x] 新特性 - [ ] 性能优化 - [ ] 文档更新 - [ ] 其他，请描述： See merge request: cann/ops-math!4502	3 months ago
stft_infershape.cpp	fix(stft): 补齐 infershape 除零保护与参数有效性校验 Co-authored-by: yourealize<chenzhanxi1@huawei.com> # message auto-generated for no-merge-commit merge: !7107 merge fix/stft-infershape-validation into master fix(stft): 补齐 infershape 除零保护与参数有效性校验 Created-by: yourealize Commit-by: yourealize Merged-by: cann-robot Description: ## 描述 修复 InferShape4STFT 在属性未校验时直接计算输出形状的问题。 - n_fft 为 1、2、3 且 hop_length 为默认值 0 时，实际步长为 0，原实现计算帧数会触发整数除零（已复现 SIGFPE）。现在在默认值换算后要求 hop_length > 0。 - 补充 n_fft > 0、输入长度已知时 n_fft <= L、默认值换算后 0 < win_length <= n_fft 的校验，失败时返回 GRAPH_FAILED。 - 将 n_fft、hop_length、win_length 和频率维度保持为 int64_t，避免属性截断导致错误输出或绕过校验。 - 输入长度未知（-1）时将输出帧数保留为 -1；补充 shape 指针检查，并先检查 window 维数再读取长度。 - 增加 25 个参数化回归用例，覆盖非法参数、默认步长为零、大整数截断、合法边界和未知输入长度。UT 文件格式按仓库提交钩子整理。 hop_length=0 和 win_length=0 按既有契约解析为默认值；对于 n_fft=1/2/3，显式传入正步长仍可成功推导。 ### 错误码整改 按用户输入错误的具体原因使用预定义错误码，并记录参数实际值与预期约束： | 场景 | 错误码 | | --- | --- | | n_fft / win_length 取值非法 | EZ0024 | | hop_length 非法（含默认值解析后为 0） | EZ0026 | | x / window 维数非法 | EZ0011 | | window 形状与 win_length 不匹配 | EZ0008 | | x / window dtype 不支持 | EZ0019 | | 缺失必填属性 n_fft | EZ0037 | ## 关联的Issue Closes #3943 https://gitcode.com/cann/ops-math/issues/3943 ## 测试 环境：CANN 9.1.0-beta.1，ascend910b host 构建。 - 修复前：通过原 host infershape 注册入口复现默认步长为零导致的 SIGFPE，以及非法参数被接受、大整数截断导致输出错误。 - cmake --build build --target ophost_math_ut -j8 编译通过。 - 使用现有 CANN 库直接编译、链接本 PR 的 test_stft_infershape.cpp、仓库公共 faker 与 host UT 入口，执行过滤器 *STFT*：**35/35 通过**（原有 10 个 + 新增 25 个）；提交钩子整理格式后已重新编译、运行。 - pre-commit run --files math/stft/op_host/stft_infershape.cpp math/stft/tests/ut/op_host/test_stft_infershape.cpp 通过，包含 clang-format 与 OAT 检查。 - git diff --check 通过。 统一 host UT 构建入口在下载 backport-CVE-2025-0838.patch 时遇到 SSL 错误，因此本地采用上述现有 CANN 库直接链接方式完成本次 infershape UT 验证。 - 错误码整改后，按原 CMake 编译参数重新编译并链接 host 库，35/35 infershape UT 通过。开启原生运行日志，实际确认 ErrorManager 上报 EZ0008、EZ0011、EZ0024、EZ0026、EZ0037，所执行用例未上报 EZ9999；pre-commit 与 OAT 检查通过。 ## 文档更新 参数校验依据现有 STFT README 与 API 层约束：n_fft > 0、n_fft <= L、有效步长大于 0、0 < win_length <= n_fft。 ## 类型标签 - [x] Bug修复 - [ ] 新特性 - [ ] 性能优化 - [ ] 文档更新 - [ ] 其他，请描述： See merge request: cann/ops-math!7107	9 days ago
stft_tiling.cpp	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 months ago
stft_tiling.h	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 months ago
stft_tiling_align.cpp	修复STFT算子int32/uint32溢出风险 Co-authored-by: east_yang<yangdong48@huawei.com> # message auto-generated for no-merge-commit merge: !3133 merge master into master 修复STFT算子int32/uint32溢出风险 Created-by: east_yang Commit-by: east_yang Merged-by: cann-robot Description: ## 描述 <!--在这里详细描述你的改动，包括改动的原因和所采取的方法。--> 排查整改STFT可能存在的int32、uint32溢出风险 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在这里提供Issue链接。--> <!-- 如果这个PR是为了解决特定的问题单，请在这里描述问题单单号。--> ## 测试 <!--描述进行了哪些测试来验证你的改动。包括但不限于二级冒烟、算子泛化等。-->  ## 文档更新 <!--如果这个PR包含文档的更新，请在这里指出。例如：更新了README.md文件。--> ## 类型标签 <!-- [x] 表示选中 --> - [x] Bug修复 - [ ] 新特性 - [ ] 性能优化 - [ ] 文档更新 - [ ] 其他，请描述： See merge request: cann/ops-math!3133	5 months ago
stft_tiling_base.cpp	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 months ago
stft_tiling_base.h	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 months ago
stft_tiling_generalized.cpp	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	2 months ago