Linux内核DRM/KMS显示子系统深度工程实践：从KMS原子提交到GPU调度

引言

Linux 内核 DRM（Direct Rendering Manager）与 KMS（Kernel Mode Setting）子系统是现代显示栈的核心基石。从智能手机的嵌入式面板到数据中心 GPU 显示输出，从 Wayland 合成器到 Vulkan/OpenGL 图形应用，所有图形渲染最终都要经过 DRM/KMS 这一层与硬件交互。而对于系统工程师而言，理解 DRM/KMS 不仅是驱动开发的前提，更是 GPU 计算、AI 推理和视频处理等场景中优化显示流水线、排查画面撕裂与延迟问题的关键。

本文将从 DRM 子系统的架构历史出发，深入剖析 KMS 的核心对象体系（CRTC/Encoder/Connector/Plane）、原子提交的完整机制（Atomic Commit）、GPU 调度器（drm_sched）与 Fence 同步协议、DMA-BUF 与 PRIME 显存共享模型，并结合内核源码（以 6.8.x 为基准）展示如何在实际驱动开发和系统调优中运用这些机制。

一、DRM 子系统架构演进史

1.1 从 X11 到 Wayland：显示栈的范式转移

在 X11 时代，显示模式配置（Mode Setting）由 X Server 通过 xf86-video 驱动直接操作硬件完成，内核只负责基本的帧缓冲映射。这种用户态模式设置的架构带来了严重的安全性和稳定性问题——错误的显示配置可能导致系统挂死。

KMS 的出现彻底改变了这一格局。Linux 2.6.28（2008 年）首次引入 KMS 支持，将显示模式设置权从用户态移入内核态，实现了：

• 原子性模式切换：所有显示参数（分辨率、刷新率、像素格式）在 vblank 期间一次性生效，避免中间状态闪烁
• 安全隔离：普通用户无法任意修改显示模式，防止恶意程序破坏显示
• 早期启动显示：内核启动阶段即可配置显示模式，消除启动过程中的屏幕闪烁
• 多客户端并发：多个应用可同时持有显示资源，由内核协调分配

1.2 DRM 子系统的四层架构

现代 DRM 子系统从上到下分为四个鲜明的层次：

+-------------------------------------------+
│  用户态：Mesa / libdrm / Wayland / Xorg   │
+-------------------------------------------+
│  抽象层：drm_mode_config / GEM / KMS     │
+-------------------------------------------+
│  驱动层：i915 / amdgpu / nouveau / v3d   │
+-------------------------------------------+
│  硬件层：GPU + Display Controller + PHY   │
+-------------------------------------------+

核心抽象层通过 drm_mode_config 初始化显示控制器配置，通过 GEM（Graphics Execution Manager）管理显存分配与管理，通过 KMS 对象体系建模显示管线。驱动程序则围绕这些抽象注册回调函数，实现具体硬件操作。

二、KMS 核心对象体系

2.1 CRTC：显示管线的核心调度器

CRTC（Cathode Ray Tube Controller，尽管已不限于 CRT）是显示管线的灵魂，它代表一个"显示通道"，负责从 framebuffer 中读取像素数据并按时序发送给 encoder。一个 CRTC 通常绑定一个时序发生器（Timing Generator），控制 hsync、vblank 等信号。

// include/drm/drm_crtc.h
struct drm_crtc {
    struct drm_device *dev;
    struct drm_mode_config *config;
    
    // 时序模式
    struct drm_display_mode mode;
    
    // 像素格式与色彩空间
    uint32_t pixel_format;  // DRM_FORMAT_XRGB8888 / DRM_FORMAT_NV12 等
    
    // 当前绑定的 primary plane
    struct drm_plane *primary;
    
    // vblank 处理
    struct drm_vblank_crtc vblank;
    
    // 驱动回调
    struct drm_crtc_funcs *funcs;
};

关键函数 drm_crtc_helper_funcs::mode_set_nofb() 在模式变更时被调用，驱动需在此配置硬件时序参数。而 set_config 回调则是整个 CRTC 配置编排的入口。

2.2 Plane：图层的抽象

DRM KMS 定义了三种 Plane 类型，这是现代显示合成能力的核心：

• Primary Plane（主图层）：必选，承载 CRTC 的主显示内容，与 CRTC 一一对应
• Cursor Plane（光标图层）：用于硬件鼠标光标合成，支持独立于主画面更新位置（避免全屏刷新）
• Overlay Plane（叠加图层）：用于硬件视频解码叠加、弹窗提示等，可显著降低 GPU 负载

// Plane 能力标志
#define DRM_PLANE_TYPE_PRIMARY  1
#define DRM_PLANE_TYPE_OVERLAY  0
#define DRM_PLANE_TYPE_CURSOR   2

struct drm_plane {
    struct drm_device *dev;
    struct drm_crtc *crtc;          // 当前绑定的 CRTC
    struct drm_framebuffer *fb;     // 当前绑定的 frame buffer
    
    // 支持的像素格式
    const uint32_t *format_list;
    uint32_t format_count;
    
    // 位置与裁剪
    int crtc_x, crtc_y;
    uint32_t crtc_w, crtc_h;
    
    // Z-order 控制
    uint32_t zpos;
    
    struct drm_plane_funcs *funcs;
    struct drm_plane_helper_funcs *helper_funcs;
};

Overlay Plane 是性能优化的关键。以视频播放器为例，使用 Overlay Plane 直接叠加视频帧可使 CPU/GPU 合成开销降低 80% 以上，同时视频层的 YUV 转 RGB 也由硬件完成，节省了大量 GPU 算力。

2.3 Connector：物理输出端口的抽象

Connector 代表物理显示端口（HDMI、eDP、DP、VGA 等）。它负责检测显示器连接状态（HPD 热插拔检测）、读取 EDID 信息、获取受支持的模式列表。

struct drm_connector {
    struct drm_device *dev;
    struct drm_encoder *encoder;    // 当前绑定的 encoder
    
    // 状态检测
    enum drm_connector_status connection;
    enum drm_connector_status (*detect)(struct drm_connector *, bool);
    
    // EDID 信息
    struct drm_edid *edid;
    
    // 模式列表
    struct list_head modes;
    
    // 物理属性
    uint32_t width_mm, height_mm;
    uint32_t connector_type;  // DRM_MODE_CONNECTOR_HDMIA / eDP / DP
    
    // 可选属性（HDR、colorspace 等）
    struct drm_property_blob *edid_blob;
    struct drm_object_properties properties;
};

在高分辨率高刷新率场景下，Connector 的 EDID 解析至关重要。4K@120Hz 或 8K@60Hz 的显示输出往往受限于显示接口带宽，需要通过 DSC（Display Stream Compression）进行视觉无损压缩，DRM 框架通过 drm_dp_pcon_dsc_max_slice_count 等接口查询目标显示器的 DSC 能力。

2.4 Encoder：信号格式转换器

Encoder 连接 CRTC 和 Connector，负责将像素数据转换为适合传输的信号格式。例如 CRTC 输出并行 RGB，而 eDP/LVDS 需要串行化转换，HDMI 需要 TMDS 编码。

struct drm_encoder {
    struct drm_device *dev;
    struct drm_crtc *crtc;          // 当前绑定的 CRTC
    
    // 支持的 CRTC 掩码（一个 encoder 可能支持多个 CRTC）
    uint32_t possible_crtcs;
    uint32_t possible_clones;
    
    struct drm_encoder_funcs *funcs;
    struct drm_encoder_helper_funcs *helper_funcs;
};

在支持多 GPU 输出的场景中（如 AMDGPU 的 MST dongle），Encoder 的 CRTC 掩码决定了信号路由的灵活性。一个 encoder 可以通过 possible_crtcs 声明可用的 CRTC 索引位图，驱动据此自动选择最优路径。

三、KMS 原子提交：革命性的显示配置

3.1 从 Legacy 到 Atomic：为何需要原子提交

Legacy KMS API 的 drm_mode_set_crtc_config() 存在严重的中间状态问题：一次模式切换涉及 CRTC、Plane、Connector、Encoder 多个对象的协同变更，若某个步骤失败，系统已处于不一致的显示状态——屏幕可能出现撕裂、闪烁甚至完全黑屏。

DRM Atomic Mode Setting 引入事务性语义：所有变更打包为一个原子操作，先通过硬件校验（atomic_check），全部通过后才在 vblank 期间一次性提交（atomic_commit），任一步骤失败则整个事务回滚，显示状态保持不变。

3.2 原子提交的核心流程

原子提交通过 drmModeAtomicCommit() 用户态接口触发，内核态执行路径如下：

// drivers/gpu/drm/drm_atomic.c (简化流程)
int drm_atomic_commit(struct drm_atomic_state *state)
{
    // 1. 分配状态结构（复制所有参与对象的状态快照）
    struct drm_atomic_state *state = drm_atomic_state_alloc(dev);
    
    // 2. 序列化所有对象的属性变更到 state
    drm_atomic_set_mode_for_crtc(state->crtc_state, &mode);
    drm_atomic_set_fb_for_plane(state->plane_state, fb);
    
    // 3. atomic check 阶段（验证硬件能力）
    //    检查：带宽是否超限？模式是否受支持？时序是否合法？
    ret = drm_atomic_check_only(state);
    
    // 4. 若检查通过，执行 commit
    if (ret == 0) {
        // 4a. 锁定 commit 序列号
        drm_atomic_state_commit(state);
        
        // 4b. 在 vblank 期间原子应用所有变更
        //     commit_tail() → driver's atomic_commit()
    }
    
    // 5. 释放状态结构
    drm_atomic_state_put(state);
    return ret;
}

关键设计要点：

• 非阻塞提交：通过 DRM_MODE_ATOMIC_NONBLOCK 标志实现异步提交，结合 EVENT 机制通知完成
• Allow modeset 标志：DRM_MODE_ATOMIC_ALLOW_MODESET 允许模式变更（可能触发短暂黑屏），而非仅更新位置/图层
• Test-only 模式：DRM_MODE_ATOMIC_TEST_ONLY 仅执行 check 而不提交，用于验证配置可行性

3.3 用户态实战：Atomic Commit 的 libdrm 调用示例

以下代码展示如何使用 Atomic API 将帧缓冲从 1920x1080 切换到 3840x2160：

#include <xf86drm.h>
#include <xf86drmMode.h>
#include <libdrm/drm_mode.h>

int commit_mode_atomic(int fd, uint32_t crtc_id, uint32_t conn_id,
                       uint32_t fb_id, drmModeModeInfo *mode)
{
    drmModeAtomicReq *req = drmModeAtomicAlloc();
    
    // 1. 设置 CRTC 模式
    uint32_t blob_id;
    drmModeAtomicAddProperty(req, crtc_id,
        get_property_id(fd, crtc_id, "MODE_ID"),
        drmModeCreatePropertyBlob(fd, mode, sizeof(*mode), &blob_id));
    drmModeAtomicAddProperty(req, crtc_id,
        get_property_id(fd, crtc_id, "ACTIVE"), 1);
    
    // 2. 设置 Connector CRTC 绑定
    drmModeAtomicAddProperty(req, conn_id,
        get_property_id(fd, conn_id, "CRTC_ID"), crtc_id);
    
    // 3. 配置 Primary Plane（帧缓冲 + 位置）
    uint32_t plane_id = get_primary_plane(fd, crtc_id);
    drmModeAtomicAddProperty(req, plane_id, prop_fb_id, fb_id);
    drmModeAtomicAddProperty(req, plane_id, prop_src_x, 0);
    drmModeAtomicAddProperty(req, plane_id, prop_src_y, 0);
    drmModeAtomicAddProperty(req, plane_id, prop_src_w, mode->hdisplay << 16);
    drmModeAtomicAddProperty(req, plane_id, prop_src_h, mode->vdisplay << 16);
    drmModeAtomicAddProperty(req, plane_id, prop_crtc_x, 0);
    drmModeAtomicAddProperty(req, plane_id, prop_crtc_y, 0);
    drmModeAtomicAddProperty(req, plane_id, prop_crtc_w, mode->hdisplay);
    drmModeAtomicAddProperty(req, plane_id, prop_crtc_h, mode->vdisplay);
    
    // 4. 提交（非阻塞 + 允许模式设置）
    uint32_t flags = DRM_MODE_ATOMIC_NONBLOCK | DRM_MODE_ATOMIC_ALLOW_MODESET;
    
    struct drm_event_vblank event = {0};
    int ret = drmModeAtomicCommit(fd, req, flags, &event);
    
    if (ret == 0) {
        printf("Atomic commit enqueued, will complete on vblank\n");
    }
    
    drmModeAtomicFree(req);
    return ret;
}

四、GPU 调度器与 Fence 同步

4.1 为什么 GPU 需要调度器？

现代 GPU 执行命令缓冲区（Command Buffer），多个客户端（OpenGL、Vulkan、视频编解码、计算）同时提交作业时需要 CPU 侧的调度器来管理执行队列。DRM 子系统通过 drm_sched（也被称为 GPU Scheduler）实现这一功能。

// drivers/gpu/drm/sched/gpu_scheduler.c (简化)
struct drm_gpu_scheduler {
    // 作业队列
    atomic_t hw_rq_count;
    struct drm_sched_rq run_list;       // 就绪队列（按优先级排序）
    
    // 工作线程
    struct task_struct *thread;
    
    // 硬件队列管理
    struct drm_sched_rq hw_rq;
    uint32_t hw_queues;                 // 硬件队列数量（通常 max ≤ 64）
    
    // 超时与恢复
    struct delayed_work work_tdr;       // 看门狗（Timeout Detection & Recovery）
    
    // 优先级调度
    struct drm_sched_entity *entities[DRM_SCHED_PRIORITY_MAX];
    
    // 回调
    struct drm_sched_backend_ops *ops;
};

drm_sched 支持三个优先级（高/普通/低），每个客户端的 drm_sched_entity 维护自己的 pending 队列。调度器按优先级+到达顺序（FIFO）选择下一个要提交的作业发给硬件。

4.2 Fence 同步协议

GPU 作业之间存在复杂的数据依赖关系：作业 B 必须等待作业 A 完成才能执行。DRM 使用 drm_syncobj + dma_fence 表达这些依赖。

// include/drm/drm_syncobj.h
struct drm_syncobj {
    struct kref refcount;
    struct drm_file *file;
    
    // Fence 链表（多 producer 场景）
    struct list_head head;
    spinlock_t lock;
};

// 用户态获取/等待 syncobj fence
struct drm_syncobj_create args_create = {
    .flags = DRM_SYNCOBJ_CREATE_SIGNALED // 初始状态 signaled
};
drmIoctl(fd, DRM_IOCTL_SYNCOBJ_CREATE, &args_create);

// 导出 fence 给驱动
struct drm_syncobj_handle args_export = {
    .handle = syncobj_handle,
    .flags = DRM_SYNCOBJ_FD_TO_HANDLE_FLAGS_EXPORT_SYNC_FILE
};
drmIoctl(fd, DRM_IOCTL_SYNCOBJ_HANDLE_TO_FD, &args_export);

Fence 的典型用法：应用提交渲染命令时指定 wait fence（等待前置操作完成）和 signal fence（渲染完成后触发），KMS 原子提交时在 drm_plane_state::fence 中传入上一帧的 out_fence，确保硬件在当前帧完全呈现前不会覆写 framebuffer——这是零撕裂（Zero Tearing）的关键。

4.3 作业提交与硬件队列调度

AMDGPU 和 Nouveau（开源 NV 驱动）的实际调度流程：

// drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
struct amdgpu_ctx {
    struct kref refcount;
    struct amdgpu_device *adev;
    
    // 每个 ctx 按环类型分配实体
    struct drm_sched_entity context[AMDGPU_HW_IP_NUM][AMDGPU_RING_PRIORITY_MAX];
    
    // 同步对象
    struct amdgpu_ctx_entity {
        struct drm_sched_entity entity;
        struct dma_fence *fences[MAX_SUBMISSIONS];
    };
};

// 作业提交链
int amdgpu_cs_ioctl(struct drm_device *dev, void *data, struct drm_file *filp)
{
    struct amdgpu_cs_parser parser;
    
    // 1. 解析用户态命令缓冲区（changelist, IB buffers）
    // 2. 获取等待 fence（依赖的其他作业）
    // 3. 调用 drm_sched_entity_push_job() 将作业入队
    drm_sched_entity_push_job(&sched_job);
    
    // 4. 驱动 ops->run_job() 在硬件上执行
    //    完成后通过 drm_sched_fence_finished() signal fence
}

AMDGPU 按硬件 IP 类型（GFX/SDMA/VCN/UVD 等）划分独立调度实体，每个类型对应独立的硬件环（Ring），实现了真正的并行执行：GFX 环渲染图形的同时，SDMA 环执行数据拷贝，VCN 环进行视频编解码。

五、DMA-BUF 与 PRIME：显存共享模型

5.1 DMA-BUF 框架

跨设备显存共享是 DRM 的核心需求：视频解码器产出的 NV12 buffer 需要直接送到显示器扫描，Vulkan GPU 渲染结果需要交给合成器合成，AI 推理的 tensor buffer 需要显示在屏幕上。DMA-BUF（Linux DMA Buffer Sharing）解决了这一"跨越设备边界"问题。

// include/linux/dma-buf.h
struct dma_buf {
    size_t size;
    struct file *file;
    struct list_head attachments;
    
    // 操作回调
    const struct dma_buf_ops *ops;
    
    // 导出者分配的私有数据
    void *priv;
};

struct dma_buf_ops {
    // CPU 访问控制
    int (*begin_cpu_access)(struct dma_buf *, enum dma_data_direction);
    int (*end_cpu_access)(struct dma_buf *, enum dma_data_direction);
    
    // 映射操作
    struct sg_table *(*map_dma_buf)(struct dma_buf_attachment *, enum dma_data_direction);
    void (*unmap_dma_buf)(struct dma_buf_attachment *, struct sg_table *, enum dma_data_direction);
    
    // 释放回调
    void (*release)(struct dma_buf *);
};

DMA-BUF 文件描述符机制是真正的"零拷贝"关键：GPU 驱动分配显存后导出为 DMA-BUF fd，其他设备通过 dma_buf_attach() + map_dma_buf() 获取 scatter-gather 列表，直接在硬件间建立 DMA 通路，无需复制内存数据。

5.2 PRIME：显示驱动的显存导入导出

PRIME（Pseudo-Random Memory Architecture for GPU Exporting）是 DMA-BUF 在 DRM 驱动中的具体实现，通过 DRM_IOCTL_PRIME_HANDLE_TO_FD 和 DRM_IOCTL_PRIME_FD_TO_HANDLE 在 DRM 句柄和 DMA-BUF fd 之间转换。

典型的跨 GPU 渲染+显示流程：

// 应用侧代码示例（伪代码）
// 1. 在 GPU A 上渲染
drm_intel_bo *render_bo = drm_intel_bo_alloc(primary_dev, "render", size, alignment);
// ... Vulkan rendering to render_bo ...

// 2. 导出为 DMA-BUF fd
int prime_fd;
drm_intil_bo_gem_export_to_prime(render_bo, &prime_fd);

// 3. 在显示设备（GPU B）上导入
uint32_t import_handle;
drmPrimeFDToHandle(display_fd, prime_fd, &import_handle);

// 4. 创建 DRM framebuffer
uint32_t fb_id;
drmModeAddFB2(display_fd, width, height, DRM_FORMAT_XRGB8888,
              &import_handle, &pitch, &offset, &fb_id, 0);

// 5. 通过 KMS Atomic 提交显示
drmModeAtomicCommit(display_fd, req, flags, user_data);

六、实战案例分析

6.1 4K HDR 显示的色彩管线调试

在 Linux 桌面实现真正的 HDR 输出需要 DRM 栈的多层配合：应用端合成 HDR 帧（包含 SMPTE 2084 PQ Transfer Function + BT.2020 色域），经过 Wayland 合成器传递到 KMS 驱动，最终通过 HDMI 2.1 或 DP 2.1 的 FRL（Fixed Rate Link）发送给显示器。

DRM 通过 Property 链传递 HDR 元数据：

// HDR Output Protocol Property
struct drm_property *hdr_output_metadata =
    drm_property_create_blob(dev, "HDR_OUTPUT_METADATA", 
                              sizeof(struct hdr_output_metadata));

// 在原子提交时设置
drm_object_attach_property(&connector->base, hdr_output_metadata, blob_id);
drm_object_attach_property(&plane->base, "IN_COLOR_ENCODING", 0);
drm_object_attach_property(&plane->base, "IN_TRANSFER_FUNCTION",
                            DRM_COLORIMETORY_TFR_2084_PQ);

常见问题排查管线：

• 若 KMS 日志显示 "No valid mode found"：检查 EDID 是否包含目标分辨率
• 若 Atomic commit 返回 -EINVAL：检查 CRTC/Plane 是否满足 bandwidth 约束（如 4K@120Hz 10bit 超出 DP 1.4 带宽需启用 DSC）
• 若出现画面撕裂：检查 PAGE_FLIP_EVENT 的时序配置，确保 atomic commit 在 vblank 期间完成

6.2 Wayland 合成器的 KMS 交互优化

Weston 和 wlroots 合成器作为 DRM Master 直接与 KMS 交互，其性能直接影响桌面流畅度。关键优化点包括：

1. Atomic commit 批处理：将多窗口更新打包为一次 atomic commit，减少上下文切换
2. Zero-copy 路径：客户端通过 linux-dmabuf-v1 协议提交 DMA-BUF，合成器直接扫描，避免 copy
3. Out-fence 反馈：从 atomic commit 获取 out_fence fd，传递给客户端作为帧呈现完成信号，实现精确帧同步
4. Explicit Sync（Linux 6.8+）：基于 drm_syncobj 的显式同步取代隐式 sync_file，使客户端/合成器/驱动三方的同步语义更明确

6.3 AI 推理结果的 KMS 直接显示管线

在 AI 显示加速场景（如实时超分辨率、DLSS/FSR 类的帧生成技术），GPU 推理结果的显示延迟至关重要。传统路径为：推理 → 显存 → 拷贝到 CPU → 拷贝回显存 → KMS 显示。而使用 DMA-BUF PRIME + KMS Overlay 的零拷贝路径可将延迟从 ~5ms 降低至 <0.5ms：

// 零拷贝 AI 推理显示路径
// 1. NPU/GPU 推理输出写入 DMA-BUF
struct ai_tensor_buf *tensor = ai_alloc_dmabuf(inference_ctx, width, height, NV12);
run_inference(inference_ctx, input_tensor, tensor);

// 2. 直接导入为 DRM Overlay Plane
uint32_t overlay_fb = drm_fb_from_dmabuf(display_dev, tensor->dmabuf_fd, NV12);

// 3. Atomic commit 将 Overlay 合成到主画面
drm_atomic_set_plane_fb(req, overlay_plane, overlay_fb);
drm_atomic_set_plane_position(req, overlay_plane, x1, y1, x2, y2);
drm_atomic_commit(req);

七、性能调优与观测工具

7.1 DRM 调试接口

内核提供了丰富的调试接口来观测 DRM/KMS 运行时状态：

# DRM 驱动状态
cat /sys/kernel/debug/dri/0/state

# Vblank 计数与时间戳
cat /sys/kernel/debug/dri/0/vblank

# 帧缓冲对象（GEM）使用情况
cat /sys/kernel/debug/dri/0/gem

# 启用 DRM 调试日志
echo 0x1F > /sys/module/drm/parameters/debug

# 查看当前 KMS 配置
modetest -M i915  # （来自 libdrm-tests）

7.2 ftrace 追踪 KMS 事件

DRM 子系统内置了专门的 trace event，可精确追踪 atomic commit 的每个阶段耗时：

# 启用 DRM 内核追踪点
cd /sys/kernel/tracing
echo 1 > events/drm/drm_vblank_event/enable
echo 1 > events/drm/drm_run_job/enable
echo 1 > events/drm/drm_sched_run_job/enable

# 读取追踪数据
cat trace
# 输出示例：
# drm_vblank_event: crtc=0, seq=12345, time=1690687879.123456
# drm_sched_run_job: entity=00000000, id=42, fence=00000001

通过分析 vblank_event 的时间戳间隔，可精确计算出每一帧的抖动（jitter）和丢帧时机，定位合成器或 GPU 调度的性能瓶颈。

7.3 eBPF 观测 DRM 作业提交

结合 eBPF uprobe，可以在生产环境无侵入地追踪 DRM 调度器的作业提交延迟：

// 追踪 drm_sched_entity_push_job 的调用耗时
SEC("uprobe/drm_sched_entity_push_job")
int trace_job_push(struct pt_regs *ctx) {
    struct drm_sched_job *job = (struct drm_sched_job *)PT_REGS_PARM1(ctx);
    u64 ts = bpf_ktime_get_ns();
    
    // 记录 job 入队时间戳
    bpf_map_update_elem(&job_start, &->id, &ts, BPF_ANY);
    
    return 0;
}

// 追踪 fence signal 时间
SEC("uprobe/drm_sched_fence_finished")
int trace_fence_signal(struct pt_regs *ctx) {
    struct drm_sched_fence *fence = (struct drm_sched_fence *)PT_REGS_PARM1(ctx);
    
    // 计算排队延迟 = signal_time - push_time
    u64 *start = bpf_map_lookup_elem(&job_start, &fence->scheduled.base.seqno);
    if (start) {
        u64 latency = bpf_ktime_get_ns() - *start;
        bpf_histogram_record(job_latency_hist, latency);
    }
    return 0;
}

八、总结与展望

DRM/KMS 是一个涵盖硬件抽象、显存管理、作业调度、像素管线、协议转换的复杂子系统。掌握以下核心概念是驾驭这一子系统的关键：

• 对象层次：CRTC（时序/调度）→ Plane（图层/Framebuffer）→ Encoder（信号转换）→ Connector（物理接口）
• 原子提交：事务化配置，避免显示中间状态；check-then-commit 两阶段保证一致性
• GPU 调度：drm_sched 按优先级+FIFO 调度作业，通过 Timeout Detection Recovery 防止 GPU hang
• 显存共享：DMA-BUF + PRIME 实现零拷贝跨设备显存传递，是 AI 显示加速的关键

随着 Linux 6.8 引入 Explicit Sync 支持和 DisplayPort 2.1 的普及，DRM/KMS 正在向更精确的帧同步、更低的显示延迟演进。同时，DSI/DPI 等嵌入式显示接口的完善、USB-C Alt Mode（DP over USB4）的成熟，使 DRM/KMS 在移动设备和笔记本领域的应用也越来越深入。对于系统工程师而言，深入理解 DRM/KMS 不仅是 GPU 驱动开发的基础，更是构建下一代桌面体验、AI 显示加速和实时渲染系统的必经之路。