企业官网建设流程全解析

ROCm 系统优化指南：基于 legacy-rocm-build 的 AMD Instinct、Radeon 与通用系统调优实践

【免费下载链接】legacy-rocm-buildAMD ROCm™ Software - GitHub Home项目地址: https://gitcode.com/GitHub_Trending/ro/legacy-rocm-build

本指南系统讲解 AMD GPU 平台面向 HPC 与工作站负载的整机级设置与调优建议，内容按硬件架构组织：AMD Instinct（CDNA）、AMD Radeon/Ryzen（RDNA）以及跨硬件通用的系统设置。读完本文，你将掌握基于环境变量、容器与虚拟化的 GPU 隔离方法，理解 BAR 物理寻址限制与 P2P 配置要点，能够完成 RDNA3.5 APU 的共享内存（GART/GTT/TTM）调优，并可在 RDNA2 平台上搭建 SR-IOV 虚拟化环境。

指南总览：按硬件划分的优化路径

本仓库中该指南的入口文档位于 docs/reference/system-optimization/index.rst，它将全部优化内容划分为三大板块：

此外，rdna.rst 与 common.rst 分别作为 Radeon/Ryzen 与通用设置的子索引，归纳各自下辖主题。以下按这三个板块逐层展开。

AMD Instinct（CDNA）系统优化

Instinct 板块的优化指南以远程内容（remote-content）的方式聚合自 ROCm 的 amdgpu-docs 项目，详见 cdna.rst 中的.. remote-content::指令，覆盖每一代 Instinct 数据中心 GPU，包括 MI355X、MI350X、MI325X、MI300X、MI300A、MI250/MI250X、MI210 与 MI100。

这些 GPU 属于 CDNA 架构，采用独立的 HBM 显存池与专用计算单元，系统优化重心通常是 PCIe P2P 访问、多卡拓扑与显存 BAR 配置（后者正是下文"通用系统设置"中 BAR 一节的核心场景）。若需深入了解各代 Instinct 的硬件架构细节，可直接阅读本仓库 docs/reference/gpu-arch 目录下的对应文档：

• mi350.rst（MI350 系列）与 mi350-performance-counters.rst；
• mi300.md（MI300 系列）与 mi300-mi200-performance-counters.rst；
• mi250.md（MI200 系列）与 mi100.md（MI100）。

AMD Radeon 与 Ryzen（RDNA）系统优化

RDNA3.5：Ryzen APU 的共享内存调优（gfx1150 / gfx1151 / gfx1152）

RDNA3.5 架构的 AMD Ryzen APU 将高性能 CPU 核心与集成显卡结合，支持 LPDDR5X-8000 或 DDR5 内存，特别适合 LLM 开发与推理系统、高性能工作站、承载多个 VM 的虚拟化宿主、GPU 计算与并行处理、游戏系统以及家庭服务器 / AI 开发平台。本节内容源于 rdna3-5.rst。

GPUVM 内存模型：GART 与 GTT 的本质

RDNA3.5 APU（LLVM 目标为 gfx1150、gfx1151、gfx1152）通过 GPU Virtual Memory（GPUVM）处理内存访问，为每个进程提供独立的 GPU 虚拟地址空间（VMID），而非一块独立的显存池。因此，这类 APU 上的内存是"映射"而非"物理划分"的。Graphics Address Remapping Table（GART）与 Graphics Translation Table（GTT）描述的是系统内存可以被映射进 GPU 地址空间的上限、以及由谁使用，而不是两种不同类型的物理内存：

• GART：定义可被映射进内核驱动所用 GPU 虚拟地址空间的平台地址空间（系统 RAM 或 MMIO）大小。在 CPU 与 GPU 物理共享内存的系统中，这部分映射内存实际充当 GPU 的显存。GART 通常保持较小，以限制 GPU 页表规模，主要用于驱动内部操作。
• GTT：定义可被映射进用户进程 GPU 虚拟地址空间的系统 RAM 大小，即 PyTorch 等 AI/计算负载使用的内存池。GTT 分配是动态的、不永久保留，GPU 不使用时操作系统可以回收。默认 GTT 上限约为系统总内存的 50%。

术语说明：在物理共享内存的平台上，固件菜单、文档与社区讨论中经常混用 VRAM、Carve-out、GART、Dedicated GPU memory、Firmware-reserved GPU memory 等词。本文沿用原文约定，统一以 VRAM 指代这部分共享内存。

调整 GPU 可用内存的方式

可以通过两种方式调整 GPU 可用的内存量：

1. 在 BIOS 中增大 VRAM（UMA Frame Buffer）预留；
2. 将配置的GTT 上限调小到小于预留量。

若 GTT 上限大于 VRAM，AMD GPU 驱动会采用 GTT 背书的分配方式（GTT-backed allocations）执行显存分配（对应内核提交 759e764）。由于内存物理共享，这里不存在独立显卡那种"专用显存远快于系统内存"的性能差异；固件虽然也可以预留一部分内存仅供 GPU 专用，但对大多数负载收益甚微，反而会永久性地减少可用系统内存。因此，AI 框架在统一内存架构下配合 GTT-backed 分配工作更高效——GTT 支持大规模、灵活的映射而不必永久预留内存，整体系统利用率更高。

在 Linux 上配置共享内存上限（TTM pages_limit）

可通过修改内核Translation Table Manager（TTM）页上限来增大共享 GPU 可访问内存的最大值。该设置控制可映射供 GPU 使用的系统内存页数，暴露在：

/sys/module/ttm/parameters/pages_limit

注意该值的单位是页（pages），而非字节或 GB。官方建议将 BIOS 中的专用 VRAM 预留保持较小（例如 0.5 GB），转而增大共享（TTM/GTT）上限。

仓库提供了一套辅助工具amd-ttm简化配置，其完整操作流程如下：

1. 安装pipx：

   sudo apt install pipx pipx ensurepath

2. 安装 AMD 调试工具集：

   pipx install amd-debug-tools

3. 查询当前共享内存配置：

   amd-ttm

4. 设置可用共享内存（单位为 GB）：

   amd-ttm --set <NUM>

5. 重启使更改生效。

amd-ttm会自动完成页数与 GB 之间的换算。以下为文档中的完整示例输出。

查看当前设置：

amd-ttm 💻 Current TTM pages limit: 16469033 pages (62.82 GB) 💻 Total system memory: 125.65 GB

修改可用共享内存：

❯ amd-ttm --set 100 🐧 Successfully set TTM pages limit to 26214400 pages (100.00 GB) 🐧 Configuration written to /etc/modprobe.d/ttm.conf ○ NOTE: You need to reboot for changes to take effect. Would you like to reboot the system now? (y/n): y

恢复内核默认值：

❯ amd-ttm --clear 🐧 Configuration /etc/modprobe.d/ttm.conf removed Would you like to reboot the system now? (y/n): y

操作系统支持与必需内核版本

ROCm 整体操作系统要求可参见仓库的 os-support-table.md 与 core-sdk-components-linux.rst。而 AMD Ryzen AI Max 系列 APU（gfx1151）有额外的内核版本要求：其支持依赖于修正 AMD KFD 驱动内部限制的内核补丁，这些补丁更新了队列创建与内存可用性检查的限额；缺少它们时，GPU 计算负载可能无法初始化或表现出不可预测的行为。

所需内核提交为7f26af7与7445db6，对应的最低内核版本为：

• Ubuntu 24.04 Hardware Enablement（HWE）：6.17.0-19.19~24.04.2或更高；
• Ubuntu 24.04 Original Equipment Manufacturer（OEM）：6.14.0-1018或更高；
• 其他发行版：Linux 内核6.18.4或更高。

下表仅反映 AMD 官方发布的预构建 ROCm 二进制的兼容性（发行版自带原生 ROCm 打包时支持级别可能不同），图例为 ❌ 不支持组合、⚠️ 不稳定/实验性组合、✅ 稳定且受支持组合：

需要注意：早于6.17.0-19.19~24.04.2的 Ubuntu 24.04 HWE 内核与早于6.14.0-1018的 Ubuntu 24.04 OEM 内核均不受 RDNA3.5 APU 支持。另外，以下发行版已在原生打包中包含所需修复，与 AMD 预构建二进制无关：Fedora 43、Ubuntu 26.04、Arch Linux 2026.02.01。

RDNA2：工作站负载与 SR-IOV 虚拟化

RDNA2 部分（rdna2.md）针对 Radeon PRO 系列 GPU，覆盖将其用于 Single Root I/O Virtualization（SR-IOV）与机器学习任务所需的软件要求与流程。工作站负载与 HPC 类似，有图形与计算混合、认证、稳定性等独特要求。需要特别注意的是：SR-IOV 在 V620 上受支持，在 W6800 上不受支持。

BIOS 设置：开启虚拟化基础能力

要在 V620 上启用 ROCm 虚拟化，需先在 BIOS 中配置 SR-IOV 及相关特性。下表为文档给出的推荐设置（SBIOS 需更新到 1.2a 版本）：

操作系统设置：一套已验证的参考配置

文档给出了一套经测试的主机/客户机配置组合：

宿主机部署步骤

安装 KVM 虚拟化软件包：

sudo apt-get -y install qemu-kvm qemu-utils bridge-utils virt-manager gir1.2-spiceclientgtk* gir1.2-spice-client-gtk* libvirt-daemon-system dnsmasq-base sudo virsh net-start default

在 GRUB 配置（/etc/default/grub）中启用 IOMMU（AMD CPU 平台）：

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

更新 GRUB 并重启：

sudo update-grub sudo reboot

随后安装 GPU-IOV 模块（GIM，IOV 即 I/O Virtualization）驱动并加载，创建虚拟功能（VF）：

sudo dpkg -i <gim_driver> sudo reboot # Load Host Driver to Create 1VF sudo modprobe gim vf_num=1 # Note: 若 GIM 驱动加载成功，可在 dmesg 中看到 "gim info:(gim_init:213) *****Running GIM*****" lspci -d 1002:

lspci应输出类似如下结果，其中03:02.0即为创建的 VF：

01:00.0 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] Device 1478 02:00.0 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] Device 1479 03:00.0 Display controller: Advanced Micro Devices, Inc. [AMD/ATI] Device 73a1 03:02.0 Display controller: Advanced Micro Devices, Inc. [AMD/ATI] Device 73ae → VF

客户机安装：将 VF 直通给虚拟机

将 GPU 虚拟功能（VF）分配给 VM 的步骤如下：

1. 停止 VM；
2. 运行virt-manager；
3. 在Virtual Machine Manager界面中选择目标 VM 并点击Open，进入虚拟机管理主窗口（见下图）;

4. 在 VM 界面中进入Show Virtual Hardware Details > Add Hardware配置硬件；

5. 在Add Hardware > PCI Host Device中选择对应的 VF 并点击Finish。

随后启动 VM，并参照 Linux 安装指南 在客户机内安装 ROCm 即可。

通用系统设置

GPU 隔离技术

GPU 隔离（gpu-isolation.md）用于限制应用对部分 GPU 的访问，把 GPU 资源从程序中"隐藏"起来。默认情况下，程序只会使用"暴露"的 GPU，忽略系统中其余（隐藏的）GPU。ROCm 软件栈提供多种隔离方式，它们在适用范围与安全性上各有不同。

基于环境变量的隔离

ROCm 软件栈的各运行时通过读取下列环境变量来选择向应用暴露的设备，完整的变量参考见 环境变量索引。需要强调的是：环境变量不应用来隔离不受信任的应用——应用可以在初始化运行时之前重置这些变量。

ROCR_VISIBLE_DEVICES

暴露给应用的设备索引或 UUID 列表。

• 运行时：ROCm Software Runtime，适用于所有使用用户态 ROCm 软件栈的应用。

# 示例：暴露第 1 个设备，以及一个按 UUID 指定的设备 export ROCR_VISIBLE_DEVICES="0,GPU-4b2c1a9f-8d3e-6f7a-b5c9-2e4d8a1f6c3b"

GPU_DEVICE_ORDINAL

暴露给 OpenCL 与 HIP 应用的设备索引。

• 运行时：ROCm Compute Language Runtime（ROCclr），适用于使用ROCclr抽象层的应用与运行时，包括 HIP 与 OpenCL 应用。

# 示例：暴露系统中的第 1 个和第 3 个设备 export GPU_DEVICE_ORDINAL="0,2"

HIP_VISIBLE_DEVICES

暴露给 HIP 应用的设备索引。

• 运行时：HIP runtime，仅适用于在 AMD 平台上使用 HIP 的应用。

# 示例：暴露系统中的第 1 个和第 3 个设备 export HIP_VISIBLE_DEVICES="0,2"

CUDA_VISIBLE_DEVICES

为 CUDA 兼容性提供，在 AMD 平台上与HIP_VISIBLE_DEVICES效果相同。

• 运行时：HIP 或 CUDA Runtime，适用于 AMD/NVIDIA 平台上的 HIP 应用以及 CUDA 应用。

OMP_DEFAULT_DEVICE

OpenMP target offloading 使用的默认设备。

• 运行时：OpenMP Runtime，仅适用于使用 OpenMP offloading 的应用。

# 示例：将默认设备设置为第三个设备 export OMP_DEFAULT_DEVICE="2"

基于 Docker 的隔离

Docker 利用 Linux 内核命名空间为应用提供隔离环境，这种隔离默认适用于绝大多数设备（包括 GPU）。要访问 GPU，必须在容器中显式授予访问权限；如需只暴露全部 GPU 中的子集，则需进行相应限制配置。Docker 隔离比环境变量更安全，且适用于所有通过amdgpu内核模块接口访问 GPU 的程序——即使是使用 OpenGL 或 Vulkan 的图形应用（不经过 ROCm 运行时），也只能访问暴露给容器的 GPU。

GPU 直通到虚拟机

虚拟机提供最高级别的隔离，因为连虚拟机自身的内核都与宿主机隔离。物理安装在宿主机中的设备可通过 PCIe passthrough 传递给虚拟机，从而可以在客户机中运行不同操作系统（例如从 Linux 宿主机运行 Windows 客户机）。PCIe passthrough 的配置方式取决于所采用的虚拟机监控程序（hypervisor），ROCm 对部分 GPU 支持 VMware ESXi。

BAR 访问限制与物理寻址

Direct Memory Access（DMA）通过 Base Address Register（BAR）访问 PCIe 设备时，可能因物理寻址限制而受限，进而导致系统组件间的数据访问失败。Peer-to-Peer（P2P）DMA 用于在设备间访问寄存器、内存等资源；PCIe 设备需要内存映射 I/O（MMIO）空间来完成 DMA，这些 MMIO 空间就定义在 PCIe BAR 中。本节内容源于 bar-access-limits.rst。

问题根源：BAR 与物理寻址限制

BAR 是一组 32 位或 64 位寄存器，用于定义 PCIe 设备提供的资源，CPU 与其他系统设备也通过它访问 PCIe 设备的资源。P2P DMA 仅在设备 A 能直接访问设备 B 的本地 BAR 内存时才成立。一旦某个 BAR 内存的地址超过了设备的物理寻址限制，设备（无论是访问自己的 BAR 还是系统中其他设备的 BAR）都将无法访问该 BAR。因此在处理 BAR 访问问题时，必须同时了解设备的物理寻址限制与 AMD GPU 的 BAR 配置，这在为系统物理地址空间中的 PCIe 设备配置额外 MMIO 窗口时尤为重要。

处理物理寻址限制的两种途径

系统启动时，BIOS 会为系统组件（包括系统内存与 MMIO 窗口）分配物理地址空间。现代 64 位平台上通常存在两个或更多 MMIO 窗口：一个位于 4 GB 以下（供 32 位兼容使用），一个或多个位于 4 GB 以上（供需要更多空间的设备使用）。高 MMIO 窗口的内存地址可在 BIOS 配置选项中控制，将其与物理寻址限制对齐即可让设备间 P2P DMA 正常工作。例如，若某 PCIe 设备仅支持 44 位物理寻址，应确保 MMIO 窗口位于系统物理地址空间的 44 位以内。

具体有两种处理方式：

1. 确保高 MMIO 窗口位于系统中各设备物理寻址限制之内。例如设备为 44 位物理寻址限制时，在 BIOS 中将MMIO High Base与MMIO High Size配置为使窗口落在 44 位地址范围内，并确保Above 4G Decoding选项为 Enabled。
2. 启用 IOMMU。当 IOMMU 以非透传（non-passthrough）模式启用时，它会为系统中每个设备创建虚拟 I/O 地址空间，并保证该空间内的所有虚拟地址都在设备的物理寻址限制之内。

AMD GPU 的 BAR 配置

下表展示了 AMD GPU 的 BAR 配置方式：

实例：GFX8 GPU 的 BAR 配置

以 40 位物理寻址限制的 GFX8 GPU（Fiji / Radeon R9 FURY / NANO 系列）为例，系统 BIOS 设置的 BAR 布局如下（lspci输出）：

11:00.0 Display controller: Advanced Micro Devices, Inc. [AMD/ATI] Fiji [Radeon R9 FURY / NANO Series] (rev c1) Subsystem: Advanced Micro Devices, Inc. [AMD/ATI] Device 0b35 Flags: bus master, fast devsel, latency 0, IRQ 119 Memory at bf40000000 (64-bit, prefetchable) [size=256M] Memory at bf50000000 (64-bit, prefetchable) [size=2M] I/O ports at 3000 [size=256] Memory at c7400000 (32-bit, non-prefetchable) [size=256K] Expansion ROM at c7440000 [disabled] [size=128K]

各 BAR 的详细说明如下：

GPU Frame Buffer BAR：Memory at bf40000000 (64-bit, prefetchable) [size=256M]

示例中大小为 256 MB；通常该 BAR 大小为 GPU 内存大小（典型 4 GB 以上）。依据 AMD GPU 代际与物理寻址限制，该 BAR 可设置在 2^40、2^44 或 2^48 以下。

Doorbell BAR：Memory at bf50000000 (64-bit, prefetchable) [size=2M]

这一代 GPU 的该 BAR 大小通常应小于 10 MB，示例中设为 2 MB。它被放置在 2^40 以下，以允许其他代际 AMD GPU 的 peer-to-peer 访问。

I/O BAR：I/O ports at 3000 [size=256]

用于传统 VGA 与引导设备支持。由于这些 GPU 不连接显示器（非 VGA 设备），即便系统 BIOS 未配置也不受影响。

MMIO BAR：Memory at c7400000 (32-bit, non-prefetchable) [size=256K]

AMD 驱动访问配置寄存器所必需。由于该 BAR 剩余空间仅 1 个 DWORD（32 位），因此被设置在 4 GB 以下，示例中固定为 256 KB。

Expansion ROM：Expansion ROM at c7440000 [disabled] [size=128K]

AMD 驱动访问 GPU video-BIOS 所必需，示例中固定为 128 KB。

小结

本文以 system-optimization 索引 为骨架，完整覆盖了 ROCm 系统优化的三大方向：面向 Instinct CDNA 系列的数据中心级优化入口、面向 Radeon/Ryzen RDNA 系列的内存与虚拟化调优，以及跨平台的 GPU 隔离与 BAR 物理寻址配置。实际部署时，建议先依据硬件代际确认内核与 ROCm 版本兼容性（参考 版本说明），再结合负载类型（HPC、AI 推理、虚拟化）选择对应的调优手段：统一内存平台优先调整 GTT/TTM 共享上限，多 GPU 平台优先核对 BAR 布局与 P2P 可达性，多租户场景则按安全级别从环境变量、容器逐步升级到 PCIe 直通。

【免费下载链接】legacy-rocm-buildAMD ROCm™ Software - GitHub Home项目地址: https://gitcode.com/GitHub_Trending/ro/legacy-rocm-build