文件最后提交记录最后更新时间
fix fast kernel launch example smoke test Co-authored-by: zhangzijie<zhangzijie11@hisilicon.com> # message auto-generated for no-merge-commit merge: !456 merge master into master fix fast kernel launch example smoke test Created-by: zhangzijie Commit-by: zhangzijie Merged-by: cann-robot Description: ## 描述 <!--在这里详细描述你的改动,包括改动的原因和所采取的方法。--> 修复 fast kernel launch example 冒烟测试 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue,请在这里提供Issue链接。--> <!-- 如果这个PR是为了解决特定的问题单,请在这里描述问题单单号。--> ## 测试 <!--描述进行了哪些测试来验证你的改动。包括但不限于二级冒烟、算子泛化等。--> ## 文档更新 <!--如果这个PR包含文档的更新,请在这里指出。例如:更新了README.md文件。--> ## 类型标签 <!-- [x] 表示选中 --> - [ ] Bug修复 - [ ] 新特性 - [ ] 性能优化 - [ ] 文档更新 - [ ] 其他,请描述: See merge request: cann/ops-math!4565 个月前
feat: migrate fast kernel launch example to ASC CMake Co-authored-by: zhangzijie<zhangzijie11@hisilicon.com> # message auto-generated for no-merge-commit merge: !2520 merge feature/fast-kernel-launch-asc into master feat: migrate fast kernel launch example to ASC CMake Created-by: zhangzijie Commit-by: zhangzijie Merged-by: cann-robot Description: ## 描述 将 examples/fast_kernel_launch_example 迁移到 CMake 原生 ASC 语言构建,并整理 Fast Kernel Launch 示例的算子构建组织方式: - 将 add/sqrt/gelu/layer_norm 算子实现从 .cpp 重命名为 .asc - 顶层 CMake 使用 find_package(ASC REQUIRED)project(... LANGUAGES C CXX ASC) 启用 ASC 语言 - 将示例算子目录从 ascend910b 收敛到编译器使用的 NPU_ARCH 命名,例如 dav-2201 - 将算子对象文件收集方式从全局 OBJECTS_LIST cache 变量改为 CMake object target + global property - 构建入口优先使用 Ninja,并在 README 中补充 NPU_ARCH 和新增算子的开发方式 ## Refactor 方案 ### 1. 构建入口改为 CMake 原生 ASC 语言 原方案通过普通 C/CXX 工程、手动指定 bisheng 编译器、给 .cpp 源文件追加 -xasc 的方式触发 ASC 编译。该方式把 ASC 编译细节散落在自定义宏和全局变量中,新增算子时需要理解较多隐藏约定。 本次重构改为在顶层 CMakeLists.txt 中先加载 cmake/ascend.cmake,再执行: ```cmake find_package(ASC REQUIRED) project(${PKG_NAME} VERSION 1.0.0 LANGUAGES C CXX ASC) ``` 这样 ASC 被声明为工程语言,.asc 源文件由 CMake/ASC 包正常识别,不再依赖 LANGUAGE CXX + -xasc 的绕行方式。cmake/ascend.cmake 只负责定位 Ascend Toolkit、bisheng 和默认 toolchain,ASC include/link 细节交给 find_package(ASC) 提供的能力处理。 ### 2. NPU 架构命名从芯片名切换到编译器参数 原目录使用 ascend910b,但实际传给编译器的是 --npu-arch=dav-2201。这会让目录名、CMake 参数和编译器参数不一致。 本次重构统一使用编译器 --npu-arch 对应的取值作为目录名和构建参数: - 默认 NPU_ARCH=dav-2201 - 支持 dav-2201dav-3510 - 支持通过环境变量 NPU_ARCH 或 CMake cache 覆盖 - 配置阶段校验不支持的架构并直接报错 因此示例目录迁移为: ```text csrc/<op_name>/<NPU_ARCH>/<op_name>.asc ``` 当前 PR 中 add/sqrt/gelu/layer_norm 均迁移到 dav-2201 目录。 ### 3. 算子发现从手写遍历改为按架构目录收敛 原 recursive_add_subdirectory() 会扫描 csrc 下每个算子的 ${NPU_ARCH}/CMakeLists.txt,但配合旧的 ascend910b 默认值时,目录名和真实编译参数存在错位。 新实现按如下规则发现算子: ```text csrc/*/${NPU_ARCH}/CMakeLists.txt ``` 并对结果排序后逐个 add_subdirectory(),保证构建输入稳定。如果当前架构下没有算子目录,会输出 warning,顶层仍可生成 dummy extension module,便于定位问题而不是在隐式变量处失败。 ### 4. 算子编译单元改为 object target 原 add_sources() 宏会: - 清理/重置部分全局 CMake 变量 - 递归查找 .cpp - 手动设置 LANGUAGE CXXCOMPILE_FLAGS - 将 $<TARGET_OBJECTS:...> 写入全局 cache 变量 OBJECTS_LIST 这类全局可变状态不利于维护,也容易受 CMake 配置顺序影响。 新方案提供: ```cmake ascend_ops_add_current_op(OP_TARGET) ``` 每个算子目录调用后会生成独立 object library,target 名包含算子名和 NPU_ARCH,例如 add_dav_2201_obj。函数内部负责: - 查找当前目录下的 .asc 源文件 - 为该 object target 添加通用编译选项 - 显式追加 --npu-arch=${NPU_ARCH} - 添加当前算子目录和公共 include 目录 - 将 object target 注册到全局 property ASCEND_OPS_OPERATOR_TARGETS 顶层 _C extension 再从 ASCEND_OPS_OPERATOR_TARGETS 中收集 $<TARGET_OBJECTS:${OPERATOR_TARGET}>,并在存在算子 target 时链接这些 target。这样算子自身需要的库可以留在各自目录,例如: ```cmake ascend_ops_add_current_op(OP_TARGET) target_link_libraries(${OP_TARGET} PUBLIC platform) target_link_libraries(${OP_TARGET} PUBLIC tiling_api) ``` ### 5. Python 构建入口保持轻量 setup.py 不再负责把 NPU_ARCH 翻译成 CMake 参数。架构选择统一留给 CMake 层处理,Python 侧只传入 Torch/Torch NPU 路径和构建类型。 同时 Python 构建入口优先选择 Ninja: - 环境中存在 ninja 时使用 -G Ninja - 否则回退到 Unix Makefiles requirements.txt 补充 ninja,使示例默认构建路径更稳定。 ### 6. 新增算子的维护方式 新增算子只需要按目标架构创建目录和 .asc 文件: ```text csrc/<op_name>/<NPU_ARCH>/CMakeLists.txt csrc/<op_name>/<NPU_ARCH>/<op_name>.asc ``` CMakeLists.txt 的最小内容为: ```cmake ascend_ops_add_current_op(OP_TARGET) ``` 如果算子需要额外库或编译选项,可继续对 ${OP_TARGET} 调用 target_link_libraries()target_compile_options() 等 target 级 CMake API,不需要修改顶层对象列表或全局变量。 ## 关联的Issue 无 ## 测试 测试结果: ```text 119 passed, 1 warning in 6.80s ``` ## 文档更新 更新 examples/fast_kernel_launch_example/README.md: - 补充默认 NPU_ARCH=dav-2201、可通过环境变量覆盖,以及当前支持 dav-2201/dav-3510 - 将新增算子开发说明从 .cpp + add_sources("--npu-arch=...") 更新为 .asc + ascend_ops_add_current_op(OP_TARGET) ## 类型标签 - [ ] Bug修复 - [x] 新特性 - [ ] 性能优化 - [x] 文档更新 - [x] 其他,请描述:构建重构 See merge request: cann/ops-math!25201 个月前
feat: migrate fast kernel launch example to ASC CMake Co-authored-by: zhangzijie<zhangzijie11@hisilicon.com> # message auto-generated for no-merge-commit merge: !2520 merge feature/fast-kernel-launch-asc into master feat: migrate fast kernel launch example to ASC CMake Created-by: zhangzijie Commit-by: zhangzijie Merged-by: cann-robot Description: ## 描述 将 examples/fast_kernel_launch_example 迁移到 CMake 原生 ASC 语言构建,并整理 Fast Kernel Launch 示例的算子构建组织方式: - 将 add/sqrt/gelu/layer_norm 算子实现从 .cpp 重命名为 .asc - 顶层 CMake 使用 find_package(ASC REQUIRED)project(... LANGUAGES C CXX ASC) 启用 ASC 语言 - 将示例算子目录从 ascend910b 收敛到编译器使用的 NPU_ARCH 命名,例如 dav-2201 - 将算子对象文件收集方式从全局 OBJECTS_LIST cache 变量改为 CMake object target + global property - 构建入口优先使用 Ninja,并在 README 中补充 NPU_ARCH 和新增算子的开发方式 ## Refactor 方案 ### 1. 构建入口改为 CMake 原生 ASC 语言 原方案通过普通 C/CXX 工程、手动指定 bisheng 编译器、给 .cpp 源文件追加 -xasc 的方式触发 ASC 编译。该方式把 ASC 编译细节散落在自定义宏和全局变量中,新增算子时需要理解较多隐藏约定。 本次重构改为在顶层 CMakeLists.txt 中先加载 cmake/ascend.cmake,再执行: ```cmake find_package(ASC REQUIRED) project(${PKG_NAME} VERSION 1.0.0 LANGUAGES C CXX ASC) ``` 这样 ASC 被声明为工程语言,.asc 源文件由 CMake/ASC 包正常识别,不再依赖 LANGUAGE CXX + -xasc 的绕行方式。cmake/ascend.cmake 只负责定位 Ascend Toolkit、bisheng 和默认 toolchain,ASC include/link 细节交给 find_package(ASC) 提供的能力处理。 ### 2. NPU 架构命名从芯片名切换到编译器参数 原目录使用 ascend910b,但实际传给编译器的是 --npu-arch=dav-2201。这会让目录名、CMake 参数和编译器参数不一致。 本次重构统一使用编译器 --npu-arch 对应的取值作为目录名和构建参数: - 默认 NPU_ARCH=dav-2201 - 支持 dav-2201dav-3510 - 支持通过环境变量 NPU_ARCH 或 CMake cache 覆盖 - 配置阶段校验不支持的架构并直接报错 因此示例目录迁移为: ```text csrc/<op_name>/<NPU_ARCH>/<op_name>.asc ``` 当前 PR 中 add/sqrt/gelu/layer_norm 均迁移到 dav-2201 目录。 ### 3. 算子发现从手写遍历改为按架构目录收敛 原 recursive_add_subdirectory() 会扫描 csrc 下每个算子的 ${NPU_ARCH}/CMakeLists.txt,但配合旧的 ascend910b 默认值时,目录名和真实编译参数存在错位。 新实现按如下规则发现算子: ```text csrc/*/${NPU_ARCH}/CMakeLists.txt ``` 并对结果排序后逐个 add_subdirectory(),保证构建输入稳定。如果当前架构下没有算子目录,会输出 warning,顶层仍可生成 dummy extension module,便于定位问题而不是在隐式变量处失败。 ### 4. 算子编译单元改为 object target 原 add_sources() 宏会: - 清理/重置部分全局 CMake 变量 - 递归查找 .cpp - 手动设置 LANGUAGE CXXCOMPILE_FLAGS - 将 $<TARGET_OBJECTS:...> 写入全局 cache 变量 OBJECTS_LIST 这类全局可变状态不利于维护,也容易受 CMake 配置顺序影响。 新方案提供: ```cmake ascend_ops_add_current_op(OP_TARGET) ``` 每个算子目录调用后会生成独立 object library,target 名包含算子名和 NPU_ARCH,例如 add_dav_2201_obj。函数内部负责: - 查找当前目录下的 .asc 源文件 - 为该 object target 添加通用编译选项 - 显式追加 --npu-arch=${NPU_ARCH} - 添加当前算子目录和公共 include 目录 - 将 object target 注册到全局 property ASCEND_OPS_OPERATOR_TARGETS 顶层 _C extension 再从 ASCEND_OPS_OPERATOR_TARGETS 中收集 $<TARGET_OBJECTS:${OPERATOR_TARGET}>,并在存在算子 target 时链接这些 target。这样算子自身需要的库可以留在各自目录,例如: ```cmake ascend_ops_add_current_op(OP_TARGET) target_link_libraries(${OP_TARGET} PUBLIC platform) target_link_libraries(${OP_TARGET} PUBLIC tiling_api) ``` ### 5. Python 构建入口保持轻量 setup.py 不再负责把 NPU_ARCH 翻译成 CMake 参数。架构选择统一留给 CMake 层处理,Python 侧只传入 Torch/Torch NPU 路径和构建类型。 同时 Python 构建入口优先选择 Ninja: - 环境中存在 ninja 时使用 -G Ninja - 否则回退到 Unix Makefiles requirements.txt 补充 ninja,使示例默认构建路径更稳定。 ### 6. 新增算子的维护方式 新增算子只需要按目标架构创建目录和 .asc 文件: ```text csrc/<op_name>/<NPU_ARCH>/CMakeLists.txt csrc/<op_name>/<NPU_ARCH>/<op_name>.asc ``` CMakeLists.txt 的最小内容为: ```cmake ascend_ops_add_current_op(OP_TARGET) ``` 如果算子需要额外库或编译选项,可继续对 ${OP_TARGET} 调用 target_link_libraries()target_compile_options() 等 target 级 CMake API,不需要修改顶层对象列表或全局变量。 ## 关联的Issue 无 ## 测试 测试结果: ```text 119 passed, 1 warning in 6.80s ``` ## 文档更新 更新 examples/fast_kernel_launch_example/README.md: - 补充默认 NPU_ARCH=dav-2201、可通过环境变量覆盖,以及当前支持 dav-2201/dav-3510 - 将新增算子开发说明从 .cpp + add_sources("--npu-arch=...") 更新为 .asc + ascend_ops_add_current_op(OP_TARGET) ## 类型标签 - [ ] Bug修复 - [x] 新特性 - [ ] 性能优化 - [x] 文档更新 - [x] 其他,请描述:构建重构 See merge request: cann/ops-math!25201 个月前
ai agent auto generated kernels Co-authored-by: zhangzijie<zhangzijie11@hisilicon.com> # message auto-generated for no-merge-commit merge: !1904 merge master into master ai agent auto generated kernels Created-by: zhangzijie Commit-by: zhangzijie Merged-by: cann-robot Description: ## 描述 AI Agent 自动生成Kernel代码 - Sqrt - GeLU - LayerNorm ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue,请在这里提供Issue链接。--> <!-- 如果这个PR是为了解决特定的问题单,请在这里描述问题单单号。--> ## 测试 <!--描述进行了哪些测试来验证你的改动。包括但不限于二级冒烟、算子泛化等。--> ## 文档更新 <!--如果这个PR包含文档的更新,请在这里指出。例如:更新了README.md文件。--> ## 类型标签 <!-- [x] 表示选中 --> - [ ] Bug修复 - [x] 新特性 - [ ] 性能优化 - [ ] 文档更新 - [ ] 其他,请描述: See merge request: cann/ops-math!19042 个月前
feat: migrate fast kernel launch example to ASC CMake Co-authored-by: zhangzijie<zhangzijie11@hisilicon.com> # message auto-generated for no-merge-commit merge: !2520 merge feature/fast-kernel-launch-asc into master feat: migrate fast kernel launch example to ASC CMake Created-by: zhangzijie Commit-by: zhangzijie Merged-by: cann-robot Description: ## 描述 将 examples/fast_kernel_launch_example 迁移到 CMake 原生 ASC 语言构建,并整理 Fast Kernel Launch 示例的算子构建组织方式: - 将 add/sqrt/gelu/layer_norm 算子实现从 .cpp 重命名为 .asc - 顶层 CMake 使用 find_package(ASC REQUIRED)project(... LANGUAGES C CXX ASC) 启用 ASC 语言 - 将示例算子目录从 ascend910b 收敛到编译器使用的 NPU_ARCH 命名,例如 dav-2201 - 将算子对象文件收集方式从全局 OBJECTS_LIST cache 变量改为 CMake object target + global property - 构建入口优先使用 Ninja,并在 README 中补充 NPU_ARCH 和新增算子的开发方式 ## Refactor 方案 ### 1. 构建入口改为 CMake 原生 ASC 语言 原方案通过普通 C/CXX 工程、手动指定 bisheng 编译器、给 .cpp 源文件追加 -xasc 的方式触发 ASC 编译。该方式把 ASC 编译细节散落在自定义宏和全局变量中,新增算子时需要理解较多隐藏约定。 本次重构改为在顶层 CMakeLists.txt 中先加载 cmake/ascend.cmake,再执行: ```cmake find_package(ASC REQUIRED) project(${PKG_NAME} VERSION 1.0.0 LANGUAGES C CXX ASC) ``` 这样 ASC 被声明为工程语言,.asc 源文件由 CMake/ASC 包正常识别,不再依赖 LANGUAGE CXX + -xasc 的绕行方式。cmake/ascend.cmake 只负责定位 Ascend Toolkit、bisheng 和默认 toolchain,ASC include/link 细节交给 find_package(ASC) 提供的能力处理。 ### 2. NPU 架构命名从芯片名切换到编译器参数 原目录使用 ascend910b,但实际传给编译器的是 --npu-arch=dav-2201。这会让目录名、CMake 参数和编译器参数不一致。 本次重构统一使用编译器 --npu-arch 对应的取值作为目录名和构建参数: - 默认 NPU_ARCH=dav-2201 - 支持 dav-2201dav-3510 - 支持通过环境变量 NPU_ARCH 或 CMake cache 覆盖 - 配置阶段校验不支持的架构并直接报错 因此示例目录迁移为: ```text csrc/<op_name>/<NPU_ARCH>/<op_name>.asc ``` 当前 PR 中 add/sqrt/gelu/layer_norm 均迁移到 dav-2201 目录。 ### 3. 算子发现从手写遍历改为按架构目录收敛 原 recursive_add_subdirectory() 会扫描 csrc 下每个算子的 ${NPU_ARCH}/CMakeLists.txt,但配合旧的 ascend910b 默认值时,目录名和真实编译参数存在错位。 新实现按如下规则发现算子: ```text csrc/*/${NPU_ARCH}/CMakeLists.txt ``` 并对结果排序后逐个 add_subdirectory(),保证构建输入稳定。如果当前架构下没有算子目录,会输出 warning,顶层仍可生成 dummy extension module,便于定位问题而不是在隐式变量处失败。 ### 4. 算子编译单元改为 object target 原 add_sources() 宏会: - 清理/重置部分全局 CMake 变量 - 递归查找 .cpp - 手动设置 LANGUAGE CXXCOMPILE_FLAGS - 将 $<TARGET_OBJECTS:...> 写入全局 cache 变量 OBJECTS_LIST 这类全局可变状态不利于维护,也容易受 CMake 配置顺序影响。 新方案提供: ```cmake ascend_ops_add_current_op(OP_TARGET) ``` 每个算子目录调用后会生成独立 object library,target 名包含算子名和 NPU_ARCH,例如 add_dav_2201_obj。函数内部负责: - 查找当前目录下的 .asc 源文件 - 为该 object target 添加通用编译选项 - 显式追加 --npu-arch=${NPU_ARCH} - 添加当前算子目录和公共 include 目录 - 将 object target 注册到全局 property ASCEND_OPS_OPERATOR_TARGETS 顶层 _C extension 再从 ASCEND_OPS_OPERATOR_TARGETS 中收集 $<TARGET_OBJECTS:${OPERATOR_TARGET}>,并在存在算子 target 时链接这些 target。这样算子自身需要的库可以留在各自目录,例如: ```cmake ascend_ops_add_current_op(OP_TARGET) target_link_libraries(${OP_TARGET} PUBLIC platform) target_link_libraries(${OP_TARGET} PUBLIC tiling_api) ``` ### 5. Python 构建入口保持轻量 setup.py 不再负责把 NPU_ARCH 翻译成 CMake 参数。架构选择统一留给 CMake 层处理,Python 侧只传入 Torch/Torch NPU 路径和构建类型。 同时 Python 构建入口优先选择 Ninja: - 环境中存在 ninja 时使用 -G Ninja - 否则回退到 Unix Makefiles requirements.txt 补充 ninja,使示例默认构建路径更稳定。 ### 6. 新增算子的维护方式 新增算子只需要按目标架构创建目录和 .asc 文件: ```text csrc/<op_name>/<NPU_ARCH>/CMakeLists.txt csrc/<op_name>/<NPU_ARCH>/<op_name>.asc ``` CMakeLists.txt 的最小内容为: ```cmake ascend_ops_add_current_op(OP_TARGET) ``` 如果算子需要额外库或编译选项,可继续对 ${OP_TARGET} 调用 target_link_libraries()target_compile_options() 等 target 级 CMake API,不需要修改顶层对象列表或全局变量。 ## 关联的Issue 无 ## 测试 测试结果: ```text 119 passed, 1 warning in 6.80s ``` ## 文档更新 更新 examples/fast_kernel_launch_example/README.md: - 补充默认 NPU_ARCH=dav-2201、可通过环境变量覆盖,以及当前支持 dav-2201/dav-3510 - 将新增算子开发说明从 .cpp + add_sources("--npu-arch=...") 更新为 .asc + ascend_ops_add_current_op(OP_TARGET) ## 类型标签 - [ ] Bug修复 - [x] 新特性 - [ ] 性能优化 - [x] 文档更新 - [x] 其他,请描述:构建重构 See merge request: cann/ops-math!25201 个月前
feat: migrate fast kernel launch example to ASC CMake Co-authored-by: zhangzijie<zhangzijie11@hisilicon.com> # message auto-generated for no-merge-commit merge: !2520 merge feature/fast-kernel-launch-asc into master feat: migrate fast kernel launch example to ASC CMake Created-by: zhangzijie Commit-by: zhangzijie Merged-by: cann-robot Description: ## 描述 将 examples/fast_kernel_launch_example 迁移到 CMake 原生 ASC 语言构建,并整理 Fast Kernel Launch 示例的算子构建组织方式: - 将 add/sqrt/gelu/layer_norm 算子实现从 .cpp 重命名为 .asc - 顶层 CMake 使用 find_package(ASC REQUIRED)project(... LANGUAGES C CXX ASC) 启用 ASC 语言 - 将示例算子目录从 ascend910b 收敛到编译器使用的 NPU_ARCH 命名,例如 dav-2201 - 将算子对象文件收集方式从全局 OBJECTS_LIST cache 变量改为 CMake object target + global property - 构建入口优先使用 Ninja,并在 README 中补充 NPU_ARCH 和新增算子的开发方式 ## Refactor 方案 ### 1. 构建入口改为 CMake 原生 ASC 语言 原方案通过普通 C/CXX 工程、手动指定 bisheng 编译器、给 .cpp 源文件追加 -xasc 的方式触发 ASC 编译。该方式把 ASC 编译细节散落在自定义宏和全局变量中,新增算子时需要理解较多隐藏约定。 本次重构改为在顶层 CMakeLists.txt 中先加载 cmake/ascend.cmake,再执行: ```cmake find_package(ASC REQUIRED) project(${PKG_NAME} VERSION 1.0.0 LANGUAGES C CXX ASC) ``` 这样 ASC 被声明为工程语言,.asc 源文件由 CMake/ASC 包正常识别,不再依赖 LANGUAGE CXX + -xasc 的绕行方式。cmake/ascend.cmake 只负责定位 Ascend Toolkit、bisheng 和默认 toolchain,ASC include/link 细节交给 find_package(ASC) 提供的能力处理。 ### 2. NPU 架构命名从芯片名切换到编译器参数 原目录使用 ascend910b,但实际传给编译器的是 --npu-arch=dav-2201。这会让目录名、CMake 参数和编译器参数不一致。 本次重构统一使用编译器 --npu-arch 对应的取值作为目录名和构建参数: - 默认 NPU_ARCH=dav-2201 - 支持 dav-2201dav-3510 - 支持通过环境变量 NPU_ARCH 或 CMake cache 覆盖 - 配置阶段校验不支持的架构并直接报错 因此示例目录迁移为: ```text csrc/<op_name>/<NPU_ARCH>/<op_name>.asc ``` 当前 PR 中 add/sqrt/gelu/layer_norm 均迁移到 dav-2201 目录。 ### 3. 算子发现从手写遍历改为按架构目录收敛 原 recursive_add_subdirectory() 会扫描 csrc 下每个算子的 ${NPU_ARCH}/CMakeLists.txt,但配合旧的 ascend910b 默认值时,目录名和真实编译参数存在错位。 新实现按如下规则发现算子: ```text csrc/*/${NPU_ARCH}/CMakeLists.txt ``` 并对结果排序后逐个 add_subdirectory(),保证构建输入稳定。如果当前架构下没有算子目录,会输出 warning,顶层仍可生成 dummy extension module,便于定位问题而不是在隐式变量处失败。 ### 4. 算子编译单元改为 object target 原 add_sources() 宏会: - 清理/重置部分全局 CMake 变量 - 递归查找 .cpp - 手动设置 LANGUAGE CXXCOMPILE_FLAGS - 将 $<TARGET_OBJECTS:...> 写入全局 cache 变量 OBJECTS_LIST 这类全局可变状态不利于维护,也容易受 CMake 配置顺序影响。 新方案提供: ```cmake ascend_ops_add_current_op(OP_TARGET) ``` 每个算子目录调用后会生成独立 object library,target 名包含算子名和 NPU_ARCH,例如 add_dav_2201_obj。函数内部负责: - 查找当前目录下的 .asc 源文件 - 为该 object target 添加通用编译选项 - 显式追加 --npu-arch=${NPU_ARCH} - 添加当前算子目录和公共 include 目录 - 将 object target 注册到全局 property ASCEND_OPS_OPERATOR_TARGETS 顶层 _C extension 再从 ASCEND_OPS_OPERATOR_TARGETS 中收集 $<TARGET_OBJECTS:${OPERATOR_TARGET}>,并在存在算子 target 时链接这些 target。这样算子自身需要的库可以留在各自目录,例如: ```cmake ascend_ops_add_current_op(OP_TARGET) target_link_libraries(${OP_TARGET} PUBLIC platform) target_link_libraries(${OP_TARGET} PUBLIC tiling_api) ``` ### 5. Python 构建入口保持轻量 setup.py 不再负责把 NPU_ARCH 翻译成 CMake 参数。架构选择统一留给 CMake 层处理,Python 侧只传入 Torch/Torch NPU 路径和构建类型。 同时 Python 构建入口优先选择 Ninja: - 环境中存在 ninja 时使用 -G Ninja - 否则回退到 Unix Makefiles requirements.txt 补充 ninja,使示例默认构建路径更稳定。 ### 6. 新增算子的维护方式 新增算子只需要按目标架构创建目录和 .asc 文件: ```text csrc/<op_name>/<NPU_ARCH>/CMakeLists.txt csrc/<op_name>/<NPU_ARCH>/<op_name>.asc ``` CMakeLists.txt 的最小内容为: ```cmake ascend_ops_add_current_op(OP_TARGET) ``` 如果算子需要额外库或编译选项,可继续对 ${OP_TARGET} 调用 target_link_libraries()target_compile_options() 等 target 级 CMake API,不需要修改顶层对象列表或全局变量。 ## 关联的Issue 无 ## 测试 测试结果: ```text 119 passed, 1 warning in 6.80s ``` ## 文档更新 更新 examples/fast_kernel_launch_example/README.md: - 补充默认 NPU_ARCH=dav-2201、可通过环境变量覆盖,以及当前支持 dav-2201/dav-3510 - 将新增算子开发说明从 .cpp + add_sources("--npu-arch=...") 更新为 .asc + ascend_ops_add_current_op(OP_TARGET) ## 类型标签 - [ ] Bug修复 - [x] 新特性 - [ ] 性能优化 - [x] 文档更新 - [x] 其他,请描述:构建重构 See merge request: cann/ops-math!25201 个月前
fix fast kernel launch example smoke test Co-authored-by: zhangzijie<zhangzijie11@hisilicon.com> # message auto-generated for no-merge-commit merge: !456 merge master into master fix fast kernel launch example smoke test Created-by: zhangzijie Commit-by: zhangzijie Merged-by: cann-robot Description: ## 描述 <!--在这里详细描述你的改动,包括改动的原因和所采取的方法。--> 修复 fast kernel launch example 冒烟测试 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue,请在这里提供Issue链接。--> <!-- 如果这个PR是为了解决特定的问题单,请在这里描述问题单单号。--> ## 测试 <!--描述进行了哪些测试来验证你的改动。包括但不限于二级冒烟、算子泛化等。--> ## 文档更新 <!--如果这个PR包含文档的更新,请在这里指出。例如:更新了README.md文件。--> ## 类型标签 <!-- [x] 表示选中 --> - [ ] Bug修复 - [ ] 新特性 - [ ] 性能优化 - [ ] 文档更新 - [ ] 其他,请描述: See merge request: cann/ops-math!4565 个月前
feat: migrate fast kernel launch example to ASC CMake Co-authored-by: zhangzijie<zhangzijie11@hisilicon.com> # message auto-generated for no-merge-commit merge: !2520 merge feature/fast-kernel-launch-asc into master feat: migrate fast kernel launch example to ASC CMake Created-by: zhangzijie Commit-by: zhangzijie Merged-by: cann-robot Description: ## 描述 将 examples/fast_kernel_launch_example 迁移到 CMake 原生 ASC 语言构建,并整理 Fast Kernel Launch 示例的算子构建组织方式: - 将 add/sqrt/gelu/layer_norm 算子实现从 .cpp 重命名为 .asc - 顶层 CMake 使用 find_package(ASC REQUIRED)project(... LANGUAGES C CXX ASC) 启用 ASC 语言 - 将示例算子目录从 ascend910b 收敛到编译器使用的 NPU_ARCH 命名,例如 dav-2201 - 将算子对象文件收集方式从全局 OBJECTS_LIST cache 变量改为 CMake object target + global property - 构建入口优先使用 Ninja,并在 README 中补充 NPU_ARCH 和新增算子的开发方式 ## Refactor 方案 ### 1. 构建入口改为 CMake 原生 ASC 语言 原方案通过普通 C/CXX 工程、手动指定 bisheng 编译器、给 .cpp 源文件追加 -xasc 的方式触发 ASC 编译。该方式把 ASC 编译细节散落在自定义宏和全局变量中,新增算子时需要理解较多隐藏约定。 本次重构改为在顶层 CMakeLists.txt 中先加载 cmake/ascend.cmake,再执行: ```cmake find_package(ASC REQUIRED) project(${PKG_NAME} VERSION 1.0.0 LANGUAGES C CXX ASC) ``` 这样 ASC 被声明为工程语言,.asc 源文件由 CMake/ASC 包正常识别,不再依赖 LANGUAGE CXX + -xasc 的绕行方式。cmake/ascend.cmake 只负责定位 Ascend Toolkit、bisheng 和默认 toolchain,ASC include/link 细节交给 find_package(ASC) 提供的能力处理。 ### 2. NPU 架构命名从芯片名切换到编译器参数 原目录使用 ascend910b,但实际传给编译器的是 --npu-arch=dav-2201。这会让目录名、CMake 参数和编译器参数不一致。 本次重构统一使用编译器 --npu-arch 对应的取值作为目录名和构建参数: - 默认 NPU_ARCH=dav-2201 - 支持 dav-2201dav-3510 - 支持通过环境变量 NPU_ARCH 或 CMake cache 覆盖 - 配置阶段校验不支持的架构并直接报错 因此示例目录迁移为: ```text csrc/<op_name>/<NPU_ARCH>/<op_name>.asc ``` 当前 PR 中 add/sqrt/gelu/layer_norm 均迁移到 dav-2201 目录。 ### 3. 算子发现从手写遍历改为按架构目录收敛 原 recursive_add_subdirectory() 会扫描 csrc 下每个算子的 ${NPU_ARCH}/CMakeLists.txt,但配合旧的 ascend910b 默认值时,目录名和真实编译参数存在错位。 新实现按如下规则发现算子: ```text csrc/*/${NPU_ARCH}/CMakeLists.txt ``` 并对结果排序后逐个 add_subdirectory(),保证构建输入稳定。如果当前架构下没有算子目录,会输出 warning,顶层仍可生成 dummy extension module,便于定位问题而不是在隐式变量处失败。 ### 4. 算子编译单元改为 object target 原 add_sources() 宏会: - 清理/重置部分全局 CMake 变量 - 递归查找 .cpp - 手动设置 LANGUAGE CXXCOMPILE_FLAGS - 将 $<TARGET_OBJECTS:...> 写入全局 cache 变量 OBJECTS_LIST 这类全局可变状态不利于维护,也容易受 CMake 配置顺序影响。 新方案提供: ```cmake ascend_ops_add_current_op(OP_TARGET) ``` 每个算子目录调用后会生成独立 object library,target 名包含算子名和 NPU_ARCH,例如 add_dav_2201_obj。函数内部负责: - 查找当前目录下的 .asc 源文件 - 为该 object target 添加通用编译选项 - 显式追加 --npu-arch=${NPU_ARCH} - 添加当前算子目录和公共 include 目录 - 将 object target 注册到全局 property ASCEND_OPS_OPERATOR_TARGETS 顶层 _C extension 再从 ASCEND_OPS_OPERATOR_TARGETS 中收集 $<TARGET_OBJECTS:${OPERATOR_TARGET}>,并在存在算子 target 时链接这些 target。这样算子自身需要的库可以留在各自目录,例如: ```cmake ascend_ops_add_current_op(OP_TARGET) target_link_libraries(${OP_TARGET} PUBLIC platform) target_link_libraries(${OP_TARGET} PUBLIC tiling_api) ``` ### 5. Python 构建入口保持轻量 setup.py 不再负责把 NPU_ARCH 翻译成 CMake 参数。架构选择统一留给 CMake 层处理,Python 侧只传入 Torch/Torch NPU 路径和构建类型。 同时 Python 构建入口优先选择 Ninja: - 环境中存在 ninja 时使用 -G Ninja - 否则回退到 Unix Makefiles requirements.txt 补充 ninja,使示例默认构建路径更稳定。 ### 6. 新增算子的维护方式 新增算子只需要按目标架构创建目录和 .asc 文件: ```text csrc/<op_name>/<NPU_ARCH>/CMakeLists.txt csrc/<op_name>/<NPU_ARCH>/<op_name>.asc ``` CMakeLists.txt 的最小内容为: ```cmake ascend_ops_add_current_op(OP_TARGET) ``` 如果算子需要额外库或编译选项,可继续对 ${OP_TARGET} 调用 target_link_libraries()target_compile_options() 等 target 级 CMake API,不需要修改顶层对象列表或全局变量。 ## 关联的Issue 无 ## 测试 测试结果: ```text 119 passed, 1 warning in 6.80s ``` ## 文档更新 更新 examples/fast_kernel_launch_example/README.md: - 补充默认 NPU_ARCH=dav-2201、可通过环境变量覆盖,以及当前支持 dav-2201/dav-3510 - 将新增算子开发说明从 .cpp + add_sources("--npu-arch=...") 更新为 .asc + ascend_ops_add_current_op(OP_TARGET) ## 类型标签 - [ ] Bug修复 - [x] 新特性 - [ ] 性能优化 - [x] 文档更新 - [x] 其他,请描述:构建重构 See merge request: cann/ops-math!25201 个月前
feat: migrate fast kernel launch example to ASC CMake Co-authored-by: zhangzijie<zhangzijie11@hisilicon.com> # message auto-generated for no-merge-commit merge: !2520 merge feature/fast-kernel-launch-asc into master feat: migrate fast kernel launch example to ASC CMake Created-by: zhangzijie Commit-by: zhangzijie Merged-by: cann-robot Description: ## 描述 将 examples/fast_kernel_launch_example 迁移到 CMake 原生 ASC 语言构建,并整理 Fast Kernel Launch 示例的算子构建组织方式: - 将 add/sqrt/gelu/layer_norm 算子实现从 .cpp 重命名为 .asc - 顶层 CMake 使用 find_package(ASC REQUIRED)project(... LANGUAGES C CXX ASC) 启用 ASC 语言 - 将示例算子目录从 ascend910b 收敛到编译器使用的 NPU_ARCH 命名,例如 dav-2201 - 将算子对象文件收集方式从全局 OBJECTS_LIST cache 变量改为 CMake object target + global property - 构建入口优先使用 Ninja,并在 README 中补充 NPU_ARCH 和新增算子的开发方式 ## Refactor 方案 ### 1. 构建入口改为 CMake 原生 ASC 语言 原方案通过普通 C/CXX 工程、手动指定 bisheng 编译器、给 .cpp 源文件追加 -xasc 的方式触发 ASC 编译。该方式把 ASC 编译细节散落在自定义宏和全局变量中,新增算子时需要理解较多隐藏约定。 本次重构改为在顶层 CMakeLists.txt 中先加载 cmake/ascend.cmake,再执行: ```cmake find_package(ASC REQUIRED) project(${PKG_NAME} VERSION 1.0.0 LANGUAGES C CXX ASC) ``` 这样 ASC 被声明为工程语言,.asc 源文件由 CMake/ASC 包正常识别,不再依赖 LANGUAGE CXX + -xasc 的绕行方式。cmake/ascend.cmake 只负责定位 Ascend Toolkit、bisheng 和默认 toolchain,ASC include/link 细节交给 find_package(ASC) 提供的能力处理。 ### 2. NPU 架构命名从芯片名切换到编译器参数 原目录使用 ascend910b,但实际传给编译器的是 --npu-arch=dav-2201。这会让目录名、CMake 参数和编译器参数不一致。 本次重构统一使用编译器 --npu-arch 对应的取值作为目录名和构建参数: - 默认 NPU_ARCH=dav-2201 - 支持 dav-2201dav-3510 - 支持通过环境变量 NPU_ARCH 或 CMake cache 覆盖 - 配置阶段校验不支持的架构并直接报错 因此示例目录迁移为: ```text csrc/<op_name>/<NPU_ARCH>/<op_name>.asc ``` 当前 PR 中 add/sqrt/gelu/layer_norm 均迁移到 dav-2201 目录。 ### 3. 算子发现从手写遍历改为按架构目录收敛 原 recursive_add_subdirectory() 会扫描 csrc 下每个算子的 ${NPU_ARCH}/CMakeLists.txt,但配合旧的 ascend910b 默认值时,目录名和真实编译参数存在错位。 新实现按如下规则发现算子: ```text csrc/*/${NPU_ARCH}/CMakeLists.txt ``` 并对结果排序后逐个 add_subdirectory(),保证构建输入稳定。如果当前架构下没有算子目录,会输出 warning,顶层仍可生成 dummy extension module,便于定位问题而不是在隐式变量处失败。 ### 4. 算子编译单元改为 object target 原 add_sources() 宏会: - 清理/重置部分全局 CMake 变量 - 递归查找 .cpp - 手动设置 LANGUAGE CXXCOMPILE_FLAGS - 将 $<TARGET_OBJECTS:...> 写入全局 cache 变量 OBJECTS_LIST 这类全局可变状态不利于维护,也容易受 CMake 配置顺序影响。 新方案提供: ```cmake ascend_ops_add_current_op(OP_TARGET) ``` 每个算子目录调用后会生成独立 object library,target 名包含算子名和 NPU_ARCH,例如 add_dav_2201_obj。函数内部负责: - 查找当前目录下的 .asc 源文件 - 为该 object target 添加通用编译选项 - 显式追加 --npu-arch=${NPU_ARCH} - 添加当前算子目录和公共 include 目录 - 将 object target 注册到全局 property ASCEND_OPS_OPERATOR_TARGETS 顶层 _C extension 再从 ASCEND_OPS_OPERATOR_TARGETS 中收集 $<TARGET_OBJECTS:${OPERATOR_TARGET}>,并在存在算子 target 时链接这些 target。这样算子自身需要的库可以留在各自目录,例如: ```cmake ascend_ops_add_current_op(OP_TARGET) target_link_libraries(${OP_TARGET} PUBLIC platform) target_link_libraries(${OP_TARGET} PUBLIC tiling_api) ``` ### 5. Python 构建入口保持轻量 setup.py 不再负责把 NPU_ARCH 翻译成 CMake 参数。架构选择统一留给 CMake 层处理,Python 侧只传入 Torch/Torch NPU 路径和构建类型。 同时 Python 构建入口优先选择 Ninja: - 环境中存在 ninja 时使用 -G Ninja - 否则回退到 Unix Makefiles requirements.txt 补充 ninja,使示例默认构建路径更稳定。 ### 6. 新增算子的维护方式 新增算子只需要按目标架构创建目录和 .asc 文件: ```text csrc/<op_name>/<NPU_ARCH>/CMakeLists.txt csrc/<op_name>/<NPU_ARCH>/<op_name>.asc ``` CMakeLists.txt 的最小内容为: ```cmake ascend_ops_add_current_op(OP_TARGET) ``` 如果算子需要额外库或编译选项,可继续对 ${OP_TARGET} 调用 target_link_libraries()target_compile_options() 等 target 级 CMake API,不需要修改顶层对象列表或全局变量。 ## 关联的Issue 无 ## 测试 测试结果: ```text 119 passed, 1 warning in 6.80s ``` ## 文档更新 更新 examples/fast_kernel_launch_example/README.md: - 补充默认 NPU_ARCH=dav-2201、可通过环境变量覆盖,以及当前支持 dav-2201/dav-3510 - 将新增算子开发说明从 .cpp + add_sources("--npu-arch=...") 更新为 .asc + ascend_ops_add_current_op(OP_TARGET) ## 类型标签 - [ ] Bug修复 - [x] 新特性 - [ ] 性能优化 - [x] 文档更新 - [x] 其他,请描述:构建重构 See merge request: cann/ops-math!25201 个月前
README.md

Fast Kernel Launch

简介

本文档演示如何使用Ascend C和PyTorch Extension能力开发自定义NPU算子。

核心优势:

  • 单交付件: 一个文件完成算子开发和PyTorch框架适配。

  • 高效调用: 使用<<<>>>语法启动核函数,流程简单高效。

环境部署 | Prerequisites

  • 请先参考环境部署完成基础环境搭建
  • gcc 9.4.0+
  • python 3.8+
  • torch>=2.6.0
  • 对应版本的torch_npu

安装步骤 | Installation Steps

  1. 进入examples/fast_kernel_launch_example目录。

  2. 安装依赖 | Install Dependencies:

    python3 -m pip install -r requirements.txt
    
  3. 构建Wheel包 | Build the Wheel:

    # -n: non-isolated build (uses existing environment)
    python3 -m build --wheel -n
    

    默认使用dav-2201作为NPU编译架构。可通过NPU_ARCH环境变量指定支持的架构:

    NPU_ARCH=dav-2201 python3 -m build --wheel -n
    

    当前支持的NPU_ARCH取值为dav-2201dav-3510

    构建完成后,产物在当前目录的dist文件夹下,产物名ascend_ops-1.0.0-${python_version}-abi3-${arch}.whl${python_version}表示当前环境中的python版本(python3.8.3为cp38),${arch}表示CPU架构。

  4. 安装Wheel包 | Install Package:

    python3 -m pip install dist/*.whl --force-reinstall --no-deps
    
  5. (可选)再次构建前建议先执行以下命令清理编译缓存

     python setup.py clean
    

快速开始 | Quick Start

安装完成后,您可以像使用普通PyTorch操作一样使用NPU算子,以add算子调用为例。

import torch
import torch_npu
import ascend_ops  # 构建出的python包

# Initialize data on NPU
x = torch.randn(10, 32, dtype=torch.float32).npu()
y = torch.randn(10, 32, dtype=torch.float32).npu()

# Call the custom NPU operator
npu_result = torch.ops.ascend_ops.add(x, y)  # PyTorch Custom Operator Dispatch机制: torch.ops.<library_name>.<operator_name>

# Verify against CPU ATen implementation
cpu_x = x.cpu()
cpu_y = y.cpu()
cpu_result = cpu_x + cpu_y

assert torch.allclose(cpu_result, npu_result.cpu(), rtol=1e-6)
print("Verification successful!")

开发指南:新增一个算子 | Developer Guide: Adding a New Operator

为了实现一个新算子(如add),您只需要提供一个.asc源文件实现即可。

  1. 首先您需要在csrc目录下使用算子名add建立一个文件夹,在此文件夹内使用目标NPU_ARCH建立一个子文件夹,例如dav-2201

  2. NPU_ARCH目录下新建一个CMakeLists.txt

    ascend_ops_add_current_op(OP_TARGET)
    

    这里NPU_ARCH会传递给编译器的--npu-arch参数,当前支持dav-2201dav-3510。获取方法参考NpuArch说明和使用指导。如果算子需要额外依赖,可在同一个CMakeLists.txt中为${OP_TARGET}显式添加。

  3. NPU_ARCH目录下新建一个add.asc(建议使用算子名为文件名)。这个文件包含了开发一个AI Core算子所需要的全部模块。

    • 算子Schema注册
    • 算子Meta Function实现 & 注册
    • 算子Kernel实现 (Ascend C)
    • 算子NPU调用实现 & 注册
    #include <ATen/Operators.h>
    #include <torch/all.h>
    #include <torch/library.h>
    #include "torch_npu/csrc/core/npu/NPUStream.h"
    #include "torch_npu/csrc/framework/OpCommand.h"
    #include "kernel_operator.h"
    #include "platform/platform_ascendc.h"
    #include <type_traits>
    
    namespace ascend_ops {  // 当前项目为一个命名空间
    namespace Add {         // 建议每个算子自己有一个独立的namespace,防止全局变量污染
    
    /**
     * 将算子schema注册给PyTorch框架
     * 框架知道有这样一个算子
     */
    // Register the operator's schema
    TORCH_LIBRARY_FRAGMENT(EXTENSION_MODULE_NAME, m)
    {
        m.def("add(Tensor x, Tensor y) -> Tensor");
    }
    
    /**
     * 实现算子的Meta函数,即InferShape+InferDtype
     * 根据输入推导出这个算子的输出是什么样子,需要多少空间,不需要实际计算这个算子
     */
    // Meta function implementation of Add
    torch::Tensor add_meta(const torch::Tensor &x, const torch::Tensor &y)
    {
        TORCH_CHECK(x.sizes() == y.sizes(), "The shapes of x and y must be the same.");
        auto z = torch::empty_like(x);
        return z;
    }
    
    /**
     * 将算子的Meta函数注册给框架
     * 框架可以调用这个Meta函数,在真正执行这个算子计算前知道需要多大空间
     * 后续可以支持torch.compile/AutoGrad/AclGraph等图加速
     */
    // Register the Meta implementation
    TORCH_LIBRARY_IMPL(EXTENSION_MODULE_NAME, Meta, m)
    {
        m.impl("add", add_meta);
    }
    
    /**
     * NPU算子Kernel实现,使用AscendC API,面向当前的soc编写
     */
    template <typename T>
    __global__ __aicore__ void add_kernel(GM_ADDR x, GM_ADDR y, GM_ADDR z, int64_t totalLength, int64_t blockLength, uint32_t tileSize)
    {
        // kernel implementation
    }
    
    /**
     * 实现算子调用接口
     * 在这个接口中, 需要完成NPU Kernel的调用
     * 1. 计算出输出的Tensor的个数/Shape/Dtype(可以调用Meta函数实现,也可以直接实现)
     * 2. 计算Tiling:根据Shape得到如何分块计算
     * 3. 调用NPU Kernel
     *
     */
    torch::Tensor add_npu(const torch::Tensor &x, const torch::Tensor &y)
    {
        // OptionalDeviceGuard 确保后续操作在正确的设备上下文执行
        // 它会记录当前设备状态,执行完作用域代码后自动恢复
        const c10::OptionalDeviceGuard guard(x.device());
        auto z = add_meta(x, y);
        auto stream = c10_npu::getCurrentNPUStream().stream(false);
        int64_t totalLength, numBlocks, blockLength, tileSize;
        totalLength = x.numel();
        std::tie(numBlocks, blockLength, tileSize) = calc_tiling_params(totalLength);
        auto x_ptr = (GM_ADDR)x.data_ptr();
        auto y_ptr = (GM_ADDR)y.data_ptr();
        auto z_ptr = (GM_ADDR)z.data_ptr();
        auto acl_call = [=]() -> int {
            AT_DISPATCH_SWITCH(
                x.scalar_type(), "add_npu",
                // 根据不同的数据类型,调用不同的NPU Kernel
                AT_DISPATCH_CASE(torch::kFloat32, [&] {
                    using scalar_t = float;
                    add_kernel<scalar_t><<<numBlocks, nullptr, stream>>>(x_ptr, y_ptr, z_ptr, totalLength, blockLength, tileSize);
                })
                AT_DISPATCH_CASE(torch::kFloat16, [&] {
                    using scalar_t = half;
                    add_kernel<scalar_t><<<numBlocks, nullptr, stream>>>(x_ptr, y_ptr, z_ptr, totalLength, blockLength, tileSize);
                })
                AT_DISPATCH_CASE(torch::kInt32, [&] {
                    using scalar_t = int32_t;
                    add_kernel<scalar_t><<<numBlocks, nullptr, stream>>>(x_ptr, y_ptr, z_ptr, totalLength, blockLength, tileSize);
                })
            );
            return 0;
        };
        // 需要使用RunOpApi/RunOpApiV2接口调用,保证时序与TorchNPU调用aclnn接口一致。
        at_npu::native::OpCommand::RunOpApi("Add", acl_call);
        return z;
    }
    
    /**
     * 将算子的调用函数注册给框架,Device为PrivateUse1
     * 框架知道当输入均在NPU Device上时,Dispatch到这个算子实现
     */
    // Register the NPU implementation
    TORCH_LIBRARY_IMPL(EXTENSION_MODULE_NAME, PrivateUse1, m)
    {
        m.impl("add", add_npu);
    }
    
    }  // namespace Add
    }  // namespace ascend_ops
    
    
  4. 参考安装步骤章节重新构建Wheel包并安装。

  5. 基于pytest测试算子API,请参考test_add.py的实现。