| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
feat：声明式自定义算子的辅流申请功能 Co-authored-by: Chang-an-HW<machangan@huawei.com> # message auto-generated for no-merge-commit merge: !4934 merge declarative-custom-op-attached-stream-pr into develop feat：声明式自定义算子的辅流申请功能 Created-by: Chang-an-HW Commit-by: Chang-an-HW Merged-by: cann-robot Description: # Pull Request ## 描述 为声明式自定义算子（ AnnotatedArgsOp / DeclareLaunchArgs）新增**编译期辅流申请与任务依赖声明**能力，使算子可以在 DeclareLaunchArgs 回调内把多个 kernel launch 下发到不同逻辑流，并由 GE 自动完成流分配与事件同步插入。 **对外接口（gert::AnnotatedArgsContext，@since 9.3.0(2026-09)）** - 新增 uint32_t RequestAttachedStream(const ge::AscendString &key)：按模型级 key 申请逻辑辅流，相同 key 复用同一 ID；key 为空或申请失败返回 UINT32_MAX。 - 新增 graphStatus AddLaunchWithDependencies(launch_info, args, dependencies, dependency_num, token)：以 AnnotatedLaunchToken 表达 launch 间前驱依赖，成功后输出本次 launch 的 token。 - AddLaunch 的 ABI 与行为保持不变（不产生 token，也不能作为依赖源）。 **graph_metadef 侧** - AnnotatedArgsHandler：LaunchRecord 增加 token 与依赖列表；新增 SetAttachedStreamRequestFunc / RequestAttachedStream / GetAttachedStreamIds；AddLaunchWithDependencies 校验 token 有效性（依赖必须指向更早 launch、不可重复、不可溢出）。 - stub_offline_launch_runtime.cc 同步补齐 stub 实现；stub_lowering 增加 runtime_headers、slog 链接。 **compiler 侧** - 新增 DeclarativeStreamRegistry：挂到 ComputeGraph ext attr（declarative_stream_registry），从当前逻辑流数之后按 key 去重分配辅流 ID，并做溢出保护。 - 新增 AnnotatedArgsTaskPlan 序列化/反序列化（带 version、长度与依赖边合法性校验）：缓存属性由进程内 ext attr 改为可序列化的 _custom_annotated_args_task_plan_bytes，使计划在 ReGetTaskInfo / 二次生成场景下可无回调恢复；计划中新增 launch_stream_ids、dependencies、attached_stream_ids。 - ModelBuilder：PrepareDeclarativeAttachedStreamRegistry（AssignLogicalStreams 之后建注册表）、FinalizeDeclarativeAttachedStreams（把计划辅流写回 op_desc->SetAttachedStreamIds 并扩展 stream_num）、MaterializeAnnotatedArgsTaskDependencies。 - StreamAllocator：InsertAnnotatedArgsEventTasks 为跨流依赖插入 EVENT_RECORD/EVENT_WAIT 任务；ReconcileAnnotatedArgsEventTasks 在拆流后重映射 event id、剪除同流事件对，并回写 stream/event/notify 总数（RTS 与 GE 两条拆流路径均覆盖）。 - CustomOpsKernelBuilder：物化时按计划流 ID 下发任务（无依赖且无辅流的 legacy 计划仍刷新为节点当前主流，兼容跨流复用）；CalcOpRunningParam 改为 DelAttr 清理序列化计划。 **约束校验** - 计划中至少存在一个主流 launch；辅流任务是否汇合回主流由算子自行保证。 - 依赖 token 必须指向更早的 launch，不可重复、不可自依赖。 - mobile OMC 单任务模式不支持依赖与辅流；端侧仍只允许一次 AddLaunch。 **文档**：新增 RequestAttachedStream.md、AddLaunchWithDependencies.md，更新 overview.md、README.md 目录、AddLaunch.md 与 DeclareLaunchArgs.md 约束描述。 ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [ ] 🐛 Bug 修复 - [x] ✨ 新功能 - [ ] 💄 代码风格更新（格式化，局部变量） - [ ] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [ ] 📦 构建过程或辅助工具的变动 - [ ] 📝 文档内容更新 ## 关联的Issue 无 ## 如何测试 描述测试此变更的步骤和前提条件： 1. 编译并运行 UT： - graph_metadef UT：AnnotatedArgsContextUT.AddLaunchWithDependenciesValidatesAndCopiesTokens - ge UT： - stream_allocator_unittest：DeclarativeStreamRegistryTest.*、AnnotatedArgsTaskPlanTest.*（序列化往返、跨流事件插入/重映射/同流剪枝）、ModelBuilderTest.FinalizeDeclarativeAttachedStreams* - custom_ops_kernel_info_store_unittest：计划无回调恢复、辅流不汇合主流、缺主流 launch 报错 - task_generator_unittest：GenerateTask_AnnotatedKernelRecordWait - custom_task_info_unittest：AnnotatedEventWaitUsesExistingWaitAndResetSemantics 2. 编译并运行 ST：graph_engine_test 中 DeclarativeCustomOpAttachedStreamSt.*（按 key 复用辅流 ID、回调缺失返回 UINT32_MAX）。 3. 手工验证：自定义算子在 DeclareLaunchArgs 中调用 RequestAttachedStream + AddLaunchWithDependencies 下发主流/辅流任务，出 OM 后确认 stream_num 扩展、辅流 launch 与 EVENT_RECORD/EVENT_WAIT 任务正确生成且执行结果正确。 ## 核对清单 <!-- [x] 表示选中 --> - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（如：feat:, fix:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 - PR 当前带 stat/needs-squash 标签，38 个 commit 中含多个 CI 规避/revert 提交，合入前需 squash。 - 标题 feat： 使用了全角冒号，建议改为半角 feat: 。 See merge request: cann/ge!4934 | 1 个月前 | |
feat: 自定义算子支持变长自定义数据(非内联方案) Co-authored-by: Chang-an-HW<machangan@huawei.com> # message auto-generated for no-merge-commit merge: !5273 merge feat/annotated-args-custom-data-noinline into develop feat: 自定义算子支持变长自定义数据(非内联方案) Created-by: Chang-an-HW Commit-by: Chang-an-HW Merged-by: cann-robot Description: # Pull Request SEG 20260629评审通过 ## 描述 为自定义算子的声明式 kernel launch 参数构建器 gert::AnnotatedKernelArgs 增加「变长只读字节数据」承载能力，解决自定义算子无法把 tiling 数据、常量查找表、描述符数组等**长度不固定**的数据传给 kernel 的问题。本 PR 共 16 个 commit，27 个文件，+1922/−41。 ### 背景与难点 改动前 gert::AnnotatedKernelArgs 仅支持四类**固定 8 字节**参数：逻辑输入地址、逻辑输出地址、逻辑 workspace 地址、uint64_t 标量，无法承载变长字节数据。 核心难点在于 GE 全链路硬编码了「**1 个 ge::ArgDesc = 1 个 8 字节槽**」这一不变式，分布在多处：builder 的 args.size() == arg_descs.size() * 8 校验、SetArgsOffset 的 offset = i * 8、materialize 阶段的 args[i * 8] 重填，以及被 9 类 task 共享的 ArgsIoAddrsUpdater 的 io_index * 8。若把数据字节内联进 args，上述不变式全部被击穿，且 args_offset 为 uint16，会带来 64 KB 的硬上限。 ### 方案：索引间接化（数据旁路存储） | 承载对象 | 存放位置 | | --- | --- | | 数据本体 | TaskDef.kernel.kernel_ext_info（复用 proto 既有字段 18，按 desc 顺序裸拼接） | | 数据长度 | args_format 的 pattern 中，形如 {custom_data<idx>.<size>bytes} | | args 槽位 | 恒占 1 个 8 字节槽，槽值为该数据的 device 地址 | 该形态与框架自身处理 FE tiling 的机制完全同构（MallocDynamicMemory + H2D 上传 + kAbsoluteMemType 参与刷新），因此 **5 处 8 字节不变式零破坏**，且 ArgsIoAddrsUpdater、ModelArgsManager、DavinciModel 三个共享组件**零修改**，**无 proto 变更**。 ### 主要改动 **公共 API（纯新增，向后兼容）** - 新增 gert::CustomData{const void *data; size_t size;}（@since 9.3.0(2026-10)） - 新增 AnnotatedKernelArgs::AppendArg(const CustomData &) - 新增 ge::AddrType::CUSTOM_DATA，追加在 MAX 之前，不改变任何既有枚举值 - blob 字节**不新增公开接口**：改由 friend class AnnotatedArgsContext 授权框架内部读取 impl_，避免在随包发布的 external 头上扩大永久兼容承诺；既有两参 ExtractArgsData 签名与行为不变 **格式层** - 新增 custom_data pattern 及**专用** CustomDataSerializer/CustomDataParser，把 size 编码进 pattern 并经 ArgDesc.reserved 往返（ArrayLikeSerializer 不携带 reserved，不可复用） - 单位后缀用 bytes 全称，避免与既有 .32b 的 bit 语义冲突 - pattern 仅注册主表 kPatternToHandler；ConvertArgDescNormal2Sk 入口显式拒绝，避免 sk 往返丢失 size 后静默降级 **编译层** - 新增 FillCustomDataExtInfo：按 CUSTOM_DATA desc 出现顺序把 blob 裸拼接写入 kernel_ext_info，成对设置 kernel_ext_info_size，并做三重交叉校验（Σ pattern 编码 size == kernel_ext_info.size() == kernel_ext_info_size） - materialize 路径新增 CUSTOM_DATA → continue，槽位保持编译期 0 占位 **运行期 v1** - 新增 LoadCustomDataBlobs：在**模型加载期**按 reserved 切分 kernel_ext_info，逐个 MallocDynamicMemory + aclrtMemcpy 上传，地址缓存于 custom_data_addrs_ - AssembleIoByArgsFormat 新增 CUSTOM_DATA 分支，以 kAbsoluteMemType 填址（参与刷新但值恒定） - **执行期零新增操作**：Distribute 未改动；blob 内存为 model 级生命周期，由 FreeDynamicWorkspaceMemory 统一回收 **不支持路径显式拒绝（编译期 fail-fast，不产出静默错误的产物）** - **mobile OMC**：CheckAnnotatedArgsTaskPlanForMode + GenerateMobileAnnotatedArgsTask 防御性检查（覆盖计划缓存命中路径）+ MobileModelHelper::SaveToOmModel 权威兜底 - **OM2 出图**：CustomTaskCodeBuilder::Contribute 显式检测 AddrType::CUSTOM_DATA 并报错（否则会静默生成含未初始化槽的 args） - **super kernel**：ConvertArgDescNormal2Sk 入口拒绝 **文档与测试** - 新增/更新 C++ API 文档：CustomData.md（新增）、AppendArg.md、AnnotatedKernelArgs/overview.md、API 导航 README.md - 新增 **36 个 UT 用例**，分布于 7 个 suite：AnnotatedArgsContextUT(4)、AnnotatedKernelArgsUT(6)、UtestArgsFormatDesc(7)、UtestCustomOpsKernelInfoStoreCustomData(5)、UtestCustomTaskInfoCustomData(10)、Om2CodegenModelBuilderUt(2)、UtestMobileModelHelper(2) ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [ ] 🐛 Bug 修复 - [x] ✨ 新功能 - [ ] 💄 代码风格更新（格式化，局部变量） - [ ] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [ ] 📦 构建过程或辅助工具的变动 - [x] 📝 文档内容更新 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在当前页面的右侧'关联Issue'部分添加相应Issue链接，并勾选'合并后关闭已关联的 Issue'选项。 --> 无关联 Issue。 ## 如何测试 ### 前提条件 1. 用本分支代码构建并安装两个子包： bash bash build.sh --ge_compiler --ge_executor -j24 ./build_out/cann-ge-compiler_*.run --install-path=<CANN_INSTALL> --full --quiet ./build_out/cann-ge-executor_*.run --install-path=<CANN_INSTALL> --full --quiet 2. source <CANN_INSTALL>/set_env.sh，准备可用 NPU（本机验证环境：Ascend 910B3 / CANN 9.3.0） ### UT bash bash tests/run_test.sh --ut 本机实测通过：ut_exe_graph 23/23、ut_libge_multiparts_utest 的 CustomData 用例 5/5、ut_libge_distinct_load_utest 的 CustomData 用例 10/10。 ### 端到端（NPU 上板） 配套样例作为独立 PR 提交（examples/custom_op/annotated_args_custom_data_addr），其 host 侧在一次 launch 中追加**两个** CustomData blob（变长查找表 + 定长 32B 标量参数），每个场景执行 3 轮，每轮重新申请输入/输出 device 内存以走到地址刷新路径： | 场景 | table_len | blob0 大小 | 验证点 | | --- | --- | --- | --- | | case1 | 6 | 32B | 基本功能 + 3 轮地址刷新 | | case2 | 13 | 64B | 变长：blob 长度变化而 args 布局不变 | | case3 | 5 | 28B（非对齐） | 非内联方案对 blob 长度无对齐约束 | 实测 **3/3 全部通过**，证据链： - OM 中 args_format = {i_instance0*}{i_instance1*}{custom_data0.32bytes}{custom_data1.32bytes}{o_instance0*}，5 个槽顺序与 host 侧追加顺序逐项一致 - OM 中 kernel_ext_info（proto field 18）长度 = blob0 + blob1，逐字节与 host 侧构造内容一致；kernel_ext_info_size（field 19）与之相等 - 加载期 GE 日志：MallocDynamicMemory ... size: 32 ×2，随后 LoadCustomDataBlobs: [CUSTOM OP] loaded 2 custom data blobs, total 64 bytes - 执行期零开销：3 轮执行中 blob 的 MallocDynamicMemory 仅 2 次、LoadCustomDataBlobs 仅 1 次，全部发生在加载期 - 变异实验：用错误的 table_len 校验同一份 OM 必然失败，且失败值精确对应 OM 内 blob 的真实内容（声称 5 时报 kernel 实际读到 600，即真实 len=6 的 table[5]），证明 kernel 确实消费了 blob 字节而非碰巧算对 ## 核对清单 <!-- [x] 表示选中 --> - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（如：feat:, fix:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 ### 兼容性 - **老 OM + 新版本 GE**：完全兼容。CUSTOM_DATA 追加在 MAX 之前，既有枚举值不变；新增代码分支均以「存在 CUSTOM_DATA desc」为前提 - **新 OM（未使用 CustomData）+ 老版本 GE**：与改动前逐字节一致（不使用时不写 kernel_ext_info） - **新 OM（使用 CustomData）+ 老版本 GE**：老版本解析 args_format 时明确报错（Args format [...] matched failed），加载终止，不会静默错跑 - **proto**：无变更，复用 KernelDef.kernel_ext_info = 18 / kernel_ext_info_size = 19 - **公共头 ABI**：sizeof(AnnotatedKernelArgs) 不变、AnnotatedArgsContext 的 static_assert 保持通过、既有四类 AppendArg 与两参 ExtractArgsData 行为不变 ### kernel 侧消费契约 args 中该槽位为裸 8 字节 device 地址，**数据长度不经 args 传递**（与框架既有 tiling 机制一致），kernel 侧获取长度有三种方式： 1. host/device 共享结构体 + sizeof（推荐，AscendC 既有 GET_TILING_DATA 等宏可直接使用） 2. 数据自描述（首字段写入条目数或总长度，kernel 先读头部再定位变长区） 3. 追加该描述符后再 AppendArg(uint64_t) 追加一个显式长度槽 框架**不会**自动追加长度槽，以保证 kernel 侧可沿用 AscendC 现成宏体系。 ### 已知边界 - 单条 blob 大小与单次 launch 累计字节数的代码级上限均为 UINT32_MAX（受 kernel_ext_info_size 为 uint32 约束）；实际可用量还受 HBM 容量与 protobuf 单消息上限限制 - 单次 launch 的槽位数上限为 8192（args_offset 为 uint16），该检查在编译期 SetArgsOffset 生效 - 上述两个上界中，单条 size 与累计 size 的检查未前移到 AppendArg，超限会在编译期 args_format 解析/FillCustomDataExtInfo 阶段报错（明确失败，无静默截断） ### 本轮范围之外 - **Python 侧接口未实现**：ge.custom_op 的 append_custom_data 绑定已在本分支回退，本 PR 只交付 C++ 接口 - **ST/NPU 上板用例未纳入本仓库**：端到端验证通过独立 PR 的样例完成 - 设计文档未随本 PR 提交（已从分支移除） ### 配套 PR 端到端样例作为独立 PR 提交（examples/custom_op/annotated_args_custom_data_addr），依赖本 PR 的特性代码，建议晚于本 PR 合入。 See merge request: cann/ge!5273 | 12 天前 | |
【PR】:更新产品文档 Co-authored-by: sophia1213<sophie.chen@huawei.com> # message auto-generated for no-merge-commit merge: !3851 merge develop into develop 【PR】:更新产品文档 Created-by: sophia1213 Commit-by: sophia1213 Merged-by: cann-robot Description: # Pull Request ## 描述 更新docs目录下的产品文档。 ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [ ] 🐛 Bug 修复 - [ ] ✨ 新功能 - [ ] 💄 代码风格更新（格式化，局部变量） - [ ] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [ ] 📦 构建过程或辅助工具的变动 - [x] 📝 文档内容更新 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在当前页面的右侧'关联Issue'部分添加相应Issue链接，并勾选'合并后关闭已关联的 Issue'选项。 --> ## 如何测试 根据最新资料进行测试 ## 核对清单 <!-- [x] 表示选中 --> - [ ] 我的代码遵循了项目的代码风格 - [ ] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [ ] 我在标题中使用了合适的类型标签（如： feat:, fix:） - [ ] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 在此添加任何其他关于本次 PR 的说明。 See merge request: cann/ge!3851 | 3 个月前 | |
【PR】:更新产品文档 Co-authored-by: sophia1213<sophie.chen@huawei.com> # message auto-generated for no-merge-commit merge: !3851 merge develop into develop 【PR】:更新产品文档 Created-by: sophia1213 Commit-by: sophia1213 Merged-by: cann-robot Description: # Pull Request ## 描述 更新docs目录下的产品文档。 ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [ ] 🐛 Bug 修复 - [ ] ✨ 新功能 - [ ] 💄 代码风格更新（格式化，局部变量） - [ ] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [ ] 📦 构建过程或辅助工具的变动 - [x] 📝 文档内容更新 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在当前页面的右侧'关联Issue'部分添加相应Issue链接，并勾选'合并后关闭已关联的 Issue'选项。 --> ## 如何测试 根据最新资料进行测试 ## 核对清单 <!-- [x] 表示选中 --> - [ ] 我的代码遵循了项目的代码风格 - [ ] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [ ] 我在标题中使用了合适的类型标签（如： feat:, fix:） - [ ] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 在此添加任何其他关于本次 PR 的说明。 See merge request: cann/ge!3851 | 3 个月前 | |
feat: Eager自定义算子RT2路径辅流申请功能 Co-authored-by: Chang-an-HW<machangan@huawei.com> # message auto-generated for no-merge-commit merge: !5139 merge eager-custom-op-attached-stream-RT2 into develop feat: Eager自定义算子RT2路径辅流申请功能 Created-by: Chang-an-HW Commit-by: Chang-an-HW Merged-by: cann-robot Description: # Pull Request ## 描述 2026829评审通过 为 Eager 自定义算子（ EagerExecuteOp）在 **RT2 动态图执行链路** 补齐按 key 申请框架托管物理辅流的能力。此前该能力只在 V1 静态图链路可用，RT2 下 EagerOpExecutionContext::RequestAttachedStream 因 EagerArgsHandler 未提供 provider 而恒返回 nullptr。 **公共 API 与 ABI 零改动，用户算子代码零改动**：RequestAttachedStream 签名、AdditionalInputIndex/AdditionalOutputIndex 布局、ArgsHandler::GetAttachedStreamProvider() 均不变，仅扩展 v2 内部枚举 CustomOpInput。 ### 核心链路 text LoweringCustomNode（Main 帧） └─ bg::GetAttachedStreamProvider → Init 图 CreateAttachedStreamProvider（每模型一份） └─ 作为 ExecuteCustomOp 附加输入 CustomOpInput::kAttachedStreamProvider ExecuteCustomOpImpl → 首轮 !IsInitialized() 时注入 EagerArgsHandler 用户 Execute(ctx) → RequestAttachedStream(key) → Rt2AttachedStreamCollection ### 关键设计 - **归属层级 per-ModelV2Executor**：容器由 Init 图节点的输出 Chain 持有。StreamExecutor 为每条 aclrtStream 各建一个执行器，故不同执行流即使用相同 key 也拿到不同辅流；换来天然隔离且**无需加锁**（ExecuteCustomOp 已注册 kKernelUseMemory，固定在唯一 memory worker 上串行执行）。 - **与 V1 的差异**：RT2 无 rtModel_t，不做 aclmdlRIBindStream；StreamActive 在 RT2 已退化为透传，不存在 V1 的 WAIT_ACTIVE 激活坑，按默认 flag 建流即可。 - **生命周期**：执行器析构时 Chain deleter 触发 Destroy()（先 aclrtSynchronizeStream 再 aclrtDestroyStream，幂等）。现有卸载路径（UnloadRt2Model → DeleteExecutor、StreamExecutor::Erase）都在 UnLoad() 后立即销毁执行器，故无需额外 DeInit 节点。 - **执行期开销**：RT2 下 Execute 每轮都会被调用（V1 只在下沉期一次），故 key 查找用透明比较容器（std::less<> + string_view），命中路径零堆分配，host 微基准约 25.3 ns/次。 - **不做数量限制**：单执行实例的辅流数量不设上限（与 V1 实现一致）；建流失败时打印 error 日志并返回 nullptr，由算子自行降级。 - **内存回收契约**：辅流不是框架逻辑流，RT2 多流 L2 回收不感知它，故算子必须在 Execute 返回前用 event 把辅流 join 回 ctx->GetStream()，已写入 API 文档约束说明。 ### 顺带修复的既存缺陷 RT2 内嵌 V1 静态子图场景下 Eager 算子申请的辅流**确定性泄漏**：DavinciModelFinalizer 未清理辅流，而 DestroyResources() 会置 has_finalized_ = true，导致 ~DavinciModel() 中含 UnbindAndDestroy() 的兜底清理块被整体跳过。修复：新增幂等的 DavinciModel::UnbindAndDestroyAttachedStreams()，由 Finalizer 在 DestroyStream() 之前调用。 ### 行为变化（需评审确认） 1. RT2 下 RequestAttachedStream 由恒 nullptr 变为可返回有效句柄——对以 nullptr 判定"链路不支持"的算子属行为变化。 2. 取消 CANN-FMK- 前缀的**硬拦截**（后续 HCCL 等框架组件也要通过本接口建流），改为 API 文档中的命名约定，key 校验统一为"仅判空"。属放宽型变化，原被拒绝的 key 现在会成功。 ### 对既有动态图流程的影响 - **不含 device 自定义算子的图：零影响**。bg::GetAttachedStreamProvider 全仓唯一调用点在 LoweringCustomNode，而它只注册给 kCustomOpKernelLibName + kOnDeviceHbm，这类图不会新增任何节点或输入。 - **含 device 自定义算子的图**：Init 图 +1 个 no-op 节点（每模型一份）、每个算子节点 +1 条输入边、Main 帧 +1 个 InnerData、每执行器 +1 个约 64B 容器对象；**每轮执行开销为 0**（provider 只在首轮读取一次）。 - Host CPU 自定义算子路径未触碰；OM/OM2 序列化不受影响（SerializeComputeNodeInfo 只遍历 IR 计算节点）；profiling/dump/trace 只按 IR 输入数遍历，不受附加输入影响。 ### 本 PR 不包含 Python 绑定（因 ST fallback 编译问题临时移除）、动态 shape 端到端样例、OM2 路径（其 context 由 codegen SO 内部构造且跨 OM2 C ABI）。 ## 变更类型 - [ ] 🐛 Bug 修复 - [x] ✨ 新功能 - [ ] 💄 代码风格更新（格式化，局部变量） - [ ] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [ ] 📦 构建过程或辅助工具的变动 - [x] 📝 文档内容更新 ## 关联的Issue 无 ## 如何测试 1. 以动态 shape 图验证：Execute 每轮都被调用（RT2 链路生效）、辅流句柄多轮恒定不变（跨轮次跨 shape 复用）、异 key 隔离、每轮精度全部通过。 ## 核对清单 - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（如：feat:, fix:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 无 See merge request: cann/ge!5139 | 1 个月前 | |
docs: 修正HostCpu常量折叠样例dump图验证说明 Co-authored-by: du-hua1024<duhua2@huawei.com> # message auto-generated for no-merge-commit merge: !4843 merge op-cpp into develop docs: 修正HostCpu常量折叠样例dump图验证说明 Created-by: du-hua1024 Commit-by: du-hua1024 Merged-by: cann-robot Description: # Pull Request ## 描述 修正 HostCpu 常量折叠样例 README 的 dump 图验证说明： - dump 图产物文件名由 ge_proto_*_AfterInfershape.pbtxt 修正为 ge_onnx_*_AfterInfershape.pbtxt，与 DumpGEGraphToOnnx 实际落盘命名一致 - 对齐 README_en.md 与中文版描述，删除多余的手动执行命令（run.sh 已包含可执行文件运行步骤） ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [ ] 🐛 Bug 修复 - [ ] ✨ 新功能 - [ ] 💄 代码风格更新（格式化，局部变量） - [ ] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [ ] 📦 构建过程或辅助工具的变动 - [x] 📝 文档内容更新 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在当前页面的右侧'关联Issue'部分添加相应Issue链接，并勾选'合并后关闭已关联的 Issue'选项。 --> ## 如何测试 描述测试此变更的步骤和前提条件： 1. 按 examples/custom_op/host_cpu_add_custom/constant_folding/README.md 执行 bash run.sh 完成构建 2. 设置 export DUMP_GE_GRAPH=2 后重新运行，确认 dump 产物为 ge_onnx_*_AfterInfershape.pbtxt，且图中不再包含 AddCustom 节点 ## 核对清单 <!-- [x] 表示选中 --> - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（如：feat:, fix:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 See merge request: cann/ge!4843 | 1 个月前 | |
【PR】:更新产品文档 Co-authored-by: sophia1213<sophie.chen@huawei.com> # message auto-generated for no-merge-commit merge: !3851 merge develop into develop 【PR】:更新产品文档 Created-by: sophia1213 Commit-by: sophia1213 Merged-by: cann-robot Description: # Pull Request ## 描述 更新docs目录下的产品文档。 ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [ ] 🐛 Bug 修复 - [ ] ✨ 新功能 - [ ] 💄 代码风格更新（格式化，局部变量） - [ ] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [ ] 📦 构建过程或辅助工具的变动 - [x] 📝 文档内容更新 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在当前页面的右侧'关联Issue'部分添加相应Issue链接，并勾选'合并后关闭已关联的 Issue'选项。 --> ## 如何测试 根据最新资料进行测试 ## 核对清单 <!-- [x] 表示选中 --> - [ ] 我的代码遵循了项目的代码风格 - [ ] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [ ] 我在标题中使用了合适的类型标签（如： feat:, fix:） - [ ] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 在此添加任何其他关于本次 PR 的说明。 See merge request: cann/ge!3851 | 3 个月前 | |
feat: 支持Eager自定义算子辅流资源编译期统计 Co-authored-by: Chang-an-HW<machangan@huawei.com> # message auto-generated for no-merge-commit merge: !5158 merge eager-custom-op-attached-stream-report into develop feat: 支持Eager自定义算子辅流资源编译期统计 Created-by: Chang-an-HW Commit-by: Chang-an-HW Merged-by: cann-robot Description: # Pull Request ## 描述 为 Eager 自定义算子新增辅流资源编译期统计能力： - 新增 ge::ResourceReportingOp 能力接口与 gert::ResourceUsageContext 上下文（继承 ExtendedKernelContext，零成员变量、standard_layout 断言）。算子编译期按节点申报运行期将通过 RequestAttachedStream 请求的辅流 key（ReportAttachedStreamKeys(const std::vector<ge::AscendString>&)，元素类型与运行期接口同型）。 - 框架在 ModelBuilder::BuildModelDefForStream 前遍历 device 侧自定义算子节点（跳过声明式 kAnnotatedArgs 节点防双计），按模型对 key 求 union 去重统计，写入模型属性 eager_custom_op_stream_num，随 OM/模型 cache 持久化（无上报算子不写属性，产物零变化）；根/子模型聚合求和不去重（各执行实例独立建流）。 - CompiledGraphSummary::SummaryData 新增私有成员，GetStreamNum() 返回"框架流数 + Eager 辅流统计"（唯一合并点，置于动态图 early-return 之前）；无上报算子的模型返回值逐一不变。 - 隔离不变量：统计不进入 ATTR_MODEL_STREAM_NUM、runtime_param.stream_num 与 V2 stream_resource，运行时 V1/V2 零改动，纯编译期旁路观测。 - 配套 API 参考文档：新增 ResourceReportingOp/ResourceUsageContext 两组共 8 篇，更新 GetStreamNum 行为说明与 README 索引（并补齐 EagerOpExecutionContext 遗漏的 RequestAttachedStream 索引行）。 ## 聚合与查询路径说明 针对"纯静态图的根模型 eager 属性聚合走哪条路径、summary 读到的是根模型还是子模型"（检视意见）的确认结论： - **在线/离线同一入口**：atc 离线（GeGenerator::GenerateModel → graph_manager_.BuildGraph，ge_generator.cc:1658-1662）与在线 Session 编译均走 GraphBuilder::Build（graph_builder.cc:302）。 - **纯静态图 = 单 GeModel**：Build 仅在 ATTR_NAME_DYNAMIC_SHAPE_PARTITIONED || GetGraphUnknownFlag() 时进入 BuildForDynamicShapeGraph（:323-324）；纯静态走 BuildForKnownShapeGraph，整图仅产生一个 GeModel（:330-335）。引擎分区在 known-shape 路径的产物是任务级的（各引擎 TaskDef 下沉同一 DavinciModel），不产生多个子模型，故不存在"静态多子图独立聚合点"。 - **唯一聚合点**：多 GeModel 仅来自动静拆分（BuildForUnknownShapeAllGraphs :717），聚合点唯一为 RefreshInfoOfDynamicShapeGraph（全仓唯一调用点 :620）；stream_num/event_num 的既有根模型聚合同在此处，eager 属性在同一循环内同型求和与溢出检查。 - **summary 读取同源**：GetCompiledGraphSummary 在 graph_manager.cc:5335 选取 ge_model 传入 Builder::Build，SetStreamNum 与 SetEagerCustomOpStreamNum 读取同一模型——静态图为 map 唯一 entry（即根模型），动态图为带聚合值的根模型；两属性任何路径下行为一致，无独立漏计面。 - **边界同构**：图展开场景（:619）跳过聚合（stream_num 亦然）；单算子编译单模型（single_op_model.cc:874）；ATC 动态离线空壳根模型（ge_generator.cc:668-672）两属性一同缺省 0。 ## 变更类型 - [x] ✨ 新功能 - [x] 📝 文档内容更新 ## 关联的Issue 无 ## 如何测试 1. 新增单元测试 14 个，全部通过： - ut_exe_graph --gtest_filter=ResourceUsageContextUT.*：key 上报/去重/空 key 粘滞错误/节点信息与 tensor 访问（5 个）； - ut_libge_multiparts_utest --gtest_filter=UtestModelBuilderTest.CollectEagerCustomOpStreamNum*：per-node 按 shape 分桶申报 union 精确、跨节点去重、声明式/未实现接口/非自定义节点跳过、无命中不写属性、失败传播（含算子吞错误码拦截）（4 个）； - ut_libge_multiparts_utest --gtest_filter=GraphBuilderTest.RefreshInfo*：聚合求和不去重、全缺省不写根属性、溢出失败（3 个）； - ut_libge_common_utest --gtest_filter=UtestGraphCompileSummaryImpl.*：合并点求和、属性缺省 0 与基线一致、隔离回归（新增 2 个）。 2. 回归测试：ut_exe_graph 全量 681 个、UtestModelBuilderTest/GraphBuilderTest/UtestCustomOpFactory 共 79 个全部通过；lowering/stub_lowering/ge_compiler 增量编译零告警。 3. pre-commit（clang-format/codespell/OAT 等 12 项）全部通过。 ## 核对清单 - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（如：feat:, fix:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 - 对外接口面：新增 1 个能力接口（ResourceReportingOp::DeclareResourceUsage）+ 1 个上报方法（ReportAttachedStreamKeys）；GetStreamNum 为行为变化（仅含上报算子的模型返回值增大），已在 API 文档声明，提请接口评审关注。 - std::vector<AscendString> 只读传引用参数与已发布的 AnnotatedKernelArgs::ExtractArgsData（9.2.0）跨界形态同类，无所有权/分配器跨界。 - 旧 OM 无新属性缺省按 0，旧算子 so 无需重编译，兼容性回归已覆盖。 See merge request: cann/ge!5158 | 1 个月前 | |
docs: 新增 annotated args API 文档 Co-authored-by: Chang-an-HW<machangan@huawei.com> # message auto-generated for no-merge-commit merge: !4046 merge annotated_args_op_doc into develop docs: 新增 annotated args API 文档 Created-by: Chang-an-HW Commit-by: Chang-an-HW Merged-by: cann-robot Description: # Pull Request ## 描述 本 PR 按方案 B 补齐端侧自定义算子入图和声明式地址刷新相关 API 文档，覆盖 AnnotatedArgsOp、AnnotatedArgsContext、AnnotatedKernelArgs 以及 InputAddr / OutputAddr / WorkspaceAddr 等接口入口，并更新 docs/zh/api/graph_engine_api/README.md 的导航。 ## 变更类型 请选择本次引入的变更类型： <!-- [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/ge!4046 | 3 个月前 | |
feat: 自定义算子支持变长自定义数据(非内联方案) Co-authored-by: Chang-an-HW<machangan@huawei.com> # message auto-generated for no-merge-commit merge: !5273 merge feat/annotated-args-custom-data-noinline into develop feat: 自定义算子支持变长自定义数据(非内联方案) Created-by: Chang-an-HW Commit-by: Chang-an-HW Merged-by: cann-robot Description: # Pull Request SEG 20260629评审通过 ## 描述 为自定义算子的声明式 kernel launch 参数构建器 gert::AnnotatedKernelArgs 增加「变长只读字节数据」承载能力，解决自定义算子无法把 tiling 数据、常量查找表、描述符数组等**长度不固定**的数据传给 kernel 的问题。本 PR 共 16 个 commit，27 个文件，+1922/−41。 ### 背景与难点 改动前 gert::AnnotatedKernelArgs 仅支持四类**固定 8 字节**参数：逻辑输入地址、逻辑输出地址、逻辑 workspace 地址、uint64_t 标量，无法承载变长字节数据。 核心难点在于 GE 全链路硬编码了「**1 个 ge::ArgDesc = 1 个 8 字节槽**」这一不变式，分布在多处：builder 的 args.size() == arg_descs.size() * 8 校验、SetArgsOffset 的 offset = i * 8、materialize 阶段的 args[i * 8] 重填，以及被 9 类 task 共享的 ArgsIoAddrsUpdater 的 io_index * 8。若把数据字节内联进 args，上述不变式全部被击穿，且 args_offset 为 uint16，会带来 64 KB 的硬上限。 ### 方案：索引间接化（数据旁路存储） | 承载对象 | 存放位置 | | --- | --- | | 数据本体 | TaskDef.kernel.kernel_ext_info（复用 proto 既有字段 18，按 desc 顺序裸拼接） | | 数据长度 | args_format 的 pattern 中，形如 {custom_data<idx>.<size>bytes} | | args 槽位 | 恒占 1 个 8 字节槽，槽值为该数据的 device 地址 | 该形态与框架自身处理 FE tiling 的机制完全同构（MallocDynamicMemory + H2D 上传 + kAbsoluteMemType 参与刷新），因此 **5 处 8 字节不变式零破坏**，且 ArgsIoAddrsUpdater、ModelArgsManager、DavinciModel 三个共享组件**零修改**，**无 proto 变更**。 ### 主要改动 **公共 API（纯新增，向后兼容）** - 新增 gert::CustomData{const void *data; size_t size;}（@since 9.3.0(2026-10)） - 新增 AnnotatedKernelArgs::AppendArg(const CustomData &) - 新增 ge::AddrType::CUSTOM_DATA，追加在 MAX 之前，不改变任何既有枚举值 - blob 字节**不新增公开接口**：改由 friend class AnnotatedArgsContext 授权框架内部读取 impl_，避免在随包发布的 external 头上扩大永久兼容承诺；既有两参 ExtractArgsData 签名与行为不变 **格式层** - 新增 custom_data pattern 及**专用** CustomDataSerializer/CustomDataParser，把 size 编码进 pattern 并经 ArgDesc.reserved 往返（ArrayLikeSerializer 不携带 reserved，不可复用） - 单位后缀用 bytes 全称，避免与既有 .32b 的 bit 语义冲突 - pattern 仅注册主表 kPatternToHandler；ConvertArgDescNormal2Sk 入口显式拒绝，避免 sk 往返丢失 size 后静默降级 **编译层** - 新增 FillCustomDataExtInfo：按 CUSTOM_DATA desc 出现顺序把 blob 裸拼接写入 kernel_ext_info，成对设置 kernel_ext_info_size，并做三重交叉校验（Σ pattern 编码 size == kernel_ext_info.size() == kernel_ext_info_size） - materialize 路径新增 CUSTOM_DATA → continue，槽位保持编译期 0 占位 **运行期 v1** - 新增 LoadCustomDataBlobs：在**模型加载期**按 reserved 切分 kernel_ext_info，逐个 MallocDynamicMemory + aclrtMemcpy 上传，地址缓存于 custom_data_addrs_ - AssembleIoByArgsFormat 新增 CUSTOM_DATA 分支，以 kAbsoluteMemType 填址（参与刷新但值恒定） - **执行期零新增操作**：Distribute 未改动；blob 内存为 model 级生命周期，由 FreeDynamicWorkspaceMemory 统一回收 **不支持路径显式拒绝（编译期 fail-fast，不产出静默错误的产物）** - **mobile OMC**：CheckAnnotatedArgsTaskPlanForMode + GenerateMobileAnnotatedArgsTask 防御性检查（覆盖计划缓存命中路径）+ MobileModelHelper::SaveToOmModel 权威兜底 - **OM2 出图**：CustomTaskCodeBuilder::Contribute 显式检测 AddrType::CUSTOM_DATA 并报错（否则会静默生成含未初始化槽的 args） - **super kernel**：ConvertArgDescNormal2Sk 入口拒绝 **文档与测试** - 新增/更新 C++ API 文档：CustomData.md（新增）、AppendArg.md、AnnotatedKernelArgs/overview.md、API 导航 README.md - 新增 **36 个 UT 用例**，分布于 7 个 suite：AnnotatedArgsContextUT(4)、AnnotatedKernelArgsUT(6)、UtestArgsFormatDesc(7)、UtestCustomOpsKernelInfoStoreCustomData(5)、UtestCustomTaskInfoCustomData(10)、Om2CodegenModelBuilderUt(2)、UtestMobileModelHelper(2) ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [ ] 🐛 Bug 修复 - [x] ✨ 新功能 - [ ] 💄 代码风格更新（格式化，局部变量） - [ ] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [ ] 📦 构建过程或辅助工具的变动 - [x] 📝 文档内容更新 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在当前页面的右侧'关联Issue'部分添加相应Issue链接，并勾选'合并后关闭已关联的 Issue'选项。 --> 无关联 Issue。 ## 如何测试 ### 前提条件 1. 用本分支代码构建并安装两个子包： bash bash build.sh --ge_compiler --ge_executor -j24 ./build_out/cann-ge-compiler_*.run --install-path=<CANN_INSTALL> --full --quiet ./build_out/cann-ge-executor_*.run --install-path=<CANN_INSTALL> --full --quiet 2. source <CANN_INSTALL>/set_env.sh，准备可用 NPU（本机验证环境：Ascend 910B3 / CANN 9.3.0） ### UT bash bash tests/run_test.sh --ut 本机实测通过：ut_exe_graph 23/23、ut_libge_multiparts_utest 的 CustomData 用例 5/5、ut_libge_distinct_load_utest 的 CustomData 用例 10/10。 ### 端到端（NPU 上板） 配套样例作为独立 PR 提交（examples/custom_op/annotated_args_custom_data_addr），其 host 侧在一次 launch 中追加**两个** CustomData blob（变长查找表 + 定长 32B 标量参数），每个场景执行 3 轮，每轮重新申请输入/输出 device 内存以走到地址刷新路径： | 场景 | table_len | blob0 大小 | 验证点 | | --- | --- | --- | --- | | case1 | 6 | 32B | 基本功能 + 3 轮地址刷新 | | case2 | 13 | 64B | 变长：blob 长度变化而 args 布局不变 | | case3 | 5 | 28B（非对齐） | 非内联方案对 blob 长度无对齐约束 | 实测 **3/3 全部通过**，证据链： - OM 中 args_format = {i_instance0*}{i_instance1*}{custom_data0.32bytes}{custom_data1.32bytes}{o_instance0*}，5 个槽顺序与 host 侧追加顺序逐项一致 - OM 中 kernel_ext_info（proto field 18）长度 = blob0 + blob1，逐字节与 host 侧构造内容一致；kernel_ext_info_size（field 19）与之相等 - 加载期 GE 日志：MallocDynamicMemory ... size: 32 ×2，随后 LoadCustomDataBlobs: [CUSTOM OP] loaded 2 custom data blobs, total 64 bytes - 执行期零开销：3 轮执行中 blob 的 MallocDynamicMemory 仅 2 次、LoadCustomDataBlobs 仅 1 次，全部发生在加载期 - 变异实验：用错误的 table_len 校验同一份 OM 必然失败，且失败值精确对应 OM 内 blob 的真实内容（声称 5 时报 kernel 实际读到 600，即真实 len=6 的 table[5]），证明 kernel 确实消费了 blob 字节而非碰巧算对 ## 核对清单 <!-- [x] 表示选中 --> - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（如：feat:, fix:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 ### 兼容性 - **老 OM + 新版本 GE**：完全兼容。CUSTOM_DATA 追加在 MAX 之前，既有枚举值不变；新增代码分支均以「存在 CUSTOM_DATA desc」为前提 - **新 OM（未使用 CustomData）+ 老版本 GE**：与改动前逐字节一致（不使用时不写 kernel_ext_info） - **新 OM（使用 CustomData）+ 老版本 GE**：老版本解析 args_format 时明确报错（Args format [...] matched failed），加载终止，不会静默错跑 - **proto**：无变更，复用 KernelDef.kernel_ext_info = 18 / kernel_ext_info_size = 19 - **公共头 ABI**：sizeof(AnnotatedKernelArgs) 不变、AnnotatedArgsContext 的 static_assert 保持通过、既有四类 AppendArg 与两参 ExtractArgsData 行为不变 ### kernel 侧消费契约 args 中该槽位为裸 8 字节 device 地址，**数据长度不经 args 传递**（与框架既有 tiling 机制一致），kernel 侧获取长度有三种方式： 1. host/device 共享结构体 + sizeof（推荐，AscendC 既有 GET_TILING_DATA 等宏可直接使用） 2. 数据自描述（首字段写入条目数或总长度，kernel 先读头部再定位变长区） 3. 追加该描述符后再 AppendArg(uint64_t) 追加一个显式长度槽 框架**不会**自动追加长度槽，以保证 kernel 侧可沿用 AscendC 现成宏体系。 ### 已知边界 - 单条 blob 大小与单次 launch 累计字节数的代码级上限均为 UINT32_MAX（受 kernel_ext_info_size 为 uint32 约束）；实际可用量还受 HBM 容量与 protobuf 单消息上限限制 - 单次 launch 的槽位数上限为 8192（args_offset 为 uint16），该检查在编译期 SetArgsOffset 生效 - 上述两个上界中，单条 size 与累计 size 的检查未前移到 AppendArg，超限会在编译期 args_format 解析/FillCustomDataExtInfo 阶段报错（明确失败，无静默截断） ### 本轮范围之外 - **Python 侧接口未实现**：ge.custom_op 的 append_custom_data 绑定已在本分支回退，本 PR 只交付 C++ 接口 - **ST/NPU 上板用例未纳入本仓库**：端到端验证通过独立 PR 的样例完成 - 设计文档未随本 PR 提交（已从分支移除） ### 配套 PR 端到端样例作为独立 PR 提交（examples/custom_op/annotated_args_custom_data_addr），依赖本 PR 的特性代码，建议晚于本 PR 合入。 See merge request: cann/ge!5273 | 12 天前 | |
docs: 新增 annotated args API 文档 Co-authored-by: Chang-an-HW<machangan@huawei.com> # message auto-generated for no-merge-commit merge: !4046 merge annotated_args_op_doc into develop docs: 新增 annotated args API 文档 Created-by: Chang-an-HW Commit-by: Chang-an-HW Merged-by: cann-robot Description: # Pull Request ## 描述 本 PR 按方案 B 补齐端侧自定义算子入图和声明式地址刷新相关 API 文档，覆盖 AnnotatedArgsOp、AnnotatedArgsContext、AnnotatedKernelArgs 以及 InputAddr / OutputAddr / WorkspaceAddr 等接口入口，并更新 docs/zh/api/graph_engine_api/README.md 的导航。 ## 变更类型 请选择本次引入的变更类型： <!-- [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/ge!4046 | 3 个月前 | |
【PR】:更新产品文档 Co-authored-by: sophia1213<sophie.chen@huawei.com> # message auto-generated for no-merge-commit merge: !3851 merge develop into develop 【PR】:更新产品文档 Created-by: sophia1213 Commit-by: sophia1213 Merged-by: cann-robot Description: # Pull Request ## 描述 更新docs目录下的产品文档。 ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [ ] 🐛 Bug 修复 - [ ] ✨ 新功能 - [ ] 💄 代码风格更新（格式化，局部变量） - [ ] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [ ] 📦 构建过程或辅助工具的变动 - [x] 📝 文档内容更新 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在当前页面的右侧'关联Issue'部分添加相应Issue链接，并勾选'合并后关闭已关联的 Issue'选项。 --> ## 如何测试 根据最新资料进行测试 ## 核对清单 <!-- [x] 表示选中 --> - [ ] 我的代码遵循了项目的代码风格 - [ ] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [ ] 我在标题中使用了合适的类型标签（如： feat:, fix:） - [ ] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 在此添加任何其他关于本次 PR 的说明。 See merge request: cann/ge!3851 | 3 个月前 | |
docs: 新增 annotated args API 文档 Co-authored-by: Chang-an-HW<machangan@huawei.com> # message auto-generated for no-merge-commit merge: !4046 merge annotated_args_op_doc into develop docs: 新增 annotated args API 文档 Created-by: Chang-an-HW Commit-by: Chang-an-HW Merged-by: cann-robot Description: # Pull Request ## 描述 本 PR 按方案 B 补齐端侧自定义算子入图和声明式地址刷新相关 API 文档，覆盖 AnnotatedArgsOp、AnnotatedArgsContext、AnnotatedKernelArgs 以及 InputAddr / OutputAddr / WorkspaceAddr 等接口入口，并更新 docs/zh/api/graph_engine_api/README.md 的导航。 ## 变更类型 请选择本次引入的变更类型： <!-- [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/ge!4046 | 3 个月前 | |
docs: 新增 annotated args API 文档 Co-authored-by: Chang-an-HW<machangan@huawei.com> # message auto-generated for no-merge-commit merge: !4046 merge annotated_args_op_doc into develop docs: 新增 annotated args API 文档 Created-by: Chang-an-HW Commit-by: Chang-an-HW Merged-by: cann-robot Description: # Pull Request ## 描述 本 PR 按方案 B 补齐端侧自定义算子入图和声明式地址刷新相关 API 文档，覆盖 AnnotatedArgsOp、AnnotatedArgsContext、AnnotatedKernelArgs 以及 InputAddr / OutputAddr / WorkspaceAddr 等接口入口，并更新 docs/zh/api/graph_engine_api/README.md 的导航。 ## 变更类型 请选择本次引入的变更类型： <!-- [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/ge!4046 | 3 个月前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 1 个月前 | ||
| 12 天前 | ||
| 3 个月前 | ||
| 3 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 3 个月前 | ||
| 1 个月前 | ||
| 3 个月前 | ||
| 12 天前 | ||
| 3 个月前 | ||
| 3 个月前 | ||
| 3 个月前 | ||
| 3 个月前 |