> 本文面向第一次接触海光 DCU 的开发者，用「从写代码到跑起来」的视角，梳理 DTK（DCU Toolkit）的组成、能力边界和上手路径。 --- ## 一、先建立直觉：DTK 是什么？ 如果把 DCU 比作一块「专用算力引擎」，那 **DTK 就是围绕这块引擎搭建的一整套开发底座**。 它不是一个单一程序，而是一组彼此配合的组件： - **编程接口**：让你用熟悉的语言/范式写异构程序 - **数学与 AI 算子库**：避免重复造轮子 - **编译与调试工具**：把源码变成可执行文件，并帮你定位问题 - **运行时与通信模块**：让程序在 DCU 上真正跑起来、跑得快 DTK 的定位是 **轻量、模块化**：你可以按需选用其中的能力，既可以开发传统 HPC 应用，也可以支撑深度学习推理/训练场景。  *图 1：DTK 在整体系统中的位置（自下而上：硬件 → 系统 → 运行时 → 库 → 编程接口 → 工具 → 应用）* 从上图可以看出：**应用并不直接「摸」硬件**，而是通过 DTK 提供的接口和运行时，完成编译、调度、通信与执行。这也是大多数异构计算平台的通用模式，DTK 在此基础上针对海光 DCU 做了适配与优化。 --- ## 二、DTK 跑在哪些系统上？ DTK 对操作系统有较广的覆盖： | 类型 | 常见发行版 | |------|-----------| | 国际主流 Linux | CentOS、Ubuntu 等 | | 国产操作系统 | 麒麟、统信、方德等 | 这意味着同一套 DTK 工作流，可以在不同部署环境中复用——对需要在「国产化 + 算力集群」双线落地的团队尤其重要。 --- ## 三、四种主流编程路径：怎么选？ DTK 并不强制你只学一种写法。实际项目里，常见四条路线如下。 ### 3.1 HIP —— 当前最主流的 DCU 开发方式 **HIP**（Heterogeneous-Compute Interface for Portability）最初由 AMD 提出，设计目标是： > 用接近 CUDA 的思维写 C++ 异构代码，同时保持跨平台可移植性。 在 DTK 中，HIP 被扩展为可直接面向 DCU 编译执行。如果你： - 有 CUDA 背景，或 - 希望精细控制 kernel、内存与执行流， 那么 HIP 通常是首选。 **典型特征：** - C++ 接口 + kernel 语言 - 生态成熟，资料与案例相对丰富 - 适合性能敏感、需要底层控制的场景 --- ### 3.2 OpenMP —— 低侵入并行改造 **OpenMP** 通过编译器导语（`#pragma`）把串行代码并行化，对原有代码改动小。 关键点： - 传统上擅长多核 CPU 并行 - 从 OpenMP 4.0 起引入异构设备（GPU/加速器）支持 - DTK 当前支持 **OpenMP 4.5 全量**，以及 **5.0 / 5.1 / 5.2 的部分特性** 适合场景： - 已有 C/C++/Fortran 代码，希望逐步 offload 到 DCU - 团队更熟悉「导语式并行」而非手写 kernel --- ### 3.3 OpenACC —— 面向加速器的导语模型 **OpenACC** 可以看作另一条「导语驱动 + 异构 offload」路线，语法与 OpenMP 不同，但在目标上类似：把计算任务交给加速器。 现状： - 与 OpenMP 的异构能力存在演进与融合趋势 - 仍被不少 HPC 代码用于 GPU/加速器移植 - DTK 对 OpenACC 提供 **部分 C/C++ 能力支持** 如果你维护的是 legacy OpenACC 工程，可以评估迁移成本；新项目一般会优先比较 HIP 与 OpenMP。 --- ### 3.4 OpenCL —— 兼容保留，非重点方向 DTK 仍可编译运行 OpenCL 程序，但 **并非当前主推路线**。除非有历史资产或特定依赖，否则不建议作为新项目主技术栈。 --- ### 3.5 Fortran 开发者怎么办？ DTK **不支持直接编写 Fortran 版 DCU kernel**，但有两条现实路径： 1. **Fortran ↔ C 互操作** 借助 `ISO_C_BINDING` 调用 HIP 接口或已写好的 HIP kernel（工程上很常见）。 2. **OpenMP 导语** 文档示例虽多以 C/C++ 展示，但不少能力在 Fortran 侧同样可用。 --- ### 3.6 路径选择速查 | 你的背景 / 目标 | 更推荐 | |----------------|--------| | CUDA 迁移、手写 kernel | HIP | | 老代码并行化、CPU+DCU 混合 | OpenMP | | 存量 OpenACC 项目 | OpenACC（评估后） | | 跨厂商 OpenCL 资产 | OpenCL（维护型） | | Fortran 科学计算 | Fortran + C/HIP 或 OpenMP | --- ## 四、库生态：从「能跑」到「跑得快」 DTK 内置了大量面向 DCU 优化的库。它们很多源于 HIP 生态（原本用于 AMD GPU 与 NVIDIA GPU 的可移植实现），并在 DTK 中进一步适配海光 DCU。 下面按「开发者视角」重新归类（不是简单的 CUDA 对照表）： ### 4.1 线性与稀疏计算 | DTK 库 | 典型用途 | |--------|---------| | hipBLAS | 稠密线性代数（BLAS） | | hipBLASLt | 轻量 GEMM 加速 | | hipSOLVER | 矩阵分解与求解 | | hipSPARSE | 稀疏矩阵运算 | ### 4.2 信号与随机 | DTK 库 | 典型用途 | |--------|---------| | hipFFT | 快速傅里叶变换 | | hipRAND | 随机数生成 | ### 4.3 深度学习算子 | DTK 库 | 典型用途 | |--------|---------| | MIOpen / hipDNN | 卷积、池化等 DNN 基础算子 | | hipDNN | 深度网络加速组件 | ### 4.4 并行算法与通信 | DTK 库 | 典型用途 | |--------|---------| | Thrust / hipCUB | 并行算法原语（排序、归约等） | | RCCL | 多卡 / 多节点通信（可类比 NCCL 思路） | ### 4.5 运行时编译 | DTK 库 | 典型用途 | |--------|---------| | HIP RTC | 运行期编译 kernel，提升动态场景灵活性 | **实践建议：** 性能调优时，优先确认「是否已有成熟库可替换手写 kernel」。在 DCU 上，库函数往往包含针对硬件微架构的优化，通常比「先写出来再优化」更省时。 --- ## 五、工具链：开发、编译、诊断一条龙 DTK 的工具链围绕 LLVM 编译器套件构建，HIP / OpenMP / OpenACC 的支持都由此承载。 ### 5.1 编译入口：hipcc `hipcc` 是 HIP 项目的编译包装脚本，帮你处理： - 预处理器参数 - 编译器调用 - 链接器配置 开发者通常只需一条简洁命令，即可完成从源码到可执行文件的构建。 ### 5.2 性能分析：hipprof `hipprof` 用于采集运行时指标，支持： - 统计型性能数据 - 时间线可视化 适合回答两个问题： 1. 时间花在哪个 kernel / 哪个阶段？ 2. 优化后有没有真实收益？ ### 5.3 调试：hipgdb 基于 GDB 扩展，支持断点、单步、变量查看等常见调试动作，降低 DCU 程序「只能 printf 调试」的痛苦。 ### 5.4 设备监控：rocm-smi 用于查看节点上 DCU 的实时状态，例如： - 设备数量与编号 - 温度、功耗 - 显存占用、算力利用率 示例输出（4 卡节点）： ```text DCU Temp AvgPwr Fan Perf PwrCap VRAM% DCU% 0 49.0c 58.0W 0.0% manual 450.0W 0% 0% 1 49.0c 59.0W 0.0% manual 450.0W 0% 0% 2 50.0c 57.0W 0.0% manual 450.0W 0% 0% 3 49.0c 58.0W 0.0% manual 450.0W 0% 0% ``` 字段含义（从左到右）： - 设备 ID - 温度 - 平均功率 - 风扇转速（液冷节点常为 0%） - 性能策略 - 功耗上限 - 显存使用率 - 计算单元使用率 程序运行期间可结合 `hy-smi` 观察资源是否「吃满」，避免「程序能跑但硬件在摸鱼」。 --- ## 六、安装、加载与版本策略 ### 6.1 获取渠道 DTK 安装包可从 **光合开发者社区** 下载： - 入口： - 路径：资源中心 → DCU Toolkit → 选择版本与操作系统 包名通常类似： ```text DTK-<版本号>-<操作系统>-x86_64.tar.gz ``` ### 6.2 目录结构（解压后） ```text ├── amdgcn -> dcc/dccgcn ├── bin ├── cuda ├── dcc ├── dushmem ├── env.csh ├── env.sh ├── hip ├── hipblas / hipblaslt / hipcub / hipdnn ├── hipfft / hipprof_utils / hiprand ├── hipsolver / hipsparse ├── hsa / include / lib / lib64 ├── llvm -> dcc ├── miopen / modulefile / opencl / rccl ├── rocalution / rocblas / rocfft / rocprim ├── rocprofiler / rocrand / rocsolver / rocsparse ├── rocthrust / roctracer ├── share / src ``` ### 6.3 环境加载 **本机/解压目录：** ```bash # bash source /path/to/dtk/env.sh # csh source /path/to/dtk/env.csh ``` **集群（Environment Modules）：** ```bash module unload compiler/dtk/<旧版本> # 如有冲突先卸载 module load compiler/dtk/26.04 ``` ### 6.4 版本节奏与兼容 DTK 一般在 **每年 4 月、10 月** 发布大版本，包含： - 组件升级 - 新特性 - 问题修复 官方强调 **向前兼容**。实务上建议： - 生产集群：跟管理员确认统一版本 - 性能敏感业务：新版本可做 A/B 基准 - 长期项目：在 CI 里固定 DTK 版本，避免「能编过但行为变了」 ### 6.5 编译 vs 运行的环境要求 | 动作 | 是否必须有 DCU 硬件 | |------|-------------------| | 编译 DCU 程序 | 否（登录节点常可编译） | | 运行 DCU 程序 | 是（需申请带 DCU 的计算节点） | --- ## 七、文档与学习路径建议 DTK 自带文档位于下载页对应版本的 `Document` 目录（以 DTK-26.04 为例）。 官方文档适合查 **API 细节、工具参数、边界行为**；本文更偏 **全景认知与路线选择**。 推荐学习顺序： 1. 用 `rocm-smi` 确认环境可见设备 2. 跑通一个最小 HIP 样例（编译 + 运行） 3. 用 `hipprof` 看一次时间线 4. 按业务引入 hipBLAS / MIOpen 等库 5. 需要并行扩展时再评估 OpenMP / RCCL --- ## 八、结语：把 DTK 当成「生产力系统」而非「安装包」 很多人第一次接触 DCU，会把注意力全放在「卡够不够、驱动对不对」。但真正决定交付效率的，往往是 **DTK 是否用对**： - 选对编程路径，减少迁移摩擦 - 善用库而不是手写一切 - 用 prof + smi 形成「开发—测量—优化」闭环 DTK 的价值，不在于某个单独工具，而在于它把 **语言、库、编译器、运行时、通信** 串成了一条可复制的工程路径。 当你能在集群上稳定地完成「编写 → 编译 → 运行 → 诊断 → 迭代」，才算真正进入了 DCU 开发的主航道。 --- ## 附录：HIP 库与 CUDA 生态对照（便于迁移同学查阅） | HIP / DTK 库 | CUDA 对应 | 一句话说明 | |--------------|-----------|-----------| | hipBLAS | cuBLAS | 基础线性代数 | | hipFFT | cuFFT | 傅里叶变换 | | hipRAND | cuRAND | 随机数 | | hipSOLVER | cuSOLVER | 矩阵求解 | | hipSPARSE | cuSPARSE | 稀疏线性代数 | | Thrust | Thrust | 并行算法（STL 风格） | | hipCUB | CUB | 底层并行原语 | | RCCL | NCCL | 多卡通信 | | MIOpen | cuDNN | 深度学习基础算子 | | HIP RTC | NVRTC | 运行时编译 | | hipBLASLt | cuBLASLt | GEMM 专用加速 | | hipDNN | cuDNN | 深度神经网络加速 | --- **作者说明：** 本文基于公开资料与实践经验整理，旨在帮助开发者快速建立 DTK 全局认识。具体 API 与版本特性请以官方 Document 为准。