[Feature] Migrate AICPU launch to new rtsLaunchCpuKernel interface (BUILD_WITH_NEW_CANN)

[hw-native-sys-bot]

Summary

Migrate the AICPU kernel launch path to use the new rtsLaunchCpuKernel / rtsBinaryLoadFromFile / rtsFuncGetByName API, with a two-layer dispatcher SO architecture that allows different runtimes to load different AICPU kernel SOs at runtime.

Motivation / Use Case

Current state (simpler):

Both a2a3 and a5 platform backends launch AICPU kernels through CANN's built-in libaicpu_extend_kernels.so:

rtAicpuKernelLaunchExWithArgs(
    rtKernelType_t::KERNEL_TYPE_AICPU_KFC, "AST_DYN_AICPU",
    aicpu_num, &rt_args, nullptr, stream, 0);

Problems:

• The SO name (libaicpu_extend_kernels.so) is hardcoded — only one fixed SO can be loaded
• Different runtimes cannot load different AICPU kernel implementations at runtime
• Manual offsetof-based struct packing for kernel/SO name strings
• Legacy API may be deprecated in future CANN versions

Target architecture:

Two-layer SO dispatch (matching pypto's pypto_aicpu_interface pattern) + new CANN launch API:

1. Dispatcher SO (outer, fixed) — runs on AICPU, exports:

   • DynTileFwkDispatcherLoad — receives inner SO binary, saves to AICPU filesystem, dlopen + dlsym
   • DynTileFwkDispatcherInit — delegates to inner SO's init
   • DynTileFwkDispatcherRun — delegates to inner SO's run

2. Runtime SO (inner, replaceable) — different runtimes load different SOs with different names

3. Host-side LoadAicpuOp — generates JSON descriptor → rtsBinaryLoadFromFile → rtsFuncGetByName → rtsLaunchCpuKernel

Current Progress

Done:

• Dispatcher SO implemented (src/common/aicpu_dispatcher/)
• Host-side LoadAicpuOp wrapper implemented (src/common/host/)
• Build system updated (dispatcher target, RuntimeBinaries, parallel build)
• DeviceRunner integration (DispatcherLoad → Init → Run three-step launch)

Blocker:

• rtsBinaryLoadFromFile returns ACL_ERROR_RT_PARAM_INVALID (107000) on CANN 8.5.0 for any input (including CANN's own built-in aicpu_kernel.json). Need to investigate root cause — likely a missing initialization step, environment config, or CANN version requirement.

Scope

File	Change
src/common/aicpu_dispatcher/aicpu_dispatcher.{h,cpp,CMakeLists.txt}	New: dispatcher SO
src/common/host/load_aicpu_op.{h,cpp}	New: host-side new API wrapper
src/a2a3/platform/onboard/host/device_runner.{h,cpp}	Replace launch_aicpu_kernel with new API path
src/a5/platform/onboard/host/device_runner.{h,cpp}	Same
src/{a2a3,a5}/platform/onboard/host/pto_runtime_c_api.cpp	Set dispatcher SO path
src/{a2a3,a5}/platform/onboard/host/CMakeLists.txt	Add load_aicpu_op source + rts include path
python/simpler/runtime_compiler.py	Add dispatcher build target
simpler_setup/runtime_builder.py	Build dispatcher in parallel, dispatcher_path in RuntimeBinaries
examples/scripts/runtime_builder.py	Same

Reference

• pypto dispatcher: framework/src/machine/device/machine_interface/pypto_aicpu_interface.{h,cpp}
• pypto host-side: framework/src/machine/runtime/load_aicpu_op.{h,cpp}

[puddingfjz]

AI分析的当前问题：

当前问题总结

目标：将 AICPU launch 从旧 API (rtAicpuKernelLaunchExWithArgs) 迁移到新 API (rtsBinaryLoadFromFile / rtsFuncGetByName / rtsLaunchCpuKernel)，使用 cpuKernelMode=1。

现状：

• Host 端加载成功 — JSON 放在 SO 同目录、同 basename（libaicpu_dispatcher.json / libaicpu_dispatcher.so），rtsBinaryLoadFromFile 返回成功，三个 function handle（Null/Init/Run）全部解析成功。
• rtsLaunchCpuKernel 调用返回成功（host 侧不报错）。
• rtStreamSynchronize 返回 507018 — 说明 AICPU scheduler 端执行内核时失败了。

已排除的尝试：

尝试 | 结果 -- | -- kernelSo 用绝对路径 | scheduler 的 CreateSingleSoMgr 显式拒绝 kernelSo 用相对路径（当前方案） | scheduler 没有报 SO 找不到，但 CallKernelApi 失败（symbol not found） 去掉 static linking（4127→76 symbols） | 无效 加 -Wl,-Bsymbolic,--build-id | 无效 strip debug info | 无效 设置 ASCEND_CUSTOM_OPP_PATH | scheduler 未继承该环境变量

核心困难：

1. Scheduler 是 CANN 闭源组件，无法直接 debug 其内部逻辑
2. Scheduler 进程未作为独立进程运行（可能嵌入在 driver/runtime 中），strace 方案无法挂载
3. 用 cpuKernelMode=2（内存加载）可以绕过 SO 路径问题，但你明确要求搞清楚 cpuKernelMode=1 为什么失败

下一步方向：需要在 scheduler 内部 trace 它加载 SO 和查找 symbol 的过程，确定它到底加载了什么、找不到哪个 symbol。

[puddingfjz]

Scheduler 的 SO 加载代码是 CANN 闭源的，我们无法直接查看源码。但从 device log 中的调用栈和错误信息可以推断出流程：

ae_kernel_lib_aicpu.cc:177 — CallKernelApi 函数：用 dlsym 从已加载的 SO 中查找 functionName 指定的符号
aicpusd_event_process.cpp:906 — PostProcessTsKernelTask：处理 kernel 任务结果
从之前观察到行为推断 scheduler 的加载流程：

host 调用 rtsBinaryLoadFromFile(JSON, cpuKernelMode=1)
→ host runtime 解析 JSON，发送给 scheduler
→ scheduler 用 kernelSo 字段找到 SO 文件并 dlopen
→ scheduler 用 functionName 字段 dlsym 查找符号
→ scheduler 调用找到的函数执行 kernel

现在的关键问题是：符号 DynTileFwkKernelServerNull 确实存在于我们的 SO 中，但 scheduler 的 dlsym 却找不到。可能的原因：

1. scheduler 加载了错误的 SO（同名文件在其他路径）
2. scheduler 加载 SO 时使用了 RTLD_LOCAL，导致符号不可见
3. scheduler 的 dlsym 使用的 SO handle 不对（加载了 SO 但 handle 指向了其他对象）

[puddingfjz]

我们是怎么调用scheduler侧的代码加载SO的

调用链是：

device_runner.cpp:740 — load_aicpu_op_.LaunchBuiltInOp(stream, k_args, aicpu_num, func_name, kernel_name)
load_aicpu_op.cpp:188-199 — LaunchBuiltInOp 从 func_handles_ 查找 handle，调用 AicpuKernelLaunch
load_aicpu_op.cpp:166-186 — AicpuKernelLaunch 调用 rtsLaunchCpuKernel(func_handle, aicpu_num, stream, &kernelLaunchCfg, &cpu_args)
rtsLaunchCpuKernel 是 CANN runtime 的 API，host 侧调用后，runtime 内部会把任务发给 scheduler daemon，scheduler 再去加载 SO、查找符号、执行函数。我们无法控制 scheduler 内部的 dlopen/dlsym 行为。

[puddingfjz]

传递json地址的代码在哪里

[load_aicpu_op.cpp:99-141](vscode-webview://03v380etl3ljhuk25aejn14fb38a6gdfik1vm0gqg1cm2ol4lpdv/src/common/host/load_aicpu_op.cpp#L99-L141) — Init() 方法中：

json_file_path_ = so_dir + json_name;  // 第121行：构造JSON路径

// 第124行：生成JSON文件
if (!GenerateAicpuOpJson(json_file_path_, so_basename)) { ... }

// 第141行：把JSON路径传给rtsBinaryLoadFromFile
rtError_t rc = rtsBinaryLoadFromFile(json_file_path_.c_str(), &load_config, &binary_handle_);

JSON 路径是通过 rtsBinaryLoadFromFile 传给 CANN runtime 的，runtime 再转发给 scheduler。scheduler 拿到 JSON 路径后，根据 JSON 里的 kernelSo 字段去加载 SO。