ROCm Stack Atlas

The compute units, memory and interconnect that everything above exists to reach. The GPU's gfx target ID is the fact the whole stack keys off. 计算单元、显存与互连 —— 上面所有层的存在都是为了到达这里。GPU 的 gfx 目标编号是整个栈的关键标识。

A binary built for gfx942 will not run on gfx1100. Run rocminfo first — the target name it prints is what you pass to --offload-arch. 为 gfx942 编译的二进制不能跑在 gfx1100 上。先运行 rocminfo，它打印的目标名就是你要传给 --offload-arch 的值。

The only code in the stack that runs in kernel space. It enumerates the device, owns GPU page tables, creates hardware queues, and hands your process a doorbell it can write to directly. 整个栈中唯一运行在内核态的部分：枚举设备、管理 GPU 页表、创建硬件队列，并把一个 doorbell 交给你的进程直接写。

libhsakmt is the wrapper that turns ROCr calls into /dev/kfd ioctls. It lives inside the ROCR-Runtime repository now, not as a separate project. libhsakmt 负责把 ROCr 的调用翻译成 /dev/kfd 的 ioctl。它现在已并入 ROCR-Runtime 仓库，不再是独立项目。

AMD's implementation of the HSA runtime specification, and the lowest portable API in the stack. It exposes queue, agent and signal primitives; HIP/CLR uses them to publish an AQL packet into a queue the GPU reads on its own. AMD 对 HSA 运行时规范的实现，也是栈里最低的可移植 API。它提供队列、agent 与 signal 原语；HIP／CLR 利用这些原语把 AQL 包发布到 GPU 会自行读取的队列中。

"Architected dispatch" is the whole point: the packet format is hardware-defined, so the GPU command processor consumes it without the driver being involved. "Architected dispatch"（架构化派发）是核心思想：包格式由硬件定义，GPU 命令处理器可直接消费，无需驱动参与。

Tuned kernels for the operations you would otherwise write badly: GEMM, convolution, FFT, sparse, reductions, collectives. Reaching for these instead of a hand kernel is usually the single biggest perf decision. 为那些你自己写往往写不好的运算提供调优 kernel：GEMM、卷积、FFT、稀疏、归约、集合通信。用库而非手写 kernel，通常是性能上最重要的一个决定。

The naming rule: roc* is the AMD-native implementation; hip* is a thin portable wrapper that dispatches to roc* on AMD and to the cuBLAS-family on NVIDIA. Write against hip* if the code must travel. 命名规则：roc* 是 AMD 原生实现；hip* 是可移植薄封装，在 AMD 上转发到 roc*，在 NVIDIA 上转发到 cuBLAS 系列。代码要跨平台就用 hip*。

One source file, two compilations: host code for x86-64 and device code for every gfx target you asked for, bundled into a single fat binary the runtime unpacks at load time. 一份源码，两次编译：主机端编到 x86-64，设备端为你指定的每个 gfx 目标各编一份，再打包进同一个 fat binary，由运行时在加载时取出。

If you want to see what the GPU actually executes, this is the layer: llvm-objdump --disassemble on the extracted code object gives you real ISA, not IR. 想看 GPU 究竟执行了什么，就从这一层入手：对取出的 code object 执行 llvm-objdump --disassemble，得到的是真实 ISA 而非中间表示。

Frameworks that depend on layers 4–6 for execution, optimized kernels and build/JIT support. Because the HIP back end keeps the CUDA-shaped API, model code usually runs unchanged — torch.cuda still works, and still means "the AMD GPU". 这些框架依赖第 4–6 层提供执行、调优 kernel 与编译／JIT 支持。由于 HIP 后端保持了与 CUDA 同形的 API，模型代码通常无需改动 —— torch.cuda 依然可用，指的就是那块 AMD GPU。

TensorFlow was long supported but no longer appears in AMD's validated compatibility matrix — treat PyTorch, JAX and the inference servers as the maintained paths. TensorFlow 曾长期受支持，但已不在 AMD 官方验证的兼容性矩阵中 —— 应把 PyTorch、JAX 与推理服务栈视为当前维护的主路径。

Not a layer you sit on — a layer you look through. These are how you find out what the other eight are doing, from a single kernel's occupancy up to fabric traffic between eight GPUs. 这不是你"站在上面"的一层，而是你"透过它去看"的一层：从单个 kernel 的占用率，到八卡之间的互连流量，都靠它们观测。

Start with rocprofv3 for a kernel trace, then move to rocprof-compute when you need roofline and per-CU counters. Omniperf and Omnitrace were renamed in ROCm 6.3 — old tutorials still use the old names. 先用 rocprofv3 抓 kernel trace，需要 roofline 与 CU 级计数器时再上 rocprof-compute。Omniperf 与 Omnitrace 已在 ROCm 6.3 改名，旧教程里仍是旧名字。

The workloads the stack was built to carry — and the deployments that prove it carries them at scale. 整个软件栈存在的理由，以及证明它确实能撑起规模的真实部署。