| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
fix: 修复内存加载外置权重路径配置 Co-authored-by: Chang-an-HW<machangan@huawei.com> # message auto-generated for no-merge-commit merge: !4286 merge fix_load_mdl_from_mem_with_mem into develop fix: 修复内存加载外置权重路径配置 Created-by: Chang-an-HW Commit-by: Chang-an-HW Merged-by: cann-robot Description: # Pull Request ## 描述 修复传统 OM 模型从内存加载时，外置权重目录无法正确生效的问题： - ACL_MDL_LOAD_FROM_MEM_WITH_MEM：移除配置 ACL_MDL_WEIGHT_PATH_PTR 时的错误入口拦截，复用已有权重路径透传流程。 - ACL_MDL_LOAD_FROM_MEM_WITH_Q：将配置的外置权重目录传入 ge::ModelData::weight_path；非配置加载接口保持原行为。 - 补充 ACL 单元测试，并同步更新中英文外置权重特性文档及中文 API 文档。 本次修改仅覆盖传统 OM，OM2 作为后续补充支持；aclmdlSetExternalWeightAddress 配置的用户 Device 内存优先级保持不变。 ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [x] 🐛 Bug 修复 - [ ] ✨ 新功能 - [ ] 💄 代码风格更新（格式化，局部变量） - [ ] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [ ] 📦 构建过程或辅助工具的变动 - [x] 📝 文档内容更新 ## 关联的Issue 暂无关联 Issue。 ## 如何测试 描述测试此变更的步骤和前提条件： 1. 增量构建 ACL 单测目标：env CCACHE_DISABLE=1 cmake --build build_ut --target acl_utest -j8，构建通过。 2. 执行本次修改相关的 5 个定向用例，结果为 5/5 通过。 3. 在 build_ut 目录执行完整 acl_utest，结果为 518/518 通过。 ## 核对清单 <!-- [x] 表示选中 --> - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（如：feat:, fix:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 提交前检查已通过 clang-format、codespell 和 OAT Compliance Check。 See merge request: cann/ge!4286 | 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 | 2 个月前 | |
fix: 修复aclop与图模式混跑时Python Custom Op资源被提前释放的问题 Co-authored-by: qq_45842700<caodazhou@huawei.com> # message auto-generated for no-merge-commit merge: !4284 merge fix/custom-op-lifecycle into develop fix: 修复aclop与图模式混跑时Python Custom Op资源被提前释放的问题 Created-by: qq_45842700 Commit-by: qq_45842700 Merged-by: cann-robot Description: # Pull Request ## 描述 PR #4243 修复了 aclop 与图模式混跑时自定义 Pass 资源被提前释放的问题，但同一 GeGenerator::Finalize() 路径中 ShutdownCustomOpsForProcess() 仍被无条件调用，导致 Python Custom Op 存在同类生命周期缺陷（Issue #505）。 本 PR 参照 PR #4243 对 Pass 的修复方式，为 CustomOpLoader 引入 active_users_ 引用计数。 ### 核心修改 1. **runtime/custom_op/custom_op_loader.cc**：引入 active_users_ 引用计数 - Load()：每次调用 active_users_++，首次（active_users_ == 0）才真正加载；同时重置 shutdown_done_ = false 以支持 reload 后完整 shutdown - Unload()：每次调用 active_users_--，仅当 active_users_ 归零时才执行卸载（UnloadPythonCustomOps + ShutdownPythonCustomOpsForProcess） - 保留 ShutdownCustomOpsForProcess() 作为兼容 wrapper，内部调用 Unload() - 新增 cpp_custom_ops_loaded_ 标志和 RollbackCustomOpsLoad() 回滚方法 2. **调用点替换**（4 个文件）：将 ShutdownCustomOpsForProcess() 替换为 UnloadCustomOps() - compiler/api/generator/ge_generator.cc:510（aclop 路径，最关键） - api/session/client/ge_api_v2.cc:267,405（GEInitialize guard + GEFinalize） - compiler/api/aclgrph/ge_ir_build.cc:443,490（aclgrphBuildInitialize guard + aclgrphBuildFinalize） - api/atc/main_impl.cc:2383（ATC 清理路径） ## 变更类型 - [x] 🐛 Bug 修复 ## 关联的Issue - Issue #505 - PR #4243（Pass 同类修复） ## 如何测试 ### Bug 复现条件 在同一 Python 进程内： 1. Phase 1：GEInitialize → Session.add_graph（含 Python Custom Op）→ Session.run_graph → Custom Op execute 成功 2. Phase 2：torch_npu.npu.set_compile_mode(jit_compile=True) → 执行 matmul 等 NPU 单算子 → aclop 创建临时 GeGenerator → Finalize → ShutdownCustomOpsForProcess 3. Phase 3：Session.run_graph（同一已编译图）→ Custom Op 裸指针悬空 ### 修复前 Phase 3 SIGSEGV (exit code 139)，Custom Op 被 aclop Finalize 卸载后悬空指针导致段错误。 ### 修复后 - Phase 1：Custom Op 正常加载执行 ✅ - Phase 2：aclop 编译成功 ✅ - Phase 3：Custom Op 仍正常执行 ✅（不再崩溃） - 引用计数日志：LoadCustomOps active_users_=1 → =2（aclop Load）→ =1（aclop Unload，不卸载）→ =0（GEFinalize，真正卸载） ### 测试环境 - Ascend 910, CANN 9.2.0, Python 3.12 ## 核对清单 - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我在标题中使用了合适的类型标签（fix:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定 ## 其他信息 修复方案完全对齐 PR #4243 对 Pass 的修复模式（active_users_ 引用计数），改动量小、风险可控。Pass 和 Custom Op 的修复模式一致，便于后续维护。 See merge request: cann/ge!4284 | 1 个月前 | |
feat: 自定义算子 AnnotatedArgsOp 地址刷新接口 Python 化 | 1 个月前 | |
fix: 修复aclop与图模式混跑时Python Custom Op资源被提前释放的问题 Co-authored-by: qq_45842700<caodazhou@huawei.com> # message auto-generated for no-merge-commit merge: !4284 merge fix/custom-op-lifecycle into develop fix: 修复aclop与图模式混跑时Python Custom Op资源被提前释放的问题 Created-by: qq_45842700 Commit-by: qq_45842700 Merged-by: cann-robot Description: # Pull Request ## 描述 PR #4243 修复了 aclop 与图模式混跑时自定义 Pass 资源被提前释放的问题，但同一 GeGenerator::Finalize() 路径中 ShutdownCustomOpsForProcess() 仍被无条件调用，导致 Python Custom Op 存在同类生命周期缺陷（Issue #505）。 本 PR 参照 PR #4243 对 Pass 的修复方式，为 CustomOpLoader 引入 active_users_ 引用计数。 ### 核心修改 1. **runtime/custom_op/custom_op_loader.cc**：引入 active_users_ 引用计数 - Load()：每次调用 active_users_++，首次（active_users_ == 0）才真正加载；同时重置 shutdown_done_ = false 以支持 reload 后完整 shutdown - Unload()：每次调用 active_users_--，仅当 active_users_ 归零时才执行卸载（UnloadPythonCustomOps + ShutdownPythonCustomOpsForProcess） - 保留 ShutdownCustomOpsForProcess() 作为兼容 wrapper，内部调用 Unload() - 新增 cpp_custom_ops_loaded_ 标志和 RollbackCustomOpsLoad() 回滚方法 2. **调用点替换**（4 个文件）：将 ShutdownCustomOpsForProcess() 替换为 UnloadCustomOps() - compiler/api/generator/ge_generator.cc:510（aclop 路径，最关键） - api/session/client/ge_api_v2.cc:267,405（GEInitialize guard + GEFinalize） - compiler/api/aclgrph/ge_ir_build.cc:443,490（aclgrphBuildInitialize guard + aclgrphBuildFinalize） - api/atc/main_impl.cc:2383（ATC 清理路径） ## 变更类型 - [x] 🐛 Bug 修复 ## 关联的Issue - Issue #505 - PR #4243（Pass 同类修复） ## 如何测试 ### Bug 复现条件 在同一 Python 进程内： 1. Phase 1：GEInitialize → Session.add_graph（含 Python Custom Op）→ Session.run_graph → Custom Op execute 成功 2. Phase 2：torch_npu.npu.set_compile_mode(jit_compile=True) → 执行 matmul 等 NPU 单算子 → aclop 创建临时 GeGenerator → Finalize → ShutdownCustomOpsForProcess 3. Phase 3：Session.run_graph（同一已编译图）→ Custom Op 裸指针悬空 ### 修复前 Phase 3 SIGSEGV (exit code 139)，Custom Op 被 aclop Finalize 卸载后悬空指针导致段错误。 ### 修复后 - Phase 1：Custom Op 正常加载执行 ✅ - Phase 2：aclop 编译成功 ✅ - Phase 3：Custom Op 仍正常执行 ✅（不再崩溃） - 引用计数日志：LoadCustomOps active_users_=1 → =2（aclop Load）→ =1（aclop Unload，不卸载）→ =0（GEFinalize，真正卸载） ### 测试环境 - Ascend 910, CANN 9.2.0, Python 3.12 ## 核对清单 - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我在标题中使用了合适的类型标签（fix:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定 ## 其他信息 修复方案完全对齐 PR #4243 对 Pass 的修复模式（active_users_ 引用计数），改动量小、风险可控。Pass 和 Custom Op 的修复模式一致，便于后续维护。 See merge request: cann/ge!4284 | 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 | 2 个月前 |