★ FEATURED ARTICLE 打开/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 面里的radeonsiOpenGL和radvVulkan配合libdrm_amdgpu这个库来访问内核接口。用户态的作用是把图形 API 的标准调用翻译成 GPU 能理解的命令流但它不能直接碰硬件寄存器必须通过内核。中间层是内核态也就是 DRM 框架下的amdgpu模块本体它承担资源分配、命令验证、上下文调度、显存管理、显示模式设置这些核心职责。最底层是 GPU 固件它跑在 GPU 内部的安全处理器和各个引擎的微控制器上负责电源管理、启动握手、中断处理等底层事项。这三层之间的协作关系很像一个软件公司的三层架构用户态是提需求的产品经理它决定“我要画一个三角形、清屏、换缓冲区”内核态是开发经理负责协调资源、防冲突、控制预算固件是具体干活的工程师真正驱动硬件运转。理解了这个类比后面看代码的时候你会更容易判断某个功能应该在哪一层实现。比如用户态想要三角型效果它不会去写内核代码而是通过标准 ioctl 申请资源、提交命令剩下的脏活累活由内核态和固件解决。1.2 DRM框架与amdgpu的角色分工DRMDirect 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 框架还提供了一个重要能力KMSKernel 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 BlockAMDGPU驱动里的“乐高积木”“IP Block”是理解 AMDGPU 驱动内部组织方式的钥匙。所谓 IPIntellectual Property模块指的是 GPU 内部不同功能的硬件区块图形引擎、显示引擎、视频编解码器、电源管理微控制器、安全处理器、DMA 引擎等等。AMDGPU 驱动把这些区块抽象成一个个结构体每个结构体里放着一组操作函数指针包括初始化、时钟门控、挂起、恢复、断电等。驱动启动时会按一个预定义的顺序依次执行各个 IP block 的操作这个顺序数组具体定义了模块间的依赖关系比如要先初始化内存控制器才能让后续模块正常分配显存要先启动安全处理器才能加载其他固件。下面是驱动里常见 IP Block 与其职责的对应表IP Block 名称主要职责用户可感知的体现GMC内存控制器、显存管理显存容量、带宽、GTT 映射是否正常GFX3D/ 图形引擎、Shader 核心渲染性能、游戏帧率、图形 API 功能支持SDMA系统 DMA 引擎做显存拷贝、命令搬运纹理上传、缓冲区拷贝速度DCN显示控制器、显示路径分辨率、刷新率、多屏、HDR、亮度调节PSP安全处理器、固件加载、安全启动驱动加载是否成功、加密功能是否可用SMU电源管理、功耗、温度、频率调度温度、功耗、风扇转速、性能状态VCN/UVD视频解码/编码硬件转码、视频播放是否流畅ACP音频协处理器HDMI/DP 音频输出KFD算力设备接口配合 amdkfd通用计算、AI 推理框架能否使用 GPU初看这张表不要全背重点是建立一种认知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。现在很多卡在渲染时崩溃又自动恢复背后就是这套机制在工作。DCNDisplay 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 应用要画一帧用户态驱动会生成一系列硬件命令把它们放到一块命令缓冲区IBIndirect Buffer里然后调用amdgpu_cs_ioctlcommand 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 resetAMDGPU 驱动的启动初始化过程也有两条清晰路径值得记住。第一条路径是软件路径叫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 出错”这个角度做初步定位。我根据自己的经验整理了一张高频问题速查表尽量帮你从“黑屏”这种模糊现象快速锁定到具体方向。症状常见原因优先排查方向开机黑屏、无显示信号DCN 初始化失败、固件缺失、VBIOS 解析异常dmesg 中搜display/amdgpu相关报错检查 firmware 目录使用过程中画面卡死GPU hang、scheduler 超时搜ring gfx timeout确认是否触发 GPU reset性能明显偏低SMU 频率被锁、温度过高、电源管理异常查看amdgpu_pm_info确认实际频率与温度显存报错、OOMTTM 显存不足、对象泄漏、过度碎片化观察mem_info_vram占用趋势检查进程显存占用视频播放花屏VCN/UVD 解码问题、固件版本不匹配换软件解码对比确认是否硬件解码路径问题多屏或 HDR 设置异常DCN 显示路径问题、模式设置错误调整显示配置检查kms相关日志参考内核参数amdgpu.dc1这张表不能替代完整日志分析但能帮你迅速选择一个排查方向。拿到一个问题建议先花两分钟收集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 驱动架构概览能成为你第一步的地图。
阅读完成 · 觉得有帮助？
