打开/lib/modules/$(uname -r)/kernel/drivers/gpu/drm/amd/看一圈，你会发现里面躺着一个叫amdgpu.ko的大块头，旁边还跟着一堆amdgpu_*.ko模块——很多人就是在这里开始懵的：占地方不小，却不知道该从哪里读起。这篇文章不打算带你逐行读代码，而是把这套驱动当成一个系统来拆，让你先有一个完整的架构地图，之后再深入研究时，能够很清楚地知道“我现在看的是哪一层、它跟其他部分怎么配合、出问题该去哪里找线索”。

我默认你有一定的 Linux 内核驱动基础，至少知道字符设备、file_operations 和 ioctl 是怎么回事。如果没有也没关系，这套驱动本身就是很好的学习素材，你会看到 Linux 图形子系统是怎么在抽象层上长出一套完整 GPU 驱动的。整篇文章的核心目标只有一个：建立 AMDGPU 驱动的整体观。看懂了这一层，后面你再读任何一篇关于它的源码解析文章，都不至于迷路。

1. 为什么说AMDGPU驱动是“一台跑在GPU上的操作系统”

1.1 三层结构：用户态、内核态、固件

现代 GPU 驱动的复杂度远超普通外设驱动。一块普通的 PCIe 网卡，驱动做的事是初始化、收发包、处理中断，逻辑上是线性的；但一块 GPU 要同时处理 3D 渲染、视频编解码、显示扫描输出、多进程上下文切换、显存申请/回收、电源调度，甚至还要承担 AI 算力任务。想让这种东西高效稳定地工作，只靠一个内核模块在回调里填寄存器是不够的，它必须像操作系统一样分层经营。

AMDGPU 驱动的三层结构是最容易理解它的切入点。最上层是用户态图形栈，常见的是 Mesa 面里的radeonsi（OpenGL）和radv（Vulkan），配合libdrm_amdgpu这个库来访问内核接口。用户态的作用是把图形 API 的标准调用翻译成 GPU 能理解的命令流，但它不能直接碰硬件寄存器，必须通过内核。中间层是内核态，也就是 DRM 框架下的amdgpu模块本体，它承担资源分配、命令验证、上下文调度、显存管理、显示模式设置这些核心职责。最底层是 GPU 固件，它跑在 GPU 内部的安全处理器和各个引擎的微控制器上，负责电源管理、启动握手、中断处理等底层事项。

这三层之间的协作关系，很像一个软件公司的三层架构：用户态是提需求的产品经理，它决定“我要画一个三角形、清屏、换缓冲区”；内核态是开发经理，负责协调资源、防冲突、控制预算；固件是具体干活的工程师，真正驱动硬件运转。理解了这个类比，后面看代码的时候，你会更容易判断某个功能应该在哪一层实现。比如用户态想要三角型效果，它不会去写内核代码，而是通过标准 ioctl 申请资源、提交命令，剩下的脏活累活由内核态和固件解决。

1.2 DRM框架与amdgpu的角色分工

DRM，Direct Rendering Manager，这个名字很容易让人误以为它只管显示，实际上它是 Linux 内核里一堆 GPU 驱动共同依赖的基础设施。amdgpu并不是独立于 DRM 之外的驱动，它本质上是 DRM 框架的一个具体实现，注册进 DRM 子系统，然后被框架管理。早期内核里 GPU 驱动各家写法不一，有的用 fbdev 框架，有的自己造轮子，导致用户态图形栈每适配一个新驱动都要写一套接口。DRM 存在的意义，是定义一套统一的中介协议：统一设备节点 /dev/dri/card0，统一 ioctl 号段，统一 GEM/TTM 对象管理模型，统一 KMS 显示配置接口，这样用户态程序只需与 DRM 打交道，而不用关心底层具体是谁在执行。

AMDGPU 在 DRM 框架中的角色，相当于一个提供具体执行能力的“供应商”。DRM 框架管流程、管文件生命周期、管对象追踪，但一涉及 GPU 独有的操作，例如提交一个命令缓冲区、分配一块显存并做 GPA 映射，框架会把控制权交给 amdgpu 自己的回调函数。代码里你会频繁看到drm_xx_ioctl这样的入口函数，它们负责检查参数、分配临时结构，然后调用amdgpu_xx_ioctl完成实际工作。这个两层设计大幅减少了驱动与用户态之间的耦合，也是现代 Linux GPU 驱动能统一桌面的原因。

DRM 框架还提供了一个重要能力：KMS，Kernel Mode Setting。在内核里完成显示模式设置，而不是像老式驱动那样让用户态直接操作显示控制器寄存器。这带来的直接好处是多显示器、热插拔、DPMS 电源管理可以统一管理，即使 Xorg 或 Wayland 崩溃，屏幕也不会立刻黑掉。amdgpu对 KMS 的实现集中在显示引擎部分，后面讲 DCN 时会进一步展开。

1.3 一套驱动覆盖多代架构：GCN到RDNA

如果你看过内核早期代码，会发现在amdgpu加入之前，内核里已经有一个比较成熟的radeon驱动，它支持较早期的 GPU 核心架构。后来出现了 GCN 架构，改幅度很大，但在它基础上继续演进 RDNA 等后续架构却保持了相当强的延续性，于是负责维护的开发者们决定：与其在老驱动里补丁摞补丁，不如重构一个新驱动，面向新架构做全套适配。于是amdgpu诞生，并且通过一个技术上的妥协同时接管了新旧两代产品：amdgpu模块可以配合少量兼容参数，也承接原本属于radeon的一部分老设备支持，而radeon驱动则逐渐进入维护模式。

这种“一个驱动覆盖多代架构”的决策，对用户来说是方便，对开发角度来说是挑战。因为不同代 GPU 的寄存器布局、固件接口、引擎行为有细微差异，驱动内部必须做好分层抽象，弱化这些差异。AMDGPU 驱动解决的方案就是“IP Block 抽象”，把 GPU 拆成若干独立模块，而不是一个大一统的设备。于是同一个驱动二进制，既可以跑在若干年前的 GCN 显卡上，也能支持最新的 RDNA 架构，区别只是 IP block 的组合不同、版本号不同、初始化参数不同。这个设计思想在 PC 领域很成熟，也就是“平台化、模块化设计”。理解这一层，你才能解释为什么一个驱动要维护那么多种初始化序列，为什么某些型号没有某项功能，为什么代码里到处是chip和一个又一个版本判断宏。

这些历史包袱不是负担，恰恰是 AMDGPU 驱动最有意思的地方：它是一套面向未来的框架，同时收编了过去的硬件。如果你看到哪段代码打开一个分支判断老架构怎么做、新架构怎么做，不要觉得冗余，那就是兼容性设计的代价与智慧。

2. 读懂AMDGPU内核模块的架构地图

2.1 模块加载与设备探针：一切从pci_driver开始

内核里所有 PCI 设备驱动的起点都是struct pci_driver。AMDGPU 驱动的入口在amdgpu_drv.c，那里定义了一长串id_table，通过匹配设备的 PCI vendor ID 和 device ID 来决定这个设备是否由它接管。当你的显卡被系统识别、模块被加载，PCI 核心会调用驱动的probe回调，真正的初始化流程从这里展开。

probe做的事情远比看上去多。先是要创建一个struct drm_device，申请设备号、建立字符设备节点；然后映射 GPU 的 PCI BAR 空间，让 CPU 可以访问 GPU 的寄存器；紧接着解析显卡的 VBIOS，从中读取设备信息、显示输出接口定义、电源管理策略；再往下就是对 GPU 内部 IP 模块进行“摸底”的操作：通过寄存器读取硬编码的 IP 版本号，弄清这颗 GPU 上到底有哪些模块、它们的版本分别是什么。如果这一步成功完成，驱动就能构建出一张“这张卡能力地图”，后续初始化各引擎时就知道该加载哪些固件、该跳到哪个初始化分支。

不少驱动加载失败的问题就出在这个阶段。比如probe时 BAR 空间申请失败、VBIOS 读取异常、IP 模块版本不识别，都会导致驱动拒绝接管设备。你在dmesg里看到类似amdgpu: failed to initialize的报错时，不要盲目觉得是固件问题，先看完整日志里的上下文。记住一个原则：probe里报错的位置越是靠前，越说明是设备识别、资源申请层面的问题；越靠后，越可能是特定 IP 模块初始化失败。这个定位逻辑可以帮你快速缩小排查范围。

2.2 IP Block：AMDGPU驱动里的“乐高积木”

“IP Block”是理解 AMDGPU 驱动内部组织方式的钥匙。所谓 IP（Intellectual Property）模块，指的是 GPU 内部不同功能的硬件区块：图形引擎、显示引擎、视频编解码器、电源管理微控制器、安全处理器、DMA 引擎等等。AMDGPU 驱动把这些区块抽象成一个个结构体，每个结构体里放着一组操作函数指针，包括初始化、时钟门控、挂起、恢复、断电等。驱动启动时，会按一个预定义的顺序依次执行各个 IP block 的操作，这个顺序数组具体定义了模块间的依赖关系：比如要先初始化内存控制器，才能让后续模块正常分配显存；要先启动安全处理器，才能加载其他固件。

下面是驱动里常见 IP Block 与其职责的对应表：

初看这张表不要全背，重点是建立一种认知：GPU 不是一个整体，而是多个引擎的组合。实际工作中，你遇到“视频播放花屏”大概率是 VCN 的问题，“显示器点不亮”大概率是 DCN 的问题，“跑分太低”可能要去看 SMU 和 GFX 的频率。这种按模块定位的思路，会让你在查问题时快非常多。

代码里你还会看到类似adev->ip_blocks这样的数组，它每个元素都包含一个struct amdgpu_ip_block结构，里面注册了该模块的回调函数。整个驱动的启动过程，基本就是遍历这个数组，依次执行初始化、恢复、挂起等操作。所以新架构支持起来，往往只需在数组里加一个新的 IP block 条目，而不是大刀阔斧改整个框架。这就是“乐高积木”模式的威力。

2.3 三大核心机制：TTM显存管理、AMDGPU Scheduler、DCN显示

TTM 全称 Translation Table Maps，它不只是 AMDGPU 在用，DRM 框架里也有一个通用的 TTM 实现被多个驱动共享。它的任务是管理 GPU 的全部内存对象：显存（VRAM）、系统内存映射区（GTT）、以及临时借用系统内存的“溢出区”。如果你是做图形或者计算开发的，应该已经体会过显存不够用时性能骤降的痛，这就是 TTM 在做交换和迁移。TTM 会在显存紧张时，把暂时不用的对象换到系统内存里，并用页表重新映射，让 GPU 看起来仍然拥有完整地址空间。这个过程很像操作系统里的虚拟内存换页，只不过换页的“磁盘”变成了系统内存，效率高很多。

AMDGPU Scheduler 则是驱动私有的任务调度器。用户态程序提交的命令并不是直接塞进硬件队列就完事，而是先进入调度器的队列，由调度器根据优先级和依赖关系决定何时派发到硬件 ring。这个设计能防止一个疯狂的进程把整块 GPU 拖垮，也为 GPU reset 提供了可控的挂起点。调度器内部维护一个 job 链表、一个 pending 计数器和一个超时定时器。当某个 job 超过设定时间没有完成，调度器就会触发超时处理流程，也就是我们常说的 GPU reset。现在很多卡在渲染时崩溃又自动恢复，背后就是这套机制在工作。

DCN，Display Core Next，是显示控制部分的软件框架。它负责把显存里的帧缓冲通过显示引擎扫描输出到显示器，同时管理显示输出接口、时序、色彩空间转换、HDR 元数据等。DCN 在驱动里对应amdgpu_dm这个 Display Manager，它实现了 DRM 的 KMS 接口。你调节分辨率、接扩展坞、打开 HDR，内核里就是这个模块在响应。DCN 是相对独立的一块，有时候显卡渲染完全正常但显示器黑屏，问题很可能出在这里，需要单独看 DCN 相关的初始化日志。

3. 用一条IOCTL链路串起整个驱动

3.1 GEM对象创建：从用户态请求到显存分配

与其对着架构图凭空想象，不如跟着一次真实的用户态调用走一遍代码路径。这里我选一个最简单的操作：创建一个 GEM 对象，也就是用户态向内核申请一块 GPU 可访问的内存。在 Mesa 里，应用分配一个纹理或顶点缓冲，最终会走到libdrm的amdgpu_bo_create，然后通过 ioctl 把请求送进内核。

对应内核侧入口是amdgpu_gem_create_ioctl。它会先从用户态拷贝参数，包含 size、alignment、domain 和 flag。domain 是一个关键参数，它决定这块内存优先放在哪里：VRAM、GTT，还是系统内存。因为 GPU 访问 VRAM 的带宽远高于 GTT，所以游戏纹理通常优先 VRAM；而 CPU 频繁读写的缓冲则更倾向 GTT，减少 PCIe 拷贝开销。这个决策本质上是一个性能与容量之间的平衡，驱动并不懂你的业务，全靠用户在调用时给对参数。

接下来函数会调用amdgpu_bo_create，这里面发生的事非常有意思。它先根据 size 和 alignment 计算实际需要的内存大小，然后用 TTM 的接口进行内存对象初始化和预留。内存分配成功后还要创建 GEM 对象、关联dma_buf（如果这个缓冲需要和别的设备共享）、生成一个用户句柄返回给调用方。整个过程不涉及任何硬件寄存器操作，只是软件层面的记账和内存管理，所以速度很快。如果一个分配操作变得很慢，通常不是分配本身慢，而是触发了 TTM 换页或者碎片整理——这也是为什么优化图形应用时要注意显存资源的使用节奏。

沿着这个例子，你大概能明白一个基本事实：用户态一个简单接口调用，内核侧可能涉及 DRM 对象管理、内存分配、TTM 页表映射、文件描述符生命周期等多个子系统。之后我们再叠加显示和命令提交，整个驱动就真的“活”起来了。

3.2 命令提交：execbuffer、调度器与ring的配合

真正体现 AMDGPU 驱动核心价值的路径，是命令提交。一个 3D 应用要画一帧，用户态驱动会生成一系列硬件命令，把它们放到一块命令缓冲区（IB，Indirect Buffer）里，然后调用amdgpu_cs_ioctl（command submission）把它提交给内核。这个 ioctl 可以说是全驱动最繁忙的入口，Mesa 每个 draw call 的背后都会走一遍。

amdgpu_cs_ioctl的内部流程是一个精心设计的流水线。第一步是 parser 验证，检查命令缓冲区内容是否合法、引用的资源是否已经创建、内存访问是否符合预期。这一步之所以重要，是因为 GPU 驱动作为多进程共享的系统服务，必须防止恶意或错误的用户态程序让 GPU 去访问不属于它的内存。

验证通过后，驱动把这次提交包装成一个 job，进入 AMDGPU Scheduler 的队列。调度器是一个真正的 CPU 侧调度实体，它可能通过一个内核线程来执行派发逻辑。当 CPU 资源允许、依赖的同步对象都满足条件时，调度器把 job 写到目标的硬件 ring 上。ring 是一段 GPU 和 CPU 共享的环形缓冲区，驱动往里面写入命令包，GPU 的特定引擎（比如 GFX 引擎）会异步地读取并执行。这个模式是一种经典的生产者-消费者模型，硬件侧有一个读指针，软件侧有一个写指针，两者通过寄存器同步。你可以把 ring 想象成食堂的取餐台：驱动把订单放上去，GPU 厨师照着单子做菜，做完就把单子撕掉。

提交完成后，驱动会返回一个 fence，一个同步对象。用户态可以阻塞等待 fence 被 GPU 执行完成。这套机制与调度器配合，实现了 CPU 与 GPU 的异步并行计算。如果 CPU 一直将命令送入队列而 GPU 跟不上，调度器队列就会堆积，最终表现为高占用但低帧率，这种场景经常出现在 CPU 瓶颈的游戏中。

3.3 初始化路径：从sw_init到hw_init再到GPU reset

AMDGPU 驱动的启动初始化过程，也有两条清晰路径值得记住。第一条路径是软件路径，叫sw_init。它负责创建驱动需要的软件数据结构：各种锁、队列、内存对象、fence、调试节点。这个阶段不操作硬件，即使出错也不会破坏硬件状态，安全系数高。第二条路径是硬件路径，叫hw_init。它按顺序做真正的硬件操作：加载各类固件、配置内存控制器、启动图形引擎、显示引擎、初始化时钟和电源管理。hw_init一旦出错，GPU 可能处于部分初始化的状态，需要驱动做清理或重置。

在整个生命周期里，hw_init的错误有两种常见表现。第一种是驱动 probe 阶段直接失败，设备不可用，通常在 dmesg 中能看到具体的 IP block 名称和错误码；第二种是设备已经用了一段时间，运行中出了问题，这时会触发 reset 路径。无论哪种，AMDGPU 驱动都会走一个类似的恢复流程：暂停调度器接收新 job，等待正在执行的 job 超时或强制停止，然后执行相关 IP block 的软复位，必要时重新加载固件，最后恢复调度器并通知用户态发生了一次 GPU reset。你如果在内核日志里看到amdgpu: GPU reset begin、amdgpu: GPU reset successful这样的行文，说明驱动正在尝试自救。

这个 reset 流程对一个需要稳定运行的桌面系统来说极其重要。早期驱动没有这个能力时，GPU 一 hang，整个系统就只能重启。现代驱动加上了 reset 和恢复机制，大大提升了稳定性。但 reset 本身也是一个信号：如果某个应用频繁触发 GPU reset，说明有问题潜伏，不能只当驱动在“自动修理”就忽视它。后面第 4 章我会专门讲排查这类问题的经验。

4. 驱动问题排查实录与避坑技巧

4.1 经典症状速查表

AMDGPU 驱动的问题表现方式非常多样，但绝大多数都能从“哪个 IP block 出错”这个角度做初步定位。我根据自己的经验整理了一张高频问题速查表，尽量帮你从“黑屏”这种模糊现象，快速锁定到具体方向。

这张表不能替代完整日志分析，但能帮你迅速选择一个排查方向。拿到一个问题，建议先花两分钟收集dmesg、journalctl -k、以及对应时间段的图形应用日志，再对照表格去思考原因。多数问题其实都有比较规律的日志特征，盲目换驱动、换系统往往浪费时间。

4.2 固件与参数导致的问题怎么处理

AMDGPU 驱动依赖的固件存放在/lib/firmware/amdgpu/目录，里面每个固件文件对应一个 GPU 型号的某个 IP block。新显卡刚发布时，如果发行版自带的 firmware 包太旧，就会导致该型号无法识别、显示异常或视频功能缺失。这个问题的典型特征是：新装的系统能启动但画面分辨率和刷新率异常，或者直接黑屏，而去更新固件包后问题就消失。

固件缺失导致的报错往往带有很强的“模块感”。比如 dmesg 里出现amdgpu: failed to load ... firmware字样，说明加载某个 IP block 的固件失败，这个模块可能就无法正常使用。不要想着通过改内核参数绕过固件校验，正确的做法是更新 firmware 包，确认文件存在并且版本与驱动匹配。

内核参数方面，AMDGPU 提供了不少开关，最常被提到的有amdgpu.gpu_recovery=、amdgpu.dc=、amdgpu.si_support=、amdgpu.cik_support=。这些参数的作用通常是在特定硬件或特定场景下做兼容性调整。比如gpu_recovery控制是否允许驱动在 GPU hang 后自动重置，一些老环境担心重置不稳定可以设为 0，但现代系统中我建议保持默认开启，因为自动重置成功率不低，而且能减少需要重启的次数。si_support和cik_support主要用于让 amdgpu 接管一些老架构设备，默认关闭，不是特殊需求不要乱开。

调整参数的原则是：一次只改一个变量，修改后重新加载驱动或重启，观察日志变化。如果同时改了好几个参数，问题解决了你却不知道是哪个起的效果，问题没解决也不知道是哪个造成的新问题。另外，优先在 GRUB 配置里通过内核命令行设置，而不是在运行时写入/sys/module/...参数，这样每次启动行为一致，容易复现和对比。

4.3 Scheduler超时、GPU reset与显存泄漏排查经验

在 AMDGPU 驱动开发与调试里，ring gfx timeout大概是出镜率最高的日志关键词。它背后的流程是：调度器把一个 job 派发到 GFX ring 后，它预期在一定时间内被 GPU 完成，但计时到期时 GPU 没有更新 fence，于是判定引擎卡死，触发 reset。这个超时并不总意味着硬件坏了，更多时候是用户态程序提交了非法或者无法完成的命令，导致 GPU 引擎停在那里等一个永远满足不了的条件。

我遇到过一种典型场景：一个图形应用运行一段时间后必现崩溃，日志显示 GFX ring timeout。深入排查后发现，应用在每一帧都提交了一个超大型命令缓冲区，里面包含大量状态切换和纹理上传，把 ring 几乎占满，而调度器的超时阈值没有考虑到这种极端情况，稍微的调度抖动就导致超时误报。定位的方法是观察调度的队列深度：如果 job 堆积过多，即便硬件没有真正卡死，也可能触发超时。这时候调整应用让命令分帧提交，或者适当拉长超时阈值，问题都能缓解。

显存泄漏是另一个高频问题。用户态程序不断创建缓冲对象但忘记释放，内核侧的 GEM 对象数量只增不减，TTM 总显存占用持续上升，最终表现为运行越来越卡，直到触发 OOM。排查手段很朴素：读取/sys/class/drm/card0/device/mem_info_vram_used这类 sysfs 属性，观察显存占用是否随时间线性增长。如果确定在增长，再用perf或者调试工具确认是哪类进程在申请显存对象。这类问题的难点不在定位工具，而在于应用程序的开发流程里常常没有显存生命周期检查机制，很多泄漏在代码评审阶段发现不了，只能靠长时间的监控暴露出来。

我的个人习惯是：遇到任何讲不清的 AMDGPU 驱动问题，第一步永远是完整抓取dmesg和journalctl，然后根据关键词切分日志时间线，确定第一次报错发生在什么阶段。很多看似复杂的问题，其实答案就藏在报错行前一秒的固件加载记录或者中断上报记录里。

5. 影响范围与学习建议

5.1 从桌面到算力：AMDGPU驱动决定了很多事情的起点

AMDGPU 驱动的影响力远超“一块显卡能用”这么简单。它决定了桌面环境的流畅度、视频播放的功耗、3D 游戏的兼容性，还决定了一台工作站能不能正常跑 AI 推理、科学计算等通用计算任务。许多面向图形或者计算的软件栈，底层都在与这套驱动打交道，只是中间隔着一层又一层的库，普通用户看不到罢了。

对于运维和系统管理员来说，理解 AMDGPU 驱动架构意味着能更准确判断故障边界。屏幕点不亮不一定是硬件损坏，也许是 DCN 固件没匹配；计算任务突然报错不再仅仅是业务代码 bug，也可能是 KFD 初始化序列出了问题。当你能够在诡异的问题面前快速判断是哪一个 IP 模块、哪一层接口出了问题，你的排查效率会有一个质的提升。

对于上层图形开发者，明白驱动的调度和显存管理机制也很有帮助。为什么某些应用需要创建多个缓冲区交替使用？为什么频繁分配和释放显存会让性能下降？为什么命令提交的方式会影响帧延迟？这些问题如果只停留在 API 层面，你可能永远找不到答案。而理解了底层驱动架构，再回头去看 Vulkan 里 swapchain 和同步机制的代码，很多当初觉得抽象的设计会变得理所当然。

5.2 想入门驱动开发的阅读路径建议

如果你也想深入 AMDGPU 驱动源码，我建议不要尝试从头到尾线性阅读。那几万行代码一天是看不完的，而且大多数内容属于状态迁移和边界处理，读起来效率极低。更好的方式是“以点带面”：挑一条最短的主干路径，从一个用户态 ioctl 出发，一直追到硬件操作，中途遇到什么知识点就展开什么知识点，读完一条链路，整个驱动的骨架也就基本掌握了。

推荐的第一步是熟悉amdgpu_drv.c里的pci_driver注册和id_table，理解设备是怎么被识别的。然后跟着amdgpu_device_init走一遍，你会看到 IP block 数组的顺序，理解模块化初始化的全貌。接着选一条最简单的路径，比如 GEM 创建对象，从 ioctl 一路看到 TTM 的分配函数，这样你对驱动的软件资源管理体系就有了具象认识。最后必须看的就是amdgpu_cs_ioctl这条命令提交链路，它是整个驱动最繁忙的交通要道，看懂它，你的架构地图就基本成型了。

如果需要实际调试，可以用ftrace观察关键函数调用顺序，用drm.debug查看内核调试日志，比起加一堆 printk 要高效得多。确认自己感兴趣的方向后，再针对性地阅读 GFX 调度、TTM 缓存策略、DCN 时序计算等专项模块。这样走到后面，你会发现自己已经能回答很多别人回答不了的问题，并且真正理解了驱动、硬件和应用三者之间是如何被紧密编织在一起的。

我个人在实际操作中的体会是，别小看“概览”两个字。很多源码干了几年的人，照样会在一次诡异的 GPU 问题面前手忙脚乱，原因不是代码不熟，而是心中没有那幅“地图”。先把地图画好，把路线标记清楚，再根据问题去局部深挖，这比从头到尾硬啃代码高效得多。希望这篇 AMDGPU 驱动架构概览，能成为你第一步的地图。