| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
feat: 优化Nano模型内存拷贝 | 2 个月前 | |
fix：BorrowOpCompileContext 入参类型变更 Co-authored-by: lfz<220252399@seu.edu.cn> # message auto-generated for no-merge-commit merge: !4646 merge fix2 into develop fix：BorrowOpCompileContext 入参类型变更 Created-by: lfz2812 Commit-by: lfz Merged-by: cann-robot Description: # Pull Request ## 描述 主要调整了自定义算子（custom op）场景下编译上下文对象在 Python/C++ 绑定层之间的传递方式：原先 BorrowOpCompileContext 接收 uintptr_t 整数句柄，现在改为接收 py::capsule，并在绑定侧通过 GetContextFromCapsule 校验 capsule 类型名后取出 gert::OpCompileContext 指针，使上下文传递具备类型安全校验，同时删除了原基于整数句柄的空指针检查逻辑。 ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [x] 🐛 Bug 修复 - [ ] ✨ 新功能 - [x] 💄 代码风格更新（格式化，局部变量） - [ ] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [ ] 📦 构建过程或辅助工具的变动 - [ ] 📝 文档内容更新 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在当前页面的右侧'关联Issue'部分添加相应Issue链接，并勾选'合并后关闭已关联的 Issue'选项。 --> ## 如何测试 描述测试此变更的步骤和前提条件： 1. 2. ## 核对清单 <!-- [x] 表示选中 --> - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（如： feat:, fix:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 在此添加任何其他关于本次 PR 的说明。 See merge request: cann/ge!4646 | 2 个月前 | |
fix om2 dump config bug | 1 个月前 | |
fix: precommit整改 Co-authored-by: yelongjian<yelongjian1@huawei.com> # message auto-generated for no-merge-commit merge: !3726 merge dev-precommit into develop fix: precommit整改 Created-by: yelongjian Commit-by: yelongjian Merged-by: cann-robot Description: # Pull Request ## 描述 precommit整改 ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [ ] 🐛 Bug 修复 - [ ] ✨ 新功能 - [x] 💄 代码风格更新（格式化，局部变量） - [ ] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [ ] 📦 构建过程或辅助工具的变动 - [ ] 📝 文档内容更新 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在当前页面的右侧'关联Issue'部分添加相应Issue链接，并勾选'合并后关闭已关联的 Issue'选项。 --> ## 如何测试 描述测试此变更的步骤和前提条件： 1.NA ## 核对清单 <!-- [x] 表示选中 --> - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（如： feat:, fix:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 在此添加任何其他关于本次 PR 的说明。 See merge request: cann/ge!3726 | 4 个月前 | |
fix: precommit整改 Co-authored-by: yelongjian<yelongjian1@huawei.com> # message auto-generated for no-merge-commit merge: !3726 merge dev-precommit into develop fix: precommit整改 Created-by: yelongjian Commit-by: yelongjian Merged-by: cann-robot Description: # Pull Request ## 描述 precommit整改 ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [ ] 🐛 Bug 修复 - [ ] ✨ 新功能 - [x] 💄 代码风格更新（格式化，局部变量） - [ ] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [ ] 📦 构建过程或辅助工具的变动 - [ ] 📝 文档内容更新 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在当前页面的右侧'关联Issue'部分添加相应Issue链接，并勾选'合并后关闭已关联的 Issue'选项。 --> ## 如何测试 描述测试此变更的步骤和前提条件： 1.NA ## 核对清单 <!-- [x] 表示选中 --> - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（如： feat:, fix:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 在此添加任何其他关于本次 PR 的说明。 See merge request: cann/ge!3726 | 4 个月前 | |
【feat】: Support PCIe Through Co-authored-by: kantao1<kantao1@huawei.com> # message auto-generated for no-merge-commit merge: !4394 merge pcie_through into develop 【feat】: Support PCIe Through Created-by: kantao1 Commit-by: kantao1 Merged-by: cann-robot Description: # Pull Request 接口评审时间：2026/08/06(周四) ## 描述 PCIE Through 是 Ascend NPU 硬件能力，允许 device 端算子通过 PCIE 总线直接访问 host 内存。当前单算子场景可用，但在模型编译场景下，编译期无法确定输入 tensor 的真实的地址范围，导致 tiling 阶段无法选择正确 kernel。 本特性通过编译期能力识别 + TilingContext 注入 + 执行期上下文扩展（动态 shape），解决此问题。 ### 核心设计 **编译阶段（lowering）**： - BuildTilingPcieThroughInput 从 DefaultOpImplSpaceRegistryV2 查询算子是否支持 PCIe Through，同时通过 IsPcieThroughEnabled 检查运行环境（option 开关、芯片能力、设备连接类型），两者均满足时将 pcie_through_flag 初始值设为 true - IsPcieThroughEnabled 结果通过 thread_local static 缓存，每个线程仅计算一次 - BuildTilingCommonInputs 在 input_addrs 可用时，通过 BuildRefTensor 将输入从 StorageShape 升级为包含设备地址的 Tensor，使运行时能通过 GetInputTensor(i)->GetAddr() 获取实际输入地址 **运行时（executor）**： - UpdatePcieThroughFlag 读取 pcie_through_flag，为 false 时直接跳过；为 true 时通过 IsAnyInputInPcieRange 遍历输入地址，检查是否落在 PCIe 地址范围内 - 若存在 PCIe 地址 → flag 保持 true；否则改为 false - GetPcieThroughFlag() 接口供 Tiling 函数和缓存键计算使用 **关键修复**： - fwk_data_idx 恢复后向计算（input_num - kFwkDataOffset），修复 symbol tiling 路径中前向计算导致的 702 行 ASSERT 失败 - GetPcieThroughFlag 改为后向 GetInputNum() - 1，与 pcie_through_flag 作为最后一个输入的布局一致 - TilingForAtomic 补充 BuildTilingPcieThroughInput 调用，保证输入布局一致性 - BuildGeneralTilingCacheKey 简化为直接读 GetPcieThroughFlag()，消除运行时查 space_registry 的版本不一致问题 ## 变更类型 - [x] ✨ 新功能 - [x] 🐛 Bug 修复 ## 关联的Issue <!-- 请在右侧关联对应 Issue --> ## 如何测试 1. 编译 UT：make -C cmake-build-gcov ut_fast_runtime2_test ut_exe_graph ut_register -j$(nproc) 2. 运行 PCIe Through 相关 UT：--gtest_filter='*PcieThrough*' 3. 运行 TilingContextBuilder UT：--gtest_filter='TilingContextBuilderUT.*' 4. 在 PCIe 直通环境上执行模型推理，验证 pcie_through 算子正确识别地址并优化搬运 ## 核对清单 - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签 - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定 ## 其他信息 ### 涉及文件 | 仓库 | 文件 | 改动说明 | |------|------|---------| | ge | runtime/v2/graph_builder/bg_tiling.cc | 新增 IsPcieThroughEnabled、BuildTilingPcieThroughInput；BuildTilingCommonInputs 支持 BuildRefTensor；TilingForAtomic 补充 pcie through 输入 | | ge | runtime/v2/kernel/common_kernel_impl/tiling.cc | 新增 IsAnyInputInPcieRange、UpdatePcieThroughFlag；fwk_data_idx 恢复后向计算；BuildGeneralTilingCacheKey 简化 | | ge | runtime/v2/kernel/common_kernel_impl/tiling.h | 新增 kPcieThroughFlag 枚举项 | | metadef | inc/external/exe_graph/runtime/tiling_context.h | GetPcieThroughFlag 改为后向计算 | | ge | tests/ | 新增 PCIe Through 相关 UT/ST 用例 | See merge request: cann/ge!4394 | 1 个月前 | |
【feat】: Support PCIe Through Co-authored-by: kantao1<kantao1@huawei.com> # message auto-generated for no-merge-commit merge: !4394 merge pcie_through into develop 【feat】: Support PCIe Through Created-by: kantao1 Commit-by: kantao1 Merged-by: cann-robot Description: # Pull Request 接口评审时间：2026/08/06(周四) ## 描述 PCIE Through 是 Ascend NPU 硬件能力，允许 device 端算子通过 PCIE 总线直接访问 host 内存。当前单算子场景可用，但在模型编译场景下，编译期无法确定输入 tensor 的真实的地址范围，导致 tiling 阶段无法选择正确 kernel。 本特性通过编译期能力识别 + TilingContext 注入 + 执行期上下文扩展（动态 shape），解决此问题。 ### 核心设计 **编译阶段（lowering）**： - BuildTilingPcieThroughInput 从 DefaultOpImplSpaceRegistryV2 查询算子是否支持 PCIe Through，同时通过 IsPcieThroughEnabled 检查运行环境（option 开关、芯片能力、设备连接类型），两者均满足时将 pcie_through_flag 初始值设为 true - IsPcieThroughEnabled 结果通过 thread_local static 缓存，每个线程仅计算一次 - BuildTilingCommonInputs 在 input_addrs 可用时，通过 BuildRefTensor 将输入从 StorageShape 升级为包含设备地址的 Tensor，使运行时能通过 GetInputTensor(i)->GetAddr() 获取实际输入地址 **运行时（executor）**： - UpdatePcieThroughFlag 读取 pcie_through_flag，为 false 时直接跳过；为 true 时通过 IsAnyInputInPcieRange 遍历输入地址，检查是否落在 PCIe 地址范围内 - 若存在 PCIe 地址 → flag 保持 true；否则改为 false - GetPcieThroughFlag() 接口供 Tiling 函数和缓存键计算使用 **关键修复**： - fwk_data_idx 恢复后向计算（input_num - kFwkDataOffset），修复 symbol tiling 路径中前向计算导致的 702 行 ASSERT 失败 - GetPcieThroughFlag 改为后向 GetInputNum() - 1，与 pcie_through_flag 作为最后一个输入的布局一致 - TilingForAtomic 补充 BuildTilingPcieThroughInput 调用，保证输入布局一致性 - BuildGeneralTilingCacheKey 简化为直接读 GetPcieThroughFlag()，消除运行时查 space_registry 的版本不一致问题 ## 变更类型 - [x] ✨ 新功能 - [x] 🐛 Bug 修复 ## 关联的Issue <!-- 请在右侧关联对应 Issue --> ## 如何测试 1. 编译 UT：make -C cmake-build-gcov ut_fast_runtime2_test ut_exe_graph ut_register -j$(nproc) 2. 运行 PCIe Through 相关 UT：--gtest_filter='*PcieThrough*' 3. 运行 TilingContextBuilder UT：--gtest_filter='TilingContextBuilderUT.*' 4. 在 PCIe 直通环境上执行模型推理，验证 pcie_through 算子正确识别地址并优化搬运 ## 核对清单 - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签 - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定 ## 其他信息 ### 涉及文件 | 仓库 | 文件 | 改动说明 | |------|------|---------| | ge | runtime/v2/graph_builder/bg_tiling.cc | 新增 IsPcieThroughEnabled、BuildTilingPcieThroughInput；BuildTilingCommonInputs 支持 BuildRefTensor；TilingForAtomic 补充 pcie through 输入 | | ge | runtime/v2/kernel/common_kernel_impl/tiling.cc | 新增 IsAnyInputInPcieRange、UpdatePcieThroughFlag；fwk_data_idx 恢复后向计算；BuildGeneralTilingCacheKey 简化 | | ge | runtime/v2/kernel/common_kernel_impl/tiling.h | 新增 kPcieThroughFlag 枚举项 | | metadef | inc/external/exe_graph/runtime/tiling_context.h | GetPcieThroughFlag 改为后向计算 | | ge | tests/ | 新增 PCIe Through 相关 UT/ST 用例 | See merge request: cann/ge!4394 | 1 个月前 | |
feat: 支持自定义算子能力识别与 Python 适配器 Co-authored-by: du-hua1024<duhua2@huawei.com> # message auto-generated for no-merge-commit merge: !3970 merge op-cpp into develop feat: 支持自定义算子能力识别与 Python 适配器 Created-by: du-hua1024 Commit-by: du-hua1024 Merged-by: cann-robot Description: # Pull Request ## 描述 本 PR 为 C++ 自定义算子补充能力标识和统一转型入口，并新增 Python custom op runtime adapter 的基础实现。 主要变更： - 新增 CustomOpCapability / CustomOpCast，让调用点按 capability 判断 EagerExecuteOp、CompilableOp、ShapeInferOp、PortableOp、ArgsUpdater。 - 将现有自定义算子执行、编译、shape 推导、序列化和地址刷新调用点从直接 dynamic_cast 切换为 CustomOpCast。 - 新增 custom_op_runtime 目标和 Python custom op adapter/registry 基础类型，用于承接 Python 自定义算子执行能力。 - 将 custom_op_runtime 纳入 ge-executor 构建和 ge-executor 包安装范围，并补充相关 UT 链接和用例。 ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [ ] 🐛 Bug 修复 - [x] ✨ 新功能 - [ ] 💄 代码风格更新（格式化，局部变量） - [ ] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [x] 📦 构建过程或辅助工具的变动 - [ ] 📝 文档内容更新 ## 关联的Issue 无。 ## 如何测试 新增及历史ut运行正常 ## 核对清单 <!-- [x] 表示选中 --> - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已确认本 PR 不涉及文档更新 - [x] 我在标题中使用了合适的类型标签（如：feat:, fix:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 本 PR 是自定义算子 Python eager 执行能力的 C++ capability 和 adapter 基础部分，Python bridge/公开 Python surface 可在后续 PR 中继续拆分提交。 See merge request: cann/ge!3970 | 3 个月前 |