AMD 核心软件组织的 GitHub 全景：1000+ 仓库与 ROCm / NPU 技术路线

AMD 的 GitHub 不是一个组织，而是一张“核心计算 + 芯片平台（含 NPU）+ AI 模型 + 图形生态”的分层地图。本文以 2026-10-27 的 GitHub 公开数据、ROCm 10.1.0 与 Ryzen AI 官方文档为准：先把组织和仓库盘清，再用图拆开 ROCm 与 Ryzen AI NPU 的调用关系、软件栈和技术路线。（由 AI 辅助整理，数据和链接以官方来源为准）

图示已统一画布尺寸；部分复杂图拆成左右/三列/四列面板，便于对照阅读。

0. 统计口径

本文覆盖 AMD 的 9 个主组织：ROCm、amd、AMD-AGI、AMD-Ecosystem、AMDResearch、GPUOpen-LibrariesAndSDKs、GPUOpen-Effects、GPUOpen-Tools、GPUOpen-Drivers。

这里的“全景”指 AMD 核心软件组织的全景，不是所有 AMD GitHub 组织的穷举；Xilinx 等只在 NPU 上游处引用。

共 1035 个公开仓库：596 个活跃非 fork、366 个 fork（含 17 个已归档 fork）、90 个归档仓库。三列相加为 1052，比 1035 多 17，因为归档 fork 被同时计入 fork 和归档。另外附录还收录 9 个外围官方组织（AMD-HPC、AMDESE、pensando、AMDEPYC、AMDComputeLibraries、ROCm-LS、ROCm-DS、amd-enterprise-ai、AMD-AIM），共 144 个仓库；另有 3 个历史组织的 14 个归档仓库。

不包含：

• AMD-OSX：社区的黑苹果项目，不是 AMD 官方软件栈。
• AMDlab：名称相近，但内容是与半导体无关的建筑设计工具。
• 历史组织名 ROCmSoftwarePlatform、RadeonOpenCompute、ROCm-Developer-Tools：共 14 个归档仓库，已迁移到 ROCm，见附录 11.3。
• AMD-IT、AMD-DC-GPU、AMD-OpenSIL、AMD-AI 等空组织：当前没有公开仓库，暂不展开。
• Xilinx：AMD 收购后的独立 GitHub 组织；mlir-aie、mlir-air 是 NPU 编译器上游，只在第 8 节引用，不计入 1035。

说明：仓库数量、Star 数和简介会随时间变化；本文是 2026-10-27 的快照。完整清单保留 GitHub 官方英文简介，避免二次翻译失真；核心仓库在正文中给出中文解读。

1. 一张图看组织：AMD 的 GitHub 是“三层结构”

flowchart TB
  AMD["AMD GitHub 生态<br/>1000+ 公开仓库"]

  subgraph CORE["核心 GPU 计算"]
    ROCM["ROCm<br/>414 个仓库"]
  end

  subgraph PLATFORM["芯片、平台与 AI"]
    AMDORG["amd<br/>126 个仓库"]
    AGI["AMD-AGI<br/>72 个仓库"]
    ECO["AMD-Ecosystem<br/>213 个仓库"]
    RES["AMDResearch<br/>23 个仓库"]
  end

  subgraph GRAPHICS["图形、游戏与可视化"]
    LIB["GPUOpen-Libraries<br/>85 个仓库"]
    FX["GPUOpen-Effects<br/>22 个仓库"]
    TOOLS["GPUOpen-Tools<br/>66 个仓库"]
    DRV["GPUOpen-Drivers<br/>14 个仓库"]
  end

  AMD --> CORE
  AMD --> PLATFORM
  AMD --> GRAPHICS

图 1：AMD GitHub 组织地图。 图里是三层：AMD GitHub 生态 → 3 类组织 → 9 个组织；仓库数量标在组织节点上，不再单独画仓库层。ROCm 负责 GPU 通用计算；amd / AMD-AGI / AMD-Ecosystem / AMDResearch 负责芯片平台、AI 模型与生态移植；四个 GPUOpen 组织负责图形、游戏和可视化。

1.1 数字先看

fork 列含已归档 fork；归档 列含其中 17 个（ROCm 16、GPUOpen-Drivers 1），所以这两行三列相加会多于仓库数。这 9 个主组织在附录中的 fork 标签数为 349。

1.2 三个关键结论

第一，ROCm 正在“收拢”。

2025—2026 年 ROCm 最大的变化不是新增某个库，而是仓库结构重组：

• 自 ROCm 7.14 起，ROCm 改用 TheRock 构建和发布；
• 数学/算子库集中到 ROCm/rocm-libraries 超级仓库；
• 运行时、通信、性能工具等集中到 ROCm/rocm-systems 超级仓库；
• 旧的单组件仓库大量标记为 [DEPRECATED] Moved to ...，部分已归档。

所以今天看 ROCm，不能只看 ROCm/rocBLAS、ROCm/rccl 这些旧仓库，而要先看 TheRock、rocm-libraries、rocm-systems 三个入口。

第二，AMD 的 GitHub 远不止 ROCm。

• amd 组织覆盖 Ryzen AI NPU、AOCL CPU 数学库、EPYC 系统管理、FPGA/Vitis；
• AMD-AGI 是 AMD 的 AI 模型与训练/推理优化组织；
• AMD-Ecosystem 是 CUDA 项目向 ROCm 移植的“生态池”；
• NPU 仓库分散在 amd（RyzenAI-SW、xdna-driver、IRON、Triton-XDNA）、ROCm（FastFlowLM、FastFlow-SDK、HRX）和 AMDResearch（Riallto、NPUEval、Ryzers），详见第 8 节；
• 四个 GPUOpen 组织构成一条完整的 图形/游戏技术栈，与 ROCm 计算栈相对独立。

第三，AMD-Ecosystem 的 213 个仓库里约 190 个是 fork。

这说明它的角色不是“核心 SDK”，而是 生态移植与适配层：把 llama.cpp、SGLang、FlashInfer、LMCache、MONAI、OpenFold、MuJoCo、gsplat 等上游项目移植到 AMD GPU。真正的核心实现仍然在 ROCm、amd、AMD-AGI 三个组织里。

2. 组织逐个看

2.1 ROCm：核心 GPU 计算栈

ROCm 是 AMD 的开放 GPU 计算平台，覆盖编译器、运行时、数学库、通信库、性能工具和调试工具。官方文档对它的定义是：

ROCm is AMD’s open-source GPU computing platform: an end-to-end ecosystem of compilers, runtimes, and libraries for AI, HPC, and domain-specific workloads.

ROCm 组织有 414 个仓库，但其中大量是历史仓库、fork 和镜像。建议按“新入口 / 仍活跃 / 已迁移”三组看：

新入口（先看这三个）

仍活跃的组件/工具

已迁移/旧仓库（只作参考）

“仍活跃”只表示 GitHub 仓库未归档/仍在使用；其中部分组件已在 rocm-libraries / rocm-systems 里有镜像。写新代码优先从新入口开始。

ROCm 仓库状态提示：

• 看到 [DEPRECATED] Moved to ROCm/rocm-libraries：说明该库已迁入 rocm-libraries；
• 看到 [DEPRECATED] Moved to ROCm/rocm-systems：说明该库已迁入 rocm-systems；
• 看到 ARCHIVED：历史仓库，通常只保留只读镜像或旧版发布；
• 看到 FORK：上游项目的 AMD 分支（如 PyTorch、LLVM、vLLM）。

注意：FastFlowLM / FastFlow-SDK / hrx-system 是 NPU 项目，托管在 ROCm 组织不等于它们属于 ROCm GPU 栈。详见第 8 节。

2.2 amd：芯片平台与 CPU/NPU 软件

amd 组织不是 ROCm 的重复，而是 AMD 公司层面的“芯片平台软件”：

• Ryzen AI / XDNA NPU：RyzenAI-SW、xdna-driver、IRON、Triton-XDNA、GAIA、Quark；
• AOCL / Zen CPU 数学库：BLIS、libFLAME、FFTW、LibM、Sparse、Crypto、Compression、ZenDNN；
• EPYC 系统管理与安全：ESMI、HSMP、APML、SEV、perfspect、node-scraper；
• FPGA / 嵌入式 / ISP：Vitis-AI、Kria-RoboticsAI、mini-isp、Linux ISP；
• 视频分析 / VP AI：VAIP、XIR、VART。

2.3 AMD-AGI：开源模型、训练与推理优化

AMD-AGI 是 AMD 的 AI Group。它的仓库可以分成四类：

1. 开源基础模型：Instella、Instella-MoE、Instella-Math、Instella-T2I、InstellaVL、AMD-LLM、Nitro、Hummingbird；
2. 训练框架：Primus、Primus-Turbo、Primus-SaFE、torchtitan-amd、maxtext-slurm；
3. 推理/算子优化：Hyperloom、GEAK、Apex、AgentKernelArena、AMDKernelVault、Infera；
4. 算法研究：PARD、Gumiho、FLy、DUET-VLM、ReasonLite、Tyr-the-Pruner、LoKRA、ALTO。

注意：AMD 官方模型页有些链接仍指向旧组织 AMD-AIG-AIMA，但 GitHub 会把旧仓库地址重定向到 AMD-AGI。可以认为 AMD-AGI 是当前组织名。

另外还有 AMD-AIM（AMD AI Group, AIM）的 21 个仓库，聚焦 Radeon、Radeon Cloud 和 GPU MODE 参考 kernel，详见附录 11.2。

2.4 AMD-Ecosystem：CUDA → ROCm 的生态移植池

AMD-Ecosystem 的官方定位是：

The unified public home for open-source ecosystem software libraries, covering simulation, finance, LLM extension, life science, data science, and standalone utilities.

它最重要的特征不是“仓库多”，而是 fork 比例极高：213 个仓库中约 190 个是 fork。这说明它是一个 移植/适配层，把上游 CUDA 项目逐个搬到 ROCm/HIP。

2.5 AMDResearch：研究与教学原型

AMDResearch 更像“前孵化器”：NPU 教学、GPU 性能工具、HPC 研究原型、AI4Science 配方。它的仓库不一定进入正式 ROCm 发行版，但能提前看到 AMD 在探索什么。

2.6 GPUOpen：图形、游戏与可视化

四个 GPUOpen 组织构成一条独立的图形栈，和 ROCm 计算栈并行：

• GPUOpen-LibrariesAndSDKs：SDK 与库（FidelityFX SDK、AMF、Vulkan/D3D12 内存分配器、HIP RT、Radeon ProRender）；
• GPUOpen-Effects：特效库（FSR、TressFX、FEMFX、SSSR、CACAO、Denoiser）；
• GPUOpen-Tools：工具（RGP、RGA、RMV、RRA、OCAT、Compressonator、GPU Reshape）；
• GPUOpen-Drivers：开源驱动（AMDVLK、PAL、XGL、LLPC、GPURT）。

3. ROCm 软件栈：从应用到 GPU

3.1 分层视图

flowchart TB
  A["应用与框架<br/>PyTorch / JAX / TensorFlow<br/>vLLM / SGLang / ATOM<br/>ONNX Runtime / MIGraphX"]
  B["AI 算子与加速库<br/>AITER / CK / hipBLASLt<br/>MIOpen / AOTriton / tritonBLAS"]
  C["ROCm Core SDK<br/>BLAS / FFT / RAND / SPARSE / SOLVER<br/>rocPRIM / rocWMMA / RCCL / rocSHMEM"]
  A --> B --> C

flowchart TB
  D["编程模型与编译器<br/>HIP / HIPIFY / OpenCL / OpenMP<br/>Triton / Gluon / FlyDSL<br/>amdclang / LLVM AMDGPU / COMGR"]
  E["运行时与驱动<br/>CLR：hipamd + rocclr<br/>ROCr（Linux）/ PAL（Windows）<br/>amdkfd + amdgpu"]
  F["硬件<br/>CDNA / RDNA"]
  D --> E --> F

图 2：ROCm 软件栈分层。 左列：应用→算子→Core SDK；右列：编程模型/编译器→运行时/驱动→GPU。

XDNA NPU 不在 ROCm 支持范围；图 2 只画 GPU 栈，NPU 见第 8 节。

3.2 仓库级调用关系

flowchart TB
  APP["应用<br/>PyTorch / vLLM / SGLang / ATOM"] --> AITER["AITER<br/>CK / Triton / ASM / hipBLASLt"]
  AITER --> MATH["数学与 DNN<br/>rocBLAS / rocFFT / MIOpen / rocWMMA"]

flowchart TB
  HIP["HIP Runtime<br/>CLR：hipamd + rocclr<br/>编译：LLVM AMDGPU / COMGR"] --> RT["ROCr（Linux）/ PAL（Windows）<br/>amdkfd + amdgpu"]
  RT --> HW["CDNA / RDNA GPU"]

图 3：ROCm 仓库级调用关系。 左列：应用→AITER→数学库；右列：HIP Runtime→ROCr/PAL→GPU。MIGraphX/ONNX Runtime 走独立图执行路径，未画入这张 AITER 主链。

3.3 编译与运行调用链

flowchart TB
  CUDA["CUDA 源码"] --> IFY["HIPIFY"] --> S["HIP C++ / OpenCL C"]
  S --> F["Clang 前端<br/>amdclang++"] --> O["LLVM AMDGPU<br/>+ ROCm device-libs"]
  TRI["Triton / Gluon / FlyDSL"] --> MLIR["Triton MLIR / Fly MLIR"] --> O
  O --> CM["COMGR<br/>链接 / 检查 code object"] --> C["HSACO code object"]

flowchart TB
  C["HSACO code object"] --> R["HIP Runtime API<br/>CLR: hipamd + rocclr"]
  R --> H["ROCr（HSA）<br/>Linux"]
  R --> P["PAL<br/>Windows"]
  H --> T["libhsakmt / ROCt thunk"] --> K["amdkfd + amdgpu 内核驱动"]
  P --> K
  K --> G["AMD GPU"]

图 4：编译链（左）与运行链（右）。 HIP 源码由 amdclang 编译，经 LLVM AMDGPU 后端生成 HSACO；运行时 CLR 在 Linux 上走 ROCr，在 Windows 上走 PAL，最终通过 amdkfd/amdgpu 驱动提交到 GPU。

几个容易混淆的点：

• HIP 不是“另一个 CUDA”：HIP 是 C++ 运行时 API + kernel 语言，API 与 CUDA 高度相似，但后端是 AMD 的 CLR/ROCr。
• CLR 不是一个库：CLR 包含 hipamd、rocclr、opencl 三部分；rocclr 是虚拟设备接口，Linux 对接 ROCr，Windows 对接 PAL。
• ROCT thunk 已并入 ROCR-Runtime：旧的 ROCT-Thunk-Interface 仓库已标记废弃，libhsakmt/ROCT 的工作并入 ROCR-Runtime。
• COMGR 是编译器侧的“胶水”：负责 code object 的链接、编译和检查，不是运行时调度器。

3.4 roc* 和 hip* 的区别

官方文档说得很清楚：

• roc* 前缀：AMD 原生、用 HIP 写的高性能实现，例如 rocBLAS、rocFFT、rocSPARSE、rocSOLVER、rocPRIM；
• hip* 前缀：通常是可移植的封装层，实现与 CUDA 对应的 API，让 CUDA 应用尽量少改代码就能跑在 AMD GPU 上，例如 hipBLAS、hipFFT、hipRAND、hipSPARSE、hipSOLVER、hipCUB；例外是 hipBLASLt，它本身是 AMD 的高性能灵活 GEMM 实现。

对应关系可以记成：

例外：hipBLASLt 不是 CUDA 封装，而是 AMD 自己的高性能灵活 GEMM 库；hip* 不应一概理解为 wrapper。

选择原则：

• 新项目、追求峰值性能：优先用 roc* 或 AITER/CK；
• 从 CUDA 迁移、想少改代码：先用 hip* 封装层；
• 需要灵活 GEMM / 融合：用 hipBLASLt + CK/AITER；
• 需要图推理：用 MIGraphX 或 ONNX Runtime。

4. 技术路线：AMD GPU 编程的五条主路

flowchart TB
  subgraph ROUTES["五条主要编程路线"]
    H["HIP C++<br/>原生高性能路线"]
    C["CUDA → HIPIFY → HIP<br/>迁移路线"]
    OCL["OpenCL C<br/>跨厂商标准路线"]
    OMP["OpenMP / Fortran<br/>HPC 路线"]
    TRI["Triton / Gluon / FlyDSL<br/>AI Kernel DSL 路线"]
  end

  H --> LLVM["amdclang / LLVM AMDGPU"]
  C --> LLVM
  OCL --> LLVM
  OMP --> LLVM
  TRI --> MLIR["Triton MLIR / rocMLIR"]
  MLIR --> LLVM
  LLVM --> HSACO["HSACO / code object"]
  HSACO --> RT["CLR / ROCr / PAL"]
  RT --> GPU["AMD GPU"]

  PY["Python / hip-python"] --> H
  FORT["Fortran / hipfort"] --> OMP

图 5：五条编程路线。 所有路线最终都会落到 LLVM AMDGPU 后端、HSACO 和 HIP/ROCr 运行时。

4.1 路线一：CUDA → HIP 迁移

适合：已有 CUDA 代码、想快速跑在 AMD GPU 上。

路径：

CUDA 源码 → HIPIFY（hipify-clang / hipify-perl）→ HIP C++ → amdclang → HSACO → CLR/ROCr → GPU

关键仓库：

• HIPIFY：CUDA 到 HIP 的源码翻译；
• hipify_torch：PyTorch 生态的 CUDA→HIP 翻译；
• hipother：在 NVIDIA 平台上把 HIP API 映射回 CUDA 的兼容层；
• hipBLAS/hipFFT/hipRAND/hipSPARSE/hipSOLVER/hipCUB：CUDA 对应库的封装。

现实提醒：HIPIFY 不能自动翻译所有 CUDA 代码。没有 HIP 等价库的 CUDA 库、以及针对 NVIDIA 架构做的性能优化，仍然需要人工重写和调优。官方 HIPIFY 文档明确建议：迁移后要做代码审查、替换不支持的库、重新调试和性能优化。

4.2 路线二：原生 HIP 高性能

适合：新写 kernel、追求峰值性能、需要精细控制。

路径：

HIP C++ → amdclang → LLVM AMDGPU → HSACO → CLR/ROCr → GPU

关键仓库：

• hip：HIP 运行时 API 与 kernel 语言；
• llvm-project：amdclang、AMDGPU 后端、device-libs；
• rocPRIM/rocThrust/rocWMMA/hipTensor：并行原语与张量；
• rocprofiler-sdk/rocprofiler-compute/ROCgdb：性能分析与调试。

优化工具链：

• rocprofiler-compute：kernel 级指标；
• rocprofiler-systems：CPU/GPU 系统级 trace；
• roc-optiq：profiler 可视化；
• ROCgdb + ROCdbgapi：源码级调试；
• rocprof-trace-decoder：thread trace 解码。

4.3 路线三：OpenCL 标准路线

适合：已有 OpenCL 代码、需要跨厂商可移植性。

路径：

OpenCL C → clang/SPIR-V → CLR OpenCL runtime → ROCr/PAL → GPU

关键仓库：

• clr 中的 opencl 实现；
• clang-ocl（历史仓库）；
• ROCm-OpenCL-Runtime（已归档，旧版）；
• OpenCL-CTS、OpenCL-Headers（Khronos 规范/测试）。

ROCm 10.x 仍提供 amdrocm-opencl 包（OpenCL runtime + ICD loader），但 OpenCL 不是 AMD 当前 AI/HPC 的主推路线。新项目通常优先 HIP 或 Triton。

4.4 路线四：OpenMP / Fortran HPC

适合：Fortran/C/C++ HPC 应用、已有 OpenMP 代码。

路径：

Fortran/C/C++ + OpenMP target → amdclang / flang + LLVM OpenMP → GPU

关键仓库：

• aomp：AMD 的 OpenMP offload 编译器发行版；
• flang：Fortran 前端；
• hipfort：Fortran 到 HIP 的绑定；
• ROCm-Device-Libs、llvm-project：device 端运行时和编译器。

典型应用：GROMACS、OpenFOAM、SPECFEM3D、rocHPL、rocHPCG。

4.5 路线五：Triton / Gluon / FlyDSL

适合：AI kernel、想用 Python 写高性能 kernel、需要比 HIP 更高的抽象。

路径：

Python Triton / Gluon / FlyDSL → Triton MLIR / Fly MLIR → LLVM AMDGPU → HSACO → GPU

关键仓库：

• triton：AMD 维护的 Triton 分支；
• aotriton：Triton 算子的 ahead-of-time 编译与分发，首个 kernel 是 FlashAttention；
• tritonBLAS：基于 Triton 的分析模型驱动 GEMM 库，不需要 autotune；
• iris：AMD RAD 的 Triton 多 GPU RMA/SHMEM 框架；
• FlyDSL：Python 前端 + Fly MLIR dialect，显式表达 layout/tiling/data movement；
• gfx950-gluon-tutorials：在 MI350/MI355 上用 Gluon 写高性能 GEMM/Attention 的教程。

三条子路线怎么选：

Gluon 的官方教程说得很直白：Triton 强在可移植和生产力，但最后 10%—20% 的性能需要显式控制；Gluon 是 Triton 的 dialect，用 block-level 编程模型补上这一段。

5. AI 推理与训练路线

5.1 AI 推理：vLLM / SGLang / ATOM + AITER

flowchart TB
  MODEL["模型<br/>Llama / DeepSeek / Qwen / Kimi"] --> SERVE["推理框架<br/>vLLM / SGLang / ATOM"]
  SERVE --> AITER["AITER<br/>Attention / MoE / GEMM / Norm"]
  AITER --> BACKENDS["算子后端<br/>CK / Triton / ASM / hipBLASLt"]
  BACKENDS --> HIP["HIP Runtime"]
  LLAMA["llama.cpp"] --> HIP
  HIP --> RT["ROCr / PAL + amdgpu"]
  RT --> GPU["Instinct MI300 / MI350"]
  SERVE --> DIST["分布式<br/>RCCL / MORI / rocSHMEM"]
  DIST --> NIC["RDMA NIC<br/>Pensando AINIC / Thor2 / ConnectX-7"]
  ONNX["ONNX 模型"] --> MIGX["MIGraphX"] --> HIP

图 6：AI 推理路线。 AITER 是 AMD 当前 LLM 推理的核心算子层；vLLM、SGLang、ATOM 都通过 AITER 调用 CK/Triton/ASM/hipBLASLt；llama.cpp 直接走 HIP/rocBLAS，不经过 AITER。

AITER 的定位（官方 README）：

• AMD 高性能 AI 算子库；
• 多后端：Triton、Composable Kernel、手写 ASM；
• 覆盖推理和训练，不只是 serving kernel；
• 框架无关，可集成到 vLLM、SGLang 或自定义框架；
• 官方称其为 “default kernel backend for LLM inference on AMD GPUs”。

ATOM 是基于 AITER 的轻量 vLLM 风格实现，支持 OpenAI 兼容 API、TP/DP/EP、P/D 分离、KV cache 传输（Mooncake/MORI-IO）、FP8/MXFP4/INT8/INT4 量化、speculative decoding。

MIGraphX 是另一条路线：把 ONNX 模型编译成 AMD GPU 上的图执行引擎，适合非 Transformer 或需要图优化的场景。

5.2 AI 训练：Primus + Megatron/TorchTitan/MaxText

flowchart TB
  S["Primus-SaFE<br/>稳定性 / 故障容错"] -.-> P["Primus<br/>YAML 驱动训练编排"]
  P --> B["训练后端<br/>Megatron-LM / TorchTitan<br/>JAX MaxText / Megatron Bridge"]
  B --> PT["PyTorch / JAX"]

flowchart TB
  PT["PyTorch / JAX"] --> T["Primus-Turbo / AITER / hipBLASLt"]
  T --> C["RCCL / MORI / rocSHMEM"]
  C --> H["HIP Runtime → ROCr → amdgpu"]
  H --> G["MI300X / MI325X / MI355X 集群"]

图 7：训练编排（左）与算子/运行（右）。 Primus 是编排层，下面是 Megatron/TorchTitan/MaxText，再下面是 Primus-Turbo/AITER/hipBLASLt，最后是 RCCL/MORI 和 GPU。

Primus 的官方文档把它定义为“YAML 驱动的、面向 AMD GPU 的大规模基础模型训练框架”，支持：

• Megatron-LM；
• TorchTitan；
• JAX MaxText；
• Megatron Bridge；
• HummingbirdXT。

它的三层生态是：

Primus-SaFE（稳定性/集群管理）
        ↓
Primus-LM（训练编排）
        ↓
Primus-Turbo（算子/kernel）

5.3 HPC 路线

flowchart TB
  APP["GROMACS / OpenFOAM / SPECFEM3D / rocHPL"] --> LANG["MPI + OpenMP + Fortran/C++"]
  LANG --> COMP["amdclang / AOMP / Flang / hipfort"]

flowchart TB
  LIB["rocBLAS / rocFFT / rocSPARSE / rocSOLVER"] --> COMM["RCCL / rocSHMEM"]
  COMM --> RT["HIP Runtime → ROCr → amdgpu"]
  RT --> GPU["MI300A / MI355X / MI250X"]

图 8：应用与编译（左）、数学库与运行（右）。 HPC 应用通常走 MPI + OpenMP/Fortran，再调用 rocBLAS/rocFFT/rocSPARSE/rocSOLVER 和 RCCL/rocSHMEM。

HPC 关键仓库：

• aomp、flang、hipfort：编译与 Fortran 绑定；
• rocBLAS、rocFFT、rocSPARSE、rocSOLVER、rocALUTION：数学库；
• RCCL、rocSHMEM：集合通信；
• rocHPL、rocHPCG、rocHPL-MxP：HPC 基准；
• Gromacs、OpenFOAM_HMM、SPECFEM3D：应用移植。

5.4 分布式通信路线

flowchart TB
  APP["训练 / 推理框架"] --> CCL["集合通信"]
  CCL --> RCCL["RCCL<br/>AllReduce / AllGather / ReduceScatter"]
  CCL --> SHMEM["rocSHMEM<br/>GPU 发起、对称堆"]
  CCL --> MORI["MORI<br/>MORI-EP / MORI-IO / MORI-CCL / MORI-UMBP"]
  RCCL --> XGMI["xGMI / PCIe"]
  RCCL --> RDMA["RDMA"]
  SHMEM --> RDMA
  MORI --> RDMA
  RDMA --> NIC["Pensando AINIC / Broadcom Thor2 / ConnectX-7"]
  NIC --> CLUSTER["多节点 GPU 集群"]

图 9：分布式通信路线。 节点内走 xGMI/PCIe，节点间走 RDMA；RCCL 是通用集合通信，rocSHMEM 是 GPU 发起的细粒度通信，MORI 面向 MoE EP 和 KV cache 传输。

三条路线的关系：

• RCCL：最通用的集合通信库，类似 NCCL 的 AMD 对应物；
• rocSHMEM：OpenSHMEM 风格，适合 GPU 内核内部直接做远程内存访问；
• MORI：模块化 RDMA 框架，MORI-EP 做 MoE dispatch/combine，MORI-IO 做 KV cache 点对点传输，MORI-CCL 做定制集合通信。

MORI 官方 README 明确支持 AMD Pensando DSC、Broadcom Thor2、NVIDIA Mellanox ConnectX-7 等 NIC，并已被 SGLang、vLLM、DeepSpeed 等集成。

6. 图形与光追路线

flowchart TB
  APP["游戏 / 渲染 / 内容创作"] --> API["Vulkan / DX12 / OpenGL"]
  APP --> FX["FidelityFX SDK"] --> API
  API --> AMDVLK["AMDVLK"] --> XGL["XGL"]

flowchart TB
  XGL["XGL"] --> PAL["PAL / LLPC"] --> KMD["amdgpu 内核驱动"] --> GPU["Radeon GPU"]
  HIPRT["HIP RT"] --> HIP["HIP / ROCm"] --> KMD

图 10：图形 API/驱动前端（左）与平台/内核/光追（右）。 图形栈走 Vulkan/DX12/OpenGL → AMDVLK/XGL/LLPC/PAL；光追可以走 FidelityFX/HIP RT；HIP RT 把光追带到 HIP/ROCm。

AMDVLK 的架构（官方 README）：

• AMDVLK：开源 Vulkan 驱动；
• PAL：平台抽象库，封装硬件和 OS 细节；
• XGL：Vulkan API 层；
• LLPC：LLVM-Based Pipeline Compiler，把 shader 编译成 PAL 兼容 code object；
• GPURT：GPU 光线追踪库；
• LLVM：shader 编译基础设施。

说明：pal、xgl、llpc、gpurt 仓库目前为归档状态，但 AMDVLK 的架构仍由这些组件构成；阅读源码时以 AMDVLK README 引用的组件关系为准。

GPUOpen 工具链：

• RGP：Radeon GPU Profiler，深度分析 GPU workload；
• RGA：Radeon GPU Analyzer，离线编译和代码分析；
• RMV：Radeon Memory Visualizer，显存使用分析；
• RRA：Radeon Raytracing Analyzer，BVH 可视化；
• OCAT：FPS overlay 与性能测量；
• Compressonator：纹理/模型压缩；
• GPU Reshape：指令级插桩与验证。

7. 硬件路线：CDNA、RDNA、XDNA

flowchart TB
  MI100["MI100<br/>CDNA1 gfx908"] --> MI250["MI250X<br/>CDNA2 gfx90a"]
  MI250 --> MI300["MI300X/A<br/>CDNA3 gfx942"]
  MI300 --> MI355["MI355X<br/>CDNA4 gfx950"]

flowchart TB
  RDNA3["RX 7000<br/>RDNA3 gfx110x"] --> RDNA35["Ryzen AI Max<br/>RDNA3.5 gfx115x"]
  RDNA35 --> RDNA4["RX 9000 / R9700<br/>RDNA4 gfx120x"]

flowchart TB
  XDNA["XDNA / XDNA2<br/>AIE2 / AIE2P"] --> IRON["IRON / Triton-XDNA"]

图 11：Instinct（左）、Radeon/Ryzen（中）、Ryzen AI NPU（右）。 CDNA 面向数据中心 Instinct，RDNA 面向 Radeon/Ryzen，XDNA 面向 Ryzen AI NPU；前两者走 ROCm，XDNA 走 Ryzen AI Software。

7.1 关键规格

数据来自 ROCm 10.1.0 官方 GPU specifications 与兼容性矩阵；不同 SKU 的显存/规格可能不同。

NPU（XDNA1/XDNA2）的规格和软件栈见第 8 节，不在 ROCm 兼容性矩阵里。

7.2 ROCm 10.1 的支持范围

官方兼容性矩阵列出的 LLVM target 包括：

• CDNA4：gfx950（MI355X、MI350X、MI350P）
• CDNA3：gfx942（MI325X、MI300X、MI300A）
• CDNA2：gfx90a（MI250X、MI250、MI210）
• CDNA1：gfx908（MI100）
• RDNA4：gfx1200、gfx1201（RX 9060/9070、Radeon AI PRO R9700）
• RDNA3：gfx1100、gfx1101、gfx1102、gfx1103
• RDNA3.5：gfx1150、gfx1151、gfx1152、gfx1153（Ryzen AI 300/400、Ryzen AI Max）

XDNA NPU 不在 ROCm 的支持列表里。Ryzen AI NPU 走的是第 8 节的独立软件栈（Ryzen AI Software、IRON、Triton-XDNA、FastFlow-SDK）。ROCm 支持的是 Ryzen APU 的 iGPU（RDNA3.5），不是 NPU。

8. NPU：Ryzen AI 的软件栈与路线

这一节讲的是 Ryzen AI PC 里的 XDNA NPU，不是 ROCm 的 GPU，也不是 Versal AI Edge 的 Vitis AI。

8.1 硬件：XDNA1 → XDNA2

AMD 的 NPU 不是 GPU 的“小核”，而是一块独立的空间数据流（spatial dataflow）AI Engine 阵列。每个 AI Engine tile 包含：

• VLIW/SIMD 向量处理器；
• RISC 标量处理器；
• 本地程序存储器和数据存储器；
• 专用互连与 DMA。

它不靠大缓存，而是靠 tile 本地内存和显式数据流，所以功耗低、时延确定。

XDNA2 相对 XDNA1 的关键变化：每 tile 2× MAC、1.6× on-chip memory、block floating point，AI Engine 性能约 3×，NPU 达到 50 TOPS。不同 SKU 的 TOPS 不同：Ryzen AI 300 / Max 为 50，Ryzen AI PRO 300 为 55，Ryzen AI 400 / PRO 400 最高 60。

数字来自 AMD XDNA 架构页、IRON ISCA 2025 教程、Ryzen AI 400 CES 2026 发布页和 Ryzen AI Embedded 发布页。XDNA2 的 32 tiles/4×8 指计算 tile；不同 SKU/工具显示的拓扑可能不同。

7040/8040 的 10/16 TOPS、PRO 300 的 55 TOPS、P121i 的 30 TOPS 分别来自 AMD 对应产品页/发布资料，链接见第 12 节。

flowchart TB
  P["Phoenix / Hawk Point<br/>Ryzen 7040 / 8040"] --> X1["XDNA1<br/>AIE2 · 20 tiles · 4×5<br/>10 / 16 TOPS"]

flowchart TB
  S["Strix Point / Strix Halo<br/>Ryzen AI 300 / Max"] --> X2["XDNA2<br/>AIE2P · 32 tiles · 4×8<br/>50 TOPS"]
  K["Kraken / Gorgon<br/>Ryzen AI 400"] --> X2
  X2 --> H["最高 60 TOPS<br/>Ryzen AI 400 / PRO 400"]

flowchart TB
  E["P100 / X100"] --> EX["XDNA2<br/>最高 50 TOPS"]
  P2["P121i"] --> EX2["XDNA2<br/>30 TOPS"]

图 12：XDNA1（左）、XDNA2（中）、嵌入式 XDNA2（右）。 XDNA1 是 20 tiles/4×5、10/16 TOPS；XDNA2 是 32 tiles/4×8、50–60 TOPS；嵌入式 P100/X100 最高 50 TOPS，P121i 为 30 TOPS。

8.2 软件栈：两条栈、五层

Ryzen AI NPU 的软件栈可以按“部署栈”和“编程栈”来理解。两条栈共用驱动和硬件，但入口、编译器和运行时不同。

OGA = ONNX Runtime GenAI；Ryzen AI 文档里 llama.cpp 只支持 iGPU，NPU-only 的 LLM 路线用 OGA/FastFlowLM。Lemonade 是多厂商的本地 LLM SDK，FastFlowLM 已集成到 Lemonade。

flowchart TB
  A1["应用/模型<br/>ONNX：PyTorch / TF → ONNX<br/>IRON：Python / Triton / FastFlowLM"] --> A2["框架/API<br/>ONNX Runtime + Vitis AI EP<br/>IRON API / Triton / FastFlowLM"]

flowchart TB
  B1["量化/编译<br/>Quark / Vitis AI EP<br/>MLIR-AIE / MLIR-AIR + Peano"] --> B2["编译产物<br/>量化模型 / 编译图<br/>PDI / xclbin"]

flowchart TB
  C1["运行时<br/>XRT + XRT SHIM<br/>HRX"] --> C2["驱动/硬件<br/>amdxdna / Windows NPU 驱动<br/>XDNA1 / XDNA2"]

图 13：NPU 软件栈的三段压缩视图。 左：应用/模型 + 框架/API；中：量化/编译 + 产物；右：运行时 + 驱动/硬件。完整五层见上表。

8.3 四条路线

把上面的栈拆开，实际有四个入口：

1. ONNX / Vitis AI EP：最像“部署”的路线，适合 CNN/Transformer；
2. IRON：close-to-metal，适合写自定义算子/kernel；
3. Triton-XDNA：把 Triton kernel 编译到 NPU，适合 Triton 用户/研究；
4. FastFlowLM / FastFlow-SDK：NPU-first LLM 运行时，适合开箱即用跑 LLM/VLM/ASR。

另外，Vitis-AI / VAIP / XIR / VART 是 Versal AI Edge 的独立路线，不是 Ryzen AI NPU，见 8.6。

flowchart TB
  A1["PyTorch / TF"] --> A2["ONNX"] --> A3["Quark"] --> A4["ORT + VAI-EP"] --> A5["XRT / SHIM"] --> A6["NPU"]

flowchart TB
  B1["IRON"] --> B2["MLIR-AIE"] --> B3["Peano → PDI"] --> B4["HRX / XRT"] --> B5["NPU"]

flowchart TB
  C1["Triton"] --> C2["triton-shared"] --> C3["MLIR Transform"] --> C4["MLIR-AIR/AIE"] --> C5["XRT binary"] --> C6["NPU"]

flowchart TB
  D1["Lemonade / GAIA"] --> D2["FastFlowLM"] --> D3["IRON ops"] --> D4["HRX"] --> D5["NPU"]

图 14：四条 NPU 路线（从左到右）。 A：ONNX/Vitis AI EP；B：IRON；C：Triton-XDNA；D：FastFlowLM/FastFlow-SDK。

• A 是 Ryzen AI Software 的主推部署路线：Vitis AI EP 会切分图，把能跑 NPU 的部分交给 NPU；Windows 上不支持的算子可回退 CPU/iGPU，Linux 当前是 NPU-only。Linux 的运行时栈是 XRT + XRT SHIM，Windows 走 NPU 驱动栈。
• B 的 IRON 本身不提供 kernel，kernel 来自 MLIR-AIE 的 aie_kernels；@iron.jit 把 Python 定义的工作负载编译成 NPU 程序，ObjectFifo 负责声明式数据搬运。
• C 目前是实验项目，官方 README 说 matmul 可达到手写 NPU 实现的性能，90% 测试配置达到 baseline 的 90% 以上；支持 matmul、elementwise、softmax、layer norm。
• D 的 FastFlow-SDK 是早期访问，包含 FastFlowLM + HRX + iron-tools + iron-ops，目标 XDNA2；FastFlowLM 支持 256k context，已被 Lemonade 集成。

8.4 NPU 仓库地图

NPU 相关仓库不在一个组织里，而是分散在 amd、ROCm、AMDResearch，以及上游 Xilinx。

核心 NPU 仓库

相邻/上游仓库

RyzenAI-SW 是示例/教程仓库，不是完整安装包；完整 Ryzen AI Software 需要从 AMD 下载页安装。ROCm/FastFlowLM、FastFlow-SDK、HRX 是 NPU 项目，只是托管在 ROCm 组织，不代表 ROCm 支持 XDNA NPU。Xilinx/mlir-aie、mlir-air 不在本文 1035 个仓库的统计内，但它们是 IRON/Triton-XDNA 的上游。

8.5 与 ROCm 的边界

一句话：ROCm 管 GPU，Ryzen AI Software 管 NPU。Ryzen AI APU 上两者都有：RDNA3.5 iGPU 走 ROCm，XDNA2 NPU 走 Ryzen AI Software / IRON / FastFlow。

8.6 不要混淆：Vitis AI EP、Vitis AI 和 Versal

• Vitis AI EP：ONNX Runtime 的 Execution Provider，跑在 Ryzen AI NPU 上；Ryzen AI Software 用它做图切分/编译。
• amd/Vitis-AI、vaip、xir、vart：Vitis AI 的 Versal AI Edge 推理栈，目标 FPGA/自适应 SoC，不是 Ryzen AI NPU。典型路径是 ONNX → XIR → VAIP → VART → Versal。
• XDNA NPU vs RDNA iGPU：Ryzen AI APU 同时有两者；ROCm 支持 iGPU，Ryzen AI Software/IRON 支持 NPU。

8.7 一句话总结

Ryzen AI NPU 不是 ROCm 的附属品；它有自己的驱动（amdxdna）、运行时（XRT / HRX）、编译器（Vitis AI EP / MLIR-AIE + Peano / MLIR-AIR）和 LLM 运行时（FastFlowLM）。按目标选：部署走 ONNX/Vitis AI EP，写 kernel 走 IRON，Triton 用户走 Triton-XDNA，跑 LLM 走 FastFlowLM。

9. 仓库重组：为什么旧仓库都写着 “Moved”

flowchart TB
  L["旧版：单仓库 / 单组件发布<br/>ROCm/ROCm、ROCm/MIOpen、ROCm/rocBLAS ..."] --> S["超级仓库<br/>rocm-libraries / rocm-systems"]
  L -.-> A["归档 / 只读镜像"]

flowchart TB
  S["超级仓库"] --> T["TheRock<br/>统一构建、测试、发布"] --> P["ROCm Core SDK 10.x<br/>DEB/RPM / Tarball / Wheel / Runfile"] --> E["ROCm Extras / Standalone ONNX"]

图 15：旧版单仓库（左）与超级仓库/TheRock 发布（右）。 从“每个组件一个仓库”转向“超级仓库 + TheRock 统一发布”。

9.1 三个新入口

TheRock：

• 官方定义：The HIP Environment and ROCm Kit；
• 角色：ROCm 的顶层构建与发布系统；
• 自 ROCm 7.14 起，ROCm 通过 TheRock 构建和发布；
• 提供 nightly ROCm、PyTorch、JAX 构建；
• 支持 Linux 多发行版和原生 Windows；
• 构建从源码需要约 200 GB 磁盘空间。

rocm-libraries：

• 数学/算子库超级仓库；
• projects/ 下包括：composablekernel、hipblas、hipblas-common、hipblaslt、hipcub、hipdnn、hipfft、hiprand、hipsolver、hipsparse、hipsparselt、hiptensor、miopen、rocblas、rocfft、rocprim、rocrand、rocsolver、rocsparse、rocthrust、rocwmma、rpp；
• shared/ 下包括：rocroller、tensile、mxdatagenerator、origami。

rocm-systems：

• 系统项目超级仓库；
• projects/ 下包括：amdsmi、aqlprofile、clr、hip、hipfile、hipother、hip-tests、rccl、rdc、rocdbgapi、rocdecode、rocjpeg、rocm-core、rocminfo、rocmsmilib、rocprofiler、rocprofiler-compute、rocprofiler-register、rocprofiler-sdk、rocprofiler-systems、rocr-debug-agent、rocrruntime、rocshmem、roctracer。

9.2 包结构变化

ROCm 10.x 的包名从 rocm-* / roc* / hip* 统一改为 amdrocm-*：

安装目录也从 /opt/rocm-7.2/ 改为 /opt/rocm/core-10.1，并通过 update-alternatives 提供 /opt/rocm 兼容符号链接。

9.3 对开发者的实际影响

1. 不要再从旧仓库起步：新项目看 rocm-libraries / rocm-systems / TheRock；
2. 旧博客/脚本可能失效：包名、安装路径、组件归属都变了；
3. 用 TheRock 构建更可控：适合需要最新功能或自定义组合的开发者；
4. 发行版安装优先用 amdrocm-* 元包：避免单独安装组件导致依赖冲突。

10. 怎么选：按目标找路线

标 rocm-libraries / rocm-systems 的条目表示组件已迁入超级仓库，旧单仓库只作参考。

10.1 三条最常用的组合

组合 A：LLM 推理

模型 → vLLM/SGLang/ATOM → AITER → CK/Triton/ASM/hipBLASLt → HIP → ROCr → MI300X/MI355X

组合 B：LLM 训练

Primus → Megatron/TorchTitan/MaxText → PyTorch/JAX → RCCL/MORI → HIP → MI300X/MI355X 集群

组合 C：HPC

GROMACS/OpenFOAM → MPI + OpenMP/Fortran → AOMP/hipfort → rocBLAS/rocFFT/rocSPARSE → RCCL → HIP → MI250X/MI300A

11. 附录：本文统计范围内的全部仓库清单

以下清单按组织分组，按 Star 数从高到低排列。状态 列含义：活跃 = GitHub 上非 fork、非归档；fork = 上游项目的 AMD 分支；归档 = 只读历史仓库。简介保留 GitHub 官方英文原文。

活跃 只表示 GitHub 状态，不代表项目仍推荐使用；简介含 [DEPRECATED] Moved to ... 的仓库，请以 rocm-libraries / rocm-systems 为准。

fork 列含已归档的 fork；附录状态列只标一个主状态，所以 9 个主组织在附录中的 fork 标签数为 349，小于正文的 fork 总数 366。

说明：ROCm/legacy-rocm-build 是旧 ROCm/ROCm 主页仓库的归档名；今天 ROCm 的入口是 ROCm/TheRock。表中的 — 表示 GitHub 仓库未填写简介，这类仓库多为内部工具、第三方库镜像或历史占位仓库。

11.1 九个主组织