Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

English | 中文版

8. 下一步：路线图与展望

当前状态

ascend-rs 正处于积极开发阶段：

  • 宿主机 API: Alpha 阶段。ACL 操作、内存管理、内核启动、BLAS、DVPP、性能分析、HCCL 均已实现。
  • 构建工具: Alpha 阶段。支持 C++ 和 Rust 内核的编译，自动选择代码生成路径。
  • ascend_compile crate: 独立的内核编译库，提供 C ABI、CLI 和 Python 绑定。将 bisheng 调用与 rustc 解耦，使任何 C++ 内核生成器都能为昇腾 NPU 编译。
  • 设备运行时: 505 个 Rust NPU 内核（486 个编译测试 + 16 个可部署），实现 MultiKernelBench 全部 300 个参考内核的完整 1:1 覆盖（17 个类别），413 个测试在 Ascend 910B3 上通过 NPU 正确性验证（0 失败、0 崩溃），包含 37 个矩阵乘法通过 aclnn 算子组合执行，并提供 6 组内存安全案例研究展示相对于 AscendC C++ 的结构性安全优势。
  • 基准测试: Rust 向量内核在 softmax、激活函数、vec_add 和 matmul 上完全匹配手工优化 C++ 性能（零额外开销）。

短期目标

向量指令覆盖范围：向量指令 API 已覆盖全面的 f32 和 f16 操作集：

  • 算术运算: Add、Sub、Mul、Div、Min、Max ✓ 已实现
  • 归约操作: ReduceMax、ReduceMin、ReduceSum ✓ 已实现
  • 一元数学: Exp、Abs、Ln、Sqrt、Rsqrt、Reciprocal ✓ 已实现
  • 标量-向量: Adds、Muls、Maxs、Mins（f32 和 f16） ✓ 已实现
  • 激活函数: Relu、Sigmoid、Tanh、GELU, Softmax、ELU、Swish、Mish, SELU、Softplus、Softsign, HardSigmoid、HardSwish, Leaky ReLU、Log Softmax ✓ 已实现（16 种）
  • 组合算子: LayerNorm、RMSNorm、L1/L2 Norm, MSE/Huber/Hinge Loss、Cosine Similarity, SGD Update、Reduce Mean/Prod ✓ 已实现（17 个）
  • Cube 引擎: matmul_f16，通过 Mmad FFI（f16 输入 → f32 输出） ✓ 已实现
  • Cube 引擎转置: matmul_f16_transpose_b，使用硬件 L1→L0B 转置 ✓ 已实现
  • 分块与双缓冲: 基于队列（TQue）的流水线，实现 DMA 与计算的重叠执行
  • 类型安全的缓冲区句柄: #[repr(transparent)] 新类型封装（UbBuf、L1Buf、L0aBuf、L0bBuf、L0cBuf），在编译期防止混用不同存储层级的缓冲区 ✓ 已实现

端到端神经网络算子示例：

  • Conv2D ✓ — 通过 OpsBuilder/atc 预编译算子，宿主机端使用 Model+Dataset 执行，并与 CPU 参考实现验证
  • 多头注意力（MHA） ✓ — 宿主机编排的缩放点积注意力流水线：Q*K^T（HGEMM）→ 缩放（Rust 内核）→ 逐行 softmax（Rust 内核，使用 f16 归约/exp/muls 指令）→ weights*V（HGEMM）
  • BLAS API 改进 ✓ — acl_blas_gemm_ex 的 alpha/beta 参数从所有权转移改为借用（&DeviceBox<T>），支持在 MHA 等流水线中跨多次 GEMM 调用复用

设备端 Rust 语言支持：核心运算符和代码生成已完成：

  • 运算符: Add、Sub、Mul、Div、Rem、位运算（BitAnd、BitOr、Shl、Shr） ✓ 已实现
  • 代码生成: 有符号/浮点取模、浮点与整数互转 ✓ 已实现
  • 类型转换: Cast 代码生成，支持 f16↔f32 转换 ✓ 已实现
  • 迭代器组合子: map、filter、fold、zip、enumerate 等

中期目标：生态系统集成

ascend_compile 作为通用编译后端：独立的 ascend_compile crate 为任何生成 AscendC C++ 内核的工具提供统一的、经过验证的编译路径。它暴露四种接口：

接口消费者使用场景
Rust APIrustc_codegen_mlirascend-rs 自身的 MLIR→C++→二进制流水线
C ABI (libascend_compile.so)Python via ctypes直接替换 TileLang 的 libgen.py
CLI (ascend-compile)Shell 脚本、CI即席编译和验证
Python 封装 (ascend_compile.py)TileLang、Triton 后端直接 Python 集成

所有消费者都能享受的核心功能：

  • 编译前 3 项验证检查：入口点检查、DMA/同步屏障检查（310P 报错、910B 警告）、缓冲区大小与硬件限制对比
  • 双标志路径：310P/310B 使用 --cce-aicore-arch，910B 使用 --npu-arch -xasc（与 TileLang 兼容）
  • 同时支持目标文件和共享库输出：-c -o out.o 或 -fPIC --shared -o out.so

TileLang-Ascend 集成：TileLang 从 Python DSL 生成优化的 AscendC C++ 内核，但依赖裸露的 subprocess.run(bisheng, ...) 调用且无验证。将 LibraryGenerator.compile_lib() 替换为 ascend_compile.compile_kernel() 可提供：

  • 自动目标检测和正确的编译标志选择
  • 编译前验证，捕获常见的 NPU Bug（缺少同步屏障、缓冲区溢出）
  • 跨工具的一致编译——使用与 ascend-rs 自身经过验证的内核完全相同的编译标志

PyPTO 集成: PyPTO（并行 Tile 操作）是 CANN 的高层算子编程框架，将 Python 级别的张量操作通过约 90 条 PTO 虚拟指令集编译为 AscendC C++ 代码。当 PyPTO 随 CANN 框架一同发布后，ascend_compile 可作为其编译后端，而 ascend-rs 对 PyPTO 的接口将支持对 tile 级算子进行内存安全的静态分析——在编译期捕获缓冲区溢出、缺失的同步屏障和错误的 DMA 参数，这些目前 PyPTO 仅在代码生成阶段验证。

Triton-Ascend 后端：Triton 的编译流水线生成需要降级为设备二进制的目标特定 IR。昇腾的 Triton 后端可以使用 ascend_compile 处理最终的 AscendC C++ → NPU 二进制步骤，享受相同的验证和目标抽象。

PyTorch 集成路径：带有昇腾后端的 torch.compile 可以通过 C ABI 调用 ascend_compile 来编译生成的内核，无需 Python→Rust 依赖，使用与 TileLang 相同的 libascend_compile.so。

完善宿主机 API：所有主要的 CANN API 模块现已拥有安全的 Rust 封装：

  • 张量描述符 ✓ — TensorDesc、DataBuffer、Dataset（28 个方法）
  • 模型推理 ✓ — Model::from_file()、execute()、execute_async()、ModelDescription（16 个方法）
  • 事件管理 ✓ — AclEvent，支持 record/sync/timing（8 个方法）
  • DVPP 图像预处理 ✓ — DvppChannel、PicDesc，支持 resize/crop/JPEG/PNG（42 个方法）
  • 性能分析 API ✓ — ProfSession、ProfConfig、StepInfo、ProfStamp（18 个方法）
  • HCCL 分布式通信 ✓ — AllReduce、AllGather、Broadcast、ReduceScatter、Send/Recv（17 个方法）

MLIR 代码生成后端完善：

  • Rust 内建函数 ✓ — 位操作（ctlz/cttz/ctpop/bswap/bitreverse/rotate）、浮点数学（floor/ceil/round/trunc/copysign/fma）、溢出算术、饱和算术
  • 浮点常量支持 ✓ — 正确的 MLIR 属性格式化（包含小数点）
  • C++ 代码生成内建函数翻译 ✓ — 所有 LLVM 内建函数已映射到 GCC 内建函数和 C 数学函数
  • 正确性修复 ✓ — raw_eq（字节比较）、discriminant_value（枚举匹配）、const_uint_big（i128）、static_addr_of（全局符号）、codegen_static（初始化值）
  • 调试信息生成（尚未开始）

长期愿景

昇腾目标规格 — davinci-huawei-none：我们已准备好一份面向 Rust 编译器的 Tier-3 目标提案。目标三元组 davinci-huawei-none 遵循已有约定（nvptx64-nvidia-cuda、amdgcn-amd-amdhsa），为 DaVinci NPU 架构定义了 ABI、调用约定和指针大小。目标规格（upstream-tier3/compiler/rustc_target/src/spec/targets/davinci_huawei_none.rs）使用 aarch64-unknown-none 作为 LLVM 占位符（因为不存在 DaVinci LLVM 后端），并注册 cfg(target_arch = "davinci") 用于条件编译。upstream-tier3/ 目录包含完整的提交包：目标规格、平台支持文档、mod.rs/platform-support.md/bootstrap/sanity.rs 的补丁，以及社区参与材料（Zulip 帖子、可选 MCP 草案、PR 描述）。我们的参与计划：(1) 在 Zulip #t-compiler/help 上发帖获取早期反馈，(2) 如果新颖的 MLIR 代码生成后端需要编译器团队共识则提交 MCP，(3) 向 rust-lang/rust 提交草稿 PR。Tier-3 目标门槛最低——无需 RFC、无需 CI、单个审阅者批准即可——且我们的树内更改不包含任何专有代码。

减少 no_core 负担：维护一个平行的 core 库重实现是巨大的工程负担。长期方向是探索使用 -Zbuild-std=core 与 MLIR 后端配合，直接编译 Rust 标准库源码，而不是手动重实现。

统一的昇腾编译栈：ascend_compile crate 是迈向统一编译基础设施的第一步，多个前端（Rust、Python DSL、编译器 IR）共享同一个经过验证的、目标感知的后端。这类似于 LLVM 模型——多个前端，一个后端——但专为昇腾 NPU 硬件而优化：

graph TD
    A1["Rust 内核"] --> F["AscendC C++ · 通用中间表示"]
    A2["TileLang（规划中）"] -.-> F
    A3["Triton（规划中）"] -.-> F
    A4["torch.compile（规划中）"] -.-> F
    A5["PyPTO（规划中）"] -.-> F
    A6["未来的 DSL（规划中）"] -.-> F
    F --> G["ascend_compile: 验证 → 目标标志 → bisheng → 二进制"]
    G --> H["NPU 二进制 · .o / .so"]

社区参与

ascend-rs 目前存放在内部私有仓库中，正在等待开源决定。一旦发布，将欢迎社区参与。如果你拥有昇腾 NPU 硬件并有兴趣探索内存安全的内核编程，以下是未来可以贡献的方向：

  1. 为 ascend_std 添加新的向量指令：遵循已有的 extern "C" 桩 + mlir_to_cpp 处理器模式。
  2. 编写更多的 compiletest 测试：每当 ascend_std 增加新功能，相应的编译测试也需要添加。
  3. 完善宿主机 API 封装：CANN SDK 有大量尚未封装的 API，每个都可以独立贡献。
  4. 尝试编写更复杂的 Rust 内核：帮助发现代码生成后端的不足之处，在 NPU 硬件上验证新指令。
  5. 将 ascend_compile 集成到你的工具中：如果你在开发 TileLang、Triton 或其他面向昇腾的内核编译器，尝试用 ascend_compile 替换你的编译步骤并反馈问题。