文件最后提交记录最后更新时间
【refactor】: 使用Extend封装函数合并部分ApiCall类 Co-authored-by: chenyukai<chenyukai4@huawei.com> # message auto-generated for no-merge-commit merge: !399 merge br_c00826661_apicall0518 into develop 【refactor】: 使用Extend封装函数合并部分ApiCall类 Created-by: chenyukai Commit-by: chenyukai Merged-by: cann-robot Description: # Pull Request ## 描述 1. 将UnaryApiTmpV2Call合并到UnaryApiTmpCall,统一使用Extend wrapper 2. 删除冗余的ApiCall类(binary_tmp_api_call_v2, neg_api_call, round_api_call, square_api_call) 3. 适配Extend wrapper参数顺序(tmp_buf前置): Abs, Sign, Reciprocal, Sigmoid等 4. 新增NegExtend/FmodExtend/SquareExtend wrapper函数 ## 变更类型 请选择本次引入的变更类型: <!-- [x] 表示选中 --> - [ ] 🐛 Bug 修复 - [ ] ✨ 新功能 - [ ] 💄 代码风格更新(格式化,局部变量) - [x] ♻️ 重构(既不修复错误也不增加功能的代码变动) - [ ] 📦 构建过程或辅助工具的变动 - [ ] 📝 文档内容更新 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue,请在当前页面的右侧'关联Issue'部分添加相应Issue链接,并勾选'合并后关闭已关联的 Issue'选项。 --> ## 如何测试 现有用例看护,功能不变 ## 核对清单 <!-- [x] 表示选中 --> - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签(如:feat:, fix:) - [x] 我已经详细阅读了贡献指南(CONTRIBUTING.md),并遵守了其中的所有规定,包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 在此添加任何其他关于本次 PR 的说明。 See merge request: cann/graph-autofusion!39915 天前
add_cann_target_options 13 天前
【fix】: CalculateStride中Sub结果取Abs防止MTE2负值 Co-authored-by: zhang_shengjie<804425610@qq.com> # message auto-generated for no-merge-commit merge: !393 merge develop into develop 【fix】: CalculateStride中Sub结果取Abs防止MTE2负值 Created-by: zhang_shengjie Commit-by: zhang_shengjie Merged-by: cann-robot Description: # Pull Request ## 描述 ### 一、主要解决的问题 #### 1.1 ATT轴排序算法MTE2性能评估为负值 ATT生成的tiling_func调用轴排序算法时,对存在非连续stride的用例进行性能评估,MTE2(Memory Transfer Engine 2,GM到UB的数据搬运)评估结果为负值。 **根因**:api_perf_utils.cppCalculateStride 函数计算 stride 时,使用 ge::sym::Sub(filtered_strides[block_count_idx], filtered_repeats[filtered_dim_size - 1])。在非连续场景下,filtered_strides[block_count_idx] 可能小于 filtered_repeats[filtered_dim_size - 1],导致 Sub 结果为负值。负 stride 传入性能模型(LoadStoreStrideV2Func 等)后,res = k * block_count * stride_used 乘积为负,最终 MTE2 评估值为负。 ### 二、修改方案 #### 2.1 源码修复(api_perf_utils.cpp) 在 CalculateStride 函数中,对 Sub 结果取 ge::sym::Abs,保证 stride 非负: - **动态shape分支**(第674行):ge::sym::Abs(ge::sym::Sub(...)) - **静态shape分支**(第681行):ge::sym::Abs(ge::sym::Sub(...)) filtered_dim_size == 1 分支不需要修改,因为该路径的 Sub 不会产生负值。 #### 2.2 tiling_func代码生成支持(tiling_code_gen_impl.cpp) GenExpressionMacro() 中新增 Abs 宏定义,供生成的 tiling_func 代码使用: ```c #define Abs(a) ((double)(a) >= 0 ? (a) : -(a)) ``` 风格与已有的 Max/Min 宏保持一致。 #### 2.3 测试用例更新 stride 表达式被 Abs 包装后,符号表达式序列化形式发生变化(如 Mod(((7 * z4t_size) + -7), 256)Mod(Abs((7 - (7 * z4t_size))), 256)),同步更新 3 个测试文件的 expected 字符串。 ### 三、代码修改流程图 ```mermaid flowchart TD A[CalculateStride计算stride] --> B{Sub结果是否可能为负?} B -->|是: 非连续场景stride < repeat| C[Abs包装Sub结果] B -->|否: dim_size==1分支| D[保持不变] C --> E[stride非负传入性能模型] E --> F[MTE2评估值非负] G[GenExpressionMacro] --> H[新增Abs宏定义] H --> I[tiling_func代码可使用Abs] J[测试用例] --> K[更新expected字符串] style A fill:#FFD700,stroke:#B8860B,stroke-width:2px style C fill:#90EE90,stroke:#006400,stroke-width:2px style H fill:#90EE90,stroke:#006400,stroke-width:2px style K fill:#e1f5ff,stroke:#4682B4,stroke-width:2px ``` ## 变更类型 请选择本次引入的变更类型: - [x] 🐛 Bug 修复 - [ ] ✨ 新功能 - [ ] 💄 代码风格更新(格式化,局部变量) - [ ] ♻️ 重构(既不修复错误也不增加功能的代码变动) - [ ] 📦 构建过程或辅助工具的变动 - [ ] 📝 文档内容更新 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue,请在当前页面的右侧'关联Issue'部分添加相应Issue链接,并勾选'合并后关闭已关联的 Issue'选项。 --> ## 如何测试 ### 一 测试用例说明 #### 1.1 单元测试 - bash scripts/test/run_autofuse_test.sh --ascend_install_path=<path> --ascend_3rd_lib_path=<path> -u -m att - 866 tests PASSED, 0 failed #### 1.2 系统测试 - bash scripts/test/run_autofuse_test.sh --ascend_install_path=<path> --ascend_3rd_lib_path=<path> -s -m att - 100% tests passed, 0 tests failed ## 核对清单 - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签(如:feat:, fix:) - [x] 我已经详细阅读了贡献指南(CONTRIBUTING.md),并遵守了其中的所有规定,包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 ### 验证方法 UT: 866 PASSED / ST: 100% passed,涵盖 TestLoadApiForTypev1TestStoreApiForTypeTestNddmaApiSmallBlockLen 等关键用例。 ### 注意事项 修改仅影响 CalculateStride 的 stride 计算层,不影响 CalculateBlockCountByIndexCalculateStridePenalty 等下游函数。 See merge request: cann/graph-autofusion!39315 天前
add l Co-authored-by: JaydenChu<zhumin54@huawei.com> Co-authored-by: xingzhixiong<xingzhixiong@huawei.com> # message auto-generated for no-merge-commit merge: !370 merge 5_11_1 into master 【PR】: 同步GE仓最新修改到AF仓(4.14上午11时~5.15晚,总计129个PR需要同步) Created-by: JaydenChu Commit-by: JaydenChu;xingzhixiong Merged-by: cann-robot Description: # Pull Request ## 描述 同步GE仓最新修改到AF仓(4.14上午11时~5.15晚,总计129个PR需要同步) 所有涉及PR(包含检查过不需要同步的)从编号#1904(4.14 https://gitcode.com/cann/ge/pull/1904)到#2904(5.15 http://gitcode.com/cann/ge/pull/1904) 每个实际已同步pr都对应此pr的一个commit(部分同步pr为了方便同步合并到了一个commit中) ## 变更类型 请选择本次引入的变更类型: <!-- [x] 表示选中 --> - [x] 🐛 Bug 修复 - [x] ✨ 新功能 - [x] 💄 代码风格更新(格式化,局部变量) - [x] ♻️ 重构(既不修复错误也不增加功能的代码变动) - [x] 📦 构建过程或辅助工具的变动 - [x] 📝 文档内容更新 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue,请在当前页面的右侧'关联Issue'部分添加相应Issue链接,并勾选'合并后关闭已关联的 Issue'选项。 --> ## 如何测试 描述测试此变更的步骤和前提条件: 1. 业务代码和llt编译通过 2. llt执行通过 3. 全量rdv验证通过 ## 核对清单 <!-- [x] 表示选中 --> - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签(如:feat:, fix:) - [x] 我已经详细阅读了贡献指南(CONTRIBUTING.md),并遵守了其中的所有规定,包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 在此添加任何其他关于本次 PR 的说明。 See merge request: cann/graph-autofusion!37018 天前
add_cann_target_options 13 天前
【refactor】: 使用Extend封装函数合并部分ApiCall类 Co-authored-by: chenyukai<chenyukai4@huawei.com> # message auto-generated for no-merge-commit merge: !399 merge br_c00826661_apicall0518 into develop 【refactor】: 使用Extend封装函数合并部分ApiCall类 Created-by: chenyukai Commit-by: chenyukai Merged-by: cann-robot Description: # Pull Request ## 描述 1. 将UnaryApiTmpV2Call合并到UnaryApiTmpCall,统一使用Extend wrapper 2. 删除冗余的ApiCall类(binary_tmp_api_call_v2, neg_api_call, round_api_call, square_api_call) 3. 适配Extend wrapper参数顺序(tmp_buf前置): Abs, Sign, Reciprocal, Sigmoid等 4. 新增NegExtend/FmodExtend/SquareExtend wrapper函数 ## 变更类型 请选择本次引入的变更类型: <!-- [x] 表示选中 --> - [ ] 🐛 Bug 修复 - [ ] ✨ 新功能 - [ ] 💄 代码风格更新(格式化,局部变量) - [x] ♻️ 重构(既不修复错误也不增加功能的代码变动) - [ ] 📦 构建过程或辅助工具的变动 - [ ] 📝 文档内容更新 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue,请在当前页面的右侧'关联Issue'部分添加相应Issue链接,并勾选'合并后关闭已关联的 Issue'选项。 --> ## 如何测试 现有用例看护,功能不变 ## 核对清单 <!-- [x] 表示选中 --> - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签(如:feat:, fix:) - [x] 我已经详细阅读了贡献指南(CONTRIBUTING.md),并遵守了其中的所有规定,包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 在此添加任何其他关于本次 PR 的说明。 See merge request: cann/graph-autofusion!39915 天前
feat:inductor场景支持核数、ub参数的配置 Co-authored-by: gcw_V3YyYBt1<gaoxin32@huawei.com> # message auto-generated for no-merge-commit merge: !390 merge develop into develop feat:inductor场景支持核数、ub参数的配置 Created-by: gcw_V3YyYBt1 Commit-by: gcw_V3YyYBt1 Merged-by: cann-robot Description: # Pull Request ## 描述 ## 1. 主要解决的问题 原有 PlatformContext 仅缓存平台名称字符串( current_platform_ ),无法提供硬件规格参数(AIV核数 aiv_num 、UB大小 ub_size )。代码生成阶段 GenGetResLimitStru 中 g_no_limit_res 的核数和UB大小为硬编码值,无法根据实际芯片规格动态适配,导致不同平台下生成的 Tiling 代码可能使用错误的硬件参数。 ## 2. 修改方案 (1)新增 PlatformInfo 结构体,封装 soc_ver 、 aiv_num 、 ub_size ,替代原有的 current_platform_ 字符串硬件信息获取 (2)通过 rtGetSocSpec 接口查询 SoCInfo.vector_core_cnt 和 AICoreSpec.ub_size ,将字符串安全转换为 int64_t 初始化拆分 将硬件参数初始化逻辑从 Initialize() 中抽取为独立函数 InitPlatformInfo() ,职责清晰 (3)对外接口 新增 GetPlatformInfo() 统一返回完整平台信息 ## 3. 代码修改流程图 ```mermaid graph TD A[新增 PlatformInfo 结构体定义<br/>soc_ver, aiv_num, ub_size] --> B[PlatformContext 类增强] B --> B1[添加 InitPlatformInfo 方法] B --> B2[添加 GetPlatformInfo 方法] B --> B3[从 current_platform_ 改为 platform_info_] B1 --> C[InitPlatformInfo 实现获取逻辑] C --> C1[rtGetSocSpec获取 vector_core_cnt] C --> C2[rtGetSocSpec获取 ub_size] C --> C3[解析并存储到 platform_info_] C3 --> D[代码生成时使用动态配置] D --> D1[GenGetResLimitStru 获取 platform_info] D --> D2[使用 platform_info.aiv_num 和 ub_size] D2 --> E[单元测试相应调整] ``` ## 变更类型 请选择本次引入的变更类型: <!-- [x] 表示选中 --> - [ ] 🐛 Bug 修复 - [x] ✨ 新功能 - [ ] 💄 代码风格更新(格式化,局部变量) - [ ] ♻️ 重构(既不修复错误也不增加功能的代码变动) - [ ] 📦 构建过程或辅助工具的变动 - [ ] 📝 文档内容更新 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue,请在当前页面的右侧'关联Issue'部分添加相应Issue链接,并勾选'合并后关闭已关联的 Issue'选项。 --> ## 如何测试 描述测试此变更的步骤和前提条件: 1.编写inductor场景的Python测试用例 2.运行用例 ## 核对清单 <!-- [x] 表示选中 --> - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签(如:feat:, fix:) - [x] 我已经详细阅读了贡献指南(CONTRIBUTING.md),并遵守了其中的所有规定,包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 在此添加任何其他关于本次 PR 的说明。 See merge request: cann/graph-autofusion!39015 天前
add_cann_target_options 13 天前
docs: 文档国际化改造,支持中英文双语 13 天前
add_cann_target_options 13 天前
【feat】: 拆仓后R轴全载norm类算子融合后端代码上库 Co-authored-by: wang-yan-male<wangyan220@huawei.com> # message auto-generated for no-merge-commit merge: !424 merge develop into develop 【feat】: 拆仓后R轴全载norm类算子融合后端代码上库 Created-by: WangYanMale Commit-by: wang-yan-male Merged-by: cann-robot Description: # Pull Request ## 描述 拆仓后R轴全载norm类算子融合后端代码上库 ## 变更类型 请选择本次引入的变更类型: <!-- [x] 表示选中 --> - [ ] 🐛 Bug 修复 - [ ] ✨ 新功能 - [ ] 💄 代码风格更新(格式化,局部变量) - [ ] ♻️ 重构(既不修复错误也不增加功能的代码变动) - [ ] 📦 构建过程或辅助工具的变动 - [ ] 📝 文档内容更新 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue,请在当前页面的右侧'关联Issue'部分添加相应Issue链接,并勾选'合并后关闭已关联的 Issue'选项。 --> ## 如何测试 测试norm算子性能表现是否优化,融合片段减少 ## 核对清单 <!-- [x] 表示选中 --> - [ ] 我的代码遵循了项目的代码风格 - [ ] 我已对代码进行了自测 - [ ] 我已更新了相关的文档 - [ ] 我在标题中使用了合适的类型标签(如:feat:, fix:) - [ ] 我已经详细阅读了贡献指南(CONTRIBUTING.md),并遵守了其中的所有规定,包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 NA See merge request: cann/graph-autofusion!42414 天前
【feat】: 拆仓后R轴全载norm类算子融合后端代码上库 Co-authored-by: wang-yan-male<wangyan220@huawei.com> # message auto-generated for no-merge-commit merge: !424 merge develop into develop 【feat】: 拆仓后R轴全载norm类算子融合后端代码上库 Created-by: WangYanMale Commit-by: wang-yan-male Merged-by: cann-robot Description: # Pull Request ## 描述 拆仓后R轴全载norm类算子融合后端代码上库 ## 变更类型 请选择本次引入的变更类型: <!-- [x] 表示选中 --> - [ ] 🐛 Bug 修复 - [ ] ✨ 新功能 - [ ] 💄 代码风格更新(格式化,局部变量) - [ ] ♻️ 重构(既不修复错误也不增加功能的代码变动) - [ ] 📦 构建过程或辅助工具的变动 - [ ] 📝 文档内容更新 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue,请在当前页面的右侧'关联Issue'部分添加相应Issue链接,并勾选'合并后关闭已关联的 Issue'选项。 --> ## 如何测试 测试norm算子性能表现是否优化,融合片段减少 ## 核对清单 <!-- [x] 表示选中 --> - [ ] 我的代码遵循了项目的代码风格 - [ ] 我已对代码进行了自测 - [ ] 我已更新了相关的文档 - [ ] 我在标题中使用了合适的类型标签(如:feat:, fix:) - [ ] 我已经详细阅读了贡献指南(CONTRIBUTING.md),并遵守了其中的所有规定,包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 NA See merge request: cann/graph-autofusion!42414 天前
【PR】:[feat] [autofuse] Migrate autofuse from ge to graph-autofusion. Co-authored-by: xingzhixiong<xingzhixiong@huawei.com> # message auto-generated for no-merge-commit merge: !301 merge master_af into master 【PR】:[feat] [autofuse] Migrate autofuse from ge to graph-autofusion. Created-by: xingzhixiong Commit-by: xingzhixiong Merged-by: cann-robot Description: # Pull Request ## 描述 从 ge 仓解耦autofuse组件,从ge仓的compiler/graph/optimize/autofuse目录迁移至本仓autofuse目录,未来在本仓独立发包和演进,ge 仓的集成方式不变。 迁移内容主要包括自动融合范围识别、自动算子代码生成、Auto Tiling优化、动态shape及混合精度等特性。 ## 变更类型 请选择本次引入的变更类型: <!-- [x] 表示选中 --> - [ ] 🐛 Bug 修复 - [x] ✨ 新功能 - [ ] 💄 代码风格更新(格式化,局部变量) - [ ] ♻️ 重构(既不修复错误也不增加功能的代码变动) - [ ] 📦 构建过程或辅助工具的变动 - [ ] 📝 文档内容更新 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue,请在当前页面的右侧'关联Issue'部分添加相应Issue链接,并勾选'合并后关闭已关联的 Issue'选项。 --> ## 如何测试 描述测试此变更的步骤和前提条件: 1.上板验证inductor+af单片段流程pass 2.上板验证inductor+af整网流程pass ## 核对清单 <!-- [x] 表示选中 --> - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签(如:feat:, fix:) - [x] 我已经详细阅读了贡献指南(CONTRIBUTING.md),并遵守了其中的所有规定,包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 在此添加任何其他关于本次 PR 的说明。 See merge request: cann/graph-autofusion!3011 个月前
docs: 文档国际化改造,支持中英文双语 13 天前
【refactor】: 使用Extend封装函数合并部分ApiCall类 Co-authored-by: chenyukai<chenyukai4@huawei.com> # message auto-generated for no-merge-commit merge: !399 merge br_c00826661_apicall0518 into develop 【refactor】: 使用Extend封装函数合并部分ApiCall类 Created-by: chenyukai Commit-by: chenyukai Merged-by: cann-robot Description: # Pull Request ## 描述 1. 将UnaryApiTmpV2Call合并到UnaryApiTmpCall,统一使用Extend wrapper 2. 删除冗余的ApiCall类(binary_tmp_api_call_v2, neg_api_call, round_api_call, square_api_call) 3. 适配Extend wrapper参数顺序(tmp_buf前置): Abs, Sign, Reciprocal, Sigmoid等 4. 新增NegExtend/FmodExtend/SquareExtend wrapper函数 ## 变更类型 请选择本次引入的变更类型: <!-- [x] 表示选中 --> - [ ] 🐛 Bug 修复 - [ ] ✨ 新功能 - [ ] 💄 代码风格更新(格式化,局部变量) - [x] ♻️ 重构(既不修复错误也不增加功能的代码变动) - [ ] 📦 构建过程或辅助工具的变动 - [ ] 📝 文档内容更新 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue,请在当前页面的右侧'关联Issue'部分添加相应Issue链接,并勾选'合并后关闭已关联的 Issue'选项。 --> ## 如何测试 现有用例看护,功能不变 ## 核对清单 <!-- [x] 表示选中 --> - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签(如:feat:, fix:) - [x] 我已经详细阅读了贡献指南(CONTRIBUTING.md),并遵守了其中的所有规定,包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 在此添加任何其他关于本次 PR 的说明。 See merge request: cann/graph-autofusion!39915 天前
add_cann_target_options 13 天前
docs: 文档国际化改造,支持中英文双语 13 天前
docs: 文档国际化改造,支持中英文双语 13 天前
add l Co-authored-by: JaydenChu<zhumin54@huawei.com> Co-authored-by: xingzhixiong<xingzhixiong@huawei.com> # message auto-generated for no-merge-commit merge: !370 merge 5_11_1 into master 【PR】: 同步GE仓最新修改到AF仓(4.14上午11时~5.15晚,总计129个PR需要同步) Created-by: JaydenChu Commit-by: JaydenChu;xingzhixiong Merged-by: cann-robot Description: # Pull Request ## 描述 同步GE仓最新修改到AF仓(4.14上午11时~5.15晚,总计129个PR需要同步) 所有涉及PR(包含检查过不需要同步的)从编号#1904(4.14 https://gitcode.com/cann/ge/pull/1904)到#2904(5.15 http://gitcode.com/cann/ge/pull/1904) 每个实际已同步pr都对应此pr的一个commit(部分同步pr为了方便同步合并到了一个commit中) ## 变更类型 请选择本次引入的变更类型: <!-- [x] 表示选中 --> - [x] 🐛 Bug 修复 - [x] ✨ 新功能 - [x] 💄 代码风格更新(格式化,局部变量) - [x] ♻️ 重构(既不修复错误也不增加功能的代码变动) - [x] 📦 构建过程或辅助工具的变动 - [x] 📝 文档内容更新 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue,请在当前页面的右侧'关联Issue'部分添加相应Issue链接,并勾选'合并后关闭已关联的 Issue'选项。 --> ## 如何测试 描述测试此变更的步骤和前提条件: 1. 业务代码和llt编译通过 2. llt执行通过 3. 全量rdv验证通过 ## 核对清单 <!-- [x] 表示选中 --> - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签(如:feat:, fix:) - [x] 我已经详细阅读了贡献指南(CONTRIBUTING.md),并遵守了其中的所有规定,包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 在此添加任何其他关于本次 PR 的说明。 See merge request: cann/graph-autofusion!37018 天前
README.md

Autofuse

简介

AutoFuse是基于Ascend C的自动融合框架,支持自动融合范围识别、自动算子代码生成、Auto Tiling优化、动态shape及混合精度等特性;在算法网络中,由于存在大量的Vector计算,各个Vector计算之间会产生大量的内存搬运,导致Memory Bound问题。而AutoFuse通过自动将多个算子融合为一个算子,减少网络中的算子数量和内存搬运,从而缓解了Memory Bound问题,释放昇腾算力,提升模型的执行性能。

详细介绍,请参考《Autofuse自动融合

Autofuse 目录结构

autofuse/
├── ascendc                # ascendc api 定义
├── ascir                  # 算子注册 ascir
├── att                    # 自动 tiling 生成 模块
├── autofuse               # config 配置
├── codegen                # kernel 代码生成 模块
├── common                 # 通用工具方法
├── compiler               # 对外API 接口
├── examples               # 示例脚本,演示典型用法
├── graph_metadef          # 基本图接口
├── inc                    # 供 GE 调用接口
├── optimize               # 调度切分 模块
├── scripts                # 脚本路径
├── v35                    # 昇腾950 芯片相关优化
├── CMakeLists.txt         # CMake 配置文件
├── blacklist.txt          # 工程配置文件
├── README.md

构建与安装

参考执行构建

上板验证指导

用户如果想在昇腾设备上体验Autofuse 的功能与性能,可以先参考快速安装准备环境。无论是没有昇腾设备的开发者,还是已有昇腾设备的开发者,都可以快速搭建好环境。在此基础上,按照上一步构建与安装,增量安装了graph-autofusion仓编译生成的cann包。

此处指导如何搭建 Pytorch 环境,创建脚本,跑通 Inductor + Autofuse场景,并可视化生成的自动融合算子,以及观察最后的kernel性能。

当前自动融合支持elementwise类型+element类型,element类型+broadcast类型,element类型+reduce类型算子的融合。更多融合场景的支持(concat,gather等等)逐步开放中。

安装依赖

安装 torch_npu

pip3 install numpy
pip3 install pyyaml
pip3 install setuptools
pip3 install torch_npu==2.8  # 通过pip 安装 torch_npu 时,会自动安装依赖的torch 版本

安装 inductor-npu-ext (Autofuse 在 Inductor 的使能框架)

git clone https://gitcode.com/Ascend/torchair.git
cd torchair/experimental/_inductor_npu_ext/
pip3 install -e ./python/

其他环境依赖

CMake >= 3.16.0
GCC >= 7.3.0

在 openEuler 系统上,您可以通过以下命令安装:

sudo yum install cmake gcc

在 Ubuntu 系统上,您可以通过以下命令安装:

sudo apt-get install cmake gcc

sample 用例

autofuse 提供了丰富的 sample 用例,可以参考Autofuse样例

设置环境变量

执行用例前,需要设置如下环境变量,设置运行NPU设备。

 # 用户自己的 driver 包安装路径
 source /usr/local/Ascend/driver/bin/setenv.sh
 # 用户自己的 CANN 包安装路径
 source /usr/local/Ascend/ascend-toolkit/set_env.sh
 # 假设跑在 0卡,和脚本保持一致
 export ASCEND_DEVICE_ID=0

执行用例

假设用例名为 test.py,直接执行: python3 test.py

更多调测相关环境变量

TORCH_COMPILE_DEBUG

作用: torch原生环境变量,启用详细调试日志,以及编译中间产物保存等。

使用方法:

export TORCH_COMPILE_DEBUG=1

注意: 多次执行相同脚本,会因为缓存存在而跳过编译,可以配合 TORCHINDUCTOR_FORCE_DISABLE_CACHES 使用,强制每次执行都重新编译。

TORCHINDUCTOR_FORCE_DISABLE_CACHES

作用: torch原生环境变量,禁用 Inductor 缓存,每次执行都会重新编译。

使用方法:

export TORCHINDUCTOR_FORCE_DISABLE_CACHES=1

注意: 会显著增加图启动耗时,实际部署时请勿使用该环境变量。

可选:ASCEND_LAUNCH_BLOCKING

作用: torch_npu原生环境变量,启用 Ascend 内核同步执行,每次kernel下发都会等待完成,便于确定首个报错的 kernel。

使用方法:

export ASCEND_LAUNCH_BLOCKING=1

注意: 会显著降低下发性能,实际部署时请勿使用该环境变量。

可选:AUTOFUSE_DFX_FLAGS

作用: autofuse DFX环境变量,落盘每个自动融合算子,对应的内部融合图结构。pbtxt文件可以使用netron.app 打开观察。 使用方法:

export AUTOFUSE_DFX_FLAGS="--codegen_compile_debug=true;--debug_dir=/path-to-dump/"

注意:在设置的dump图路径下,生成 Autofuse 后端,对于每个融合算子的dump图。

结果分析 & 调测输出分析

用户开启 TORCH_COMPILE_DEBUG 后,调试信息输出位于执行目录下的torch_compile_debug子目录,带有 autofused_ 前缀的目录为 inductor-npu-ext 相关产物,其余均为 inductor 原生产物。每一个autofused_ 前缀的目录,都表示一个融合算子的白盒结构。如果没有融合算子产生(即未发生融合,需要通过打屏的 "Fallback aten.xxxx $reason: xx原因" 信息去判断原因。具体可参考inductor-npu-ext使用手册

用户也可以通过profiling的相关配置,观察使能自动融合后,算子性能收益情况。对于上面的sample用例,可以注释 "model = torch.compile(model, dynamic=False, fullgraph=True)" 这一行,即可走单算子流程。然后对比profiling里,单算子场景所有算子的总耗时,与使能 Inductor+Autofuse,融合算子的总耗时。详细的Profling性能分析工具的使用方法,可参见Profiling性能分析工具指南

需要注意的是,不是模型里所有的算子都能被融合,对于在 Inductor 层未被 lowering 的算子,最后仍然以单算子形式存在。融合提升比,等于 (融合后所有算子耗时-融合前所有算子耗时)/融合前所有算子耗时。更进一步的,可以观察融合算子的 aiv_mte2_time(输入搬运耗时)和 aiv_mte3_time(输出搬运耗时)的提升情况。

对于精度的分析,详细的精度调试工具的使用方法,可参见精度调试工具指南

复杂网络使能

用户如果想在网络里,使能 Autofuse 功能,只需要在模型文件的开头,导入torch后面,加上 import inductor_npu_ext 即可。