English | 中文版
12. 相关工作:Rust on GPU/NPU,以及与 NVIDIA 工具链的整合可能
摘要:ascend-rs 并不是第一个把 Rust 带到异构计算上的项目,也远不是唯一把“内存安全“作为 headline 的。本章把 ascend-rs 放在当前活跃的 Rust-on-accelerator 项目矩阵里对比:
rust-cuda、rust-gpu、krnl、cudarc、wgpu,以及最近宣布的OxiCUDA,然后探索 NVIDIA 一侧具体的整合路径。mlir_to_gpu后端在我们的 tree 里已经存在,它从驱动 Ascend 路径的同一份ascend_tile_*MLIR 出发生成 CUDA C——所以问题已经不是“ascend-rs 能不能在 NVIDIA GPU 上跑一个 Rust 内核“,而是“如果把内核、host runtime、以及安全卫士缝起来,相比各自重新实现一遍,整个生态能得到什么“。本章识别出四个整合机会;其中一个——把第 11 章的安全卫士跑在 OxiCUDA 这类 runtime-PTX 项目生成的 PTX 上——是一个真正新颖的联合贡献,因为今天没有任何 Rust-GPU 项目在它生成的低层 IR 上带一个编译期安全分析。
12.1 / 12.2 / 12.3 / 12.4 / 12.5 详见英文版
本章的完整内容目前只维护了英文版:
- 12.1 The Landscape of Rust on Accelerators
- 12.2 Axis-by-Axis Comparison with OxiCUDA
- 12.3 Integration Opportunities on the NVIDIA Side
- 12.4 What ascend-rs Would Ship Back to the Rust-GPU Ecosystem
- 12.5 What This Chapter Is Not
简要概括:英文版把 ascend-rs 和 rust-cuda / rust-gpu / krnl / cudarc / wgpu / OxiCUDA 放在七列矩阵里对比(目标硬件、作者层、替换了什么、运行时模型、Rust 之外的安全保证、成熟度);然后用五个小节专门对比 OxiCUDA,结论是 OxiCUDA = “删掉 CUDA SDK,运行时从 Rust 发射 PTX,覆盖 NVIDIA library surface”,而 ascend-rs = “用安全 Rust 写 NPU 内核,经 MLIR 穿过厂商工具链,证明厂商工具链自己证不了的安全属性”,两者互补而非竞争。最后一节列出 NVIDIA 侧的四个整合机会:(12.3.1) mlir_to_gpu + cudarc host runtime 的短期拼装;(12.3.2) 用 runtime-PTX 发射(自行接入 LLVM 的 NVPTX,或与 OxiCUDA 合作)替代 nvcc 依赖;(12.3.3) 把第 11 章的 oracle 跑在 PTX 上——这是真正新颖的联合贡献,因为六个 check pass 在设计上并非 Ascend-specific,只需要写一个 parse_ptx_stage2 就能复用;(12.3.4) 长期共享一份 tile IR,我们有 15 个 vendor 后端已经在这份 IR 上下沉。