3. GPU渲染管线基础：从CPU到GPU的图形数据流、显存管理、渲染上下文

在DRM/KMS显示驱动开发中，理解GPU渲染管线是掌握多平面合成与硬件加速的前提。本章聚焦于图形数据从CPU内存到GPU显存的流动路径、显存管理策略以及渲染上下文（Context）的创建与切换机制。这些概念构成了驱动开发者与GPU硬件交互的底层语言。

3.1 图形数据流：从CPU到GPU的完整路径

图形渲染的第一步是将顶点数据、纹理和着色器从系统内存（CPU可访问）传输到显存（GPU可访问）。这一过程涉及多个硬件单元和驱动层的协同工作。

下图展示了典型的图形数据流架构，包含CPU提交、DMA传输和GPU消费三个阶段：

3.1.1 数据流的关键阶段

3.2 显存管理：GEM与TTM框架

Linux内核提供了两种主要的显存管理框架：GEM (Graphics Execution Manager) 和 TTM (Translation Table Manager)。DRM驱动通常选择其一，或混合使用。

3.2.1 GEM vs TTM 对比

GEM对象是DRM中最基本的显存抽象。每个GEM对象代表一块GPU可访问的内存区域，通过句柄（handle）在用户态和内核态之间传递。

// 创建GEM对象示例 (内核驱动侧)
struct drm_gem_object *gem_obj;
size_t size = 1024 * 1024; // 1MB

gem_obj = drm_gem_object_alloc(dev, size);
if (IS_ERR(gem_obj))
    return PTR_ERR(gem_obj);

// 用户态通过ioctl获取句柄
// DRM_IOCTL_GEM_OPEN 或 DRM_IOCTL_GEM_FLINK

3.2.2 显存分配与绑定流程

下图展示了GEM对象从创建到GPU绑定的完整生命周期：

3.3 渲染上下文（Context）：GPU执行环境

渲染上下文是GPU执行命令所需的状态集合，包括：页表、着色器程序、常量缓冲区、渲染目标等。在DRM中，上下文通过 drm_file 和 drm_sched_entity 管理。

3.3.1 上下文的核心组成

3.3.2 上下文创建与切换流程

用户态通过DRM ioctl创建上下文，内核驱动负责分配硬件资源并初始化页表。上下文切换通常发生在提交命令缓冲区时，由调度器决定。

// 用户态创建上下文 (libdrm 示例)
struct drm_amdgpu_ctx_in ctx_in = {0};
struct drm_amdgpu_ctx_out ctx_out = {0};
int fd = open("/dev/dri/card0", O_RDWR);

ctx_in.op = AMDGPU_CTX_OP_ALLOC;
if (drmCommandWriteRead(fd, DRM_AMDGPU_CTX, &ctx_in, sizeof(ctx_in)))
    // 错误处理

uint32_t ctx_id = ctx_out.id; // 上下文ID，后续提交使用

3.3.3 多上下文与优先级调度

现代GPU支持多个渲染上下文并发执行。DRM调度器根据优先级和时间片分配GPU时间，确保实时任务（如显示刷新）不被阻塞。

3.4 实践要点与常见陷阱

• 显存泄漏： GEM对象引用计数管理不当会导致显存泄漏。务必配对使用 drm_gem_object_get 和 drm_gem_object_put。
• 上下文隔离： 不同进程的上下文必须拥有独立的地址空间，防止GPU错误访问其他进程的数据。
• Fence等待： 在提交新命令前，必须等待前一个Fence信号，否则可能导致GPU管线混乱。
• DMA映射一致性： 使用 dma_map_sg 后，必须调用 dma_unmap_sg 释放映射，否则IOMMU表会溢出。

3.5 本章小结