1. 课程导入
Linux 图形栈是一条从应用绘制请求到像素最终点亮屏幕的完整链路，它横跨用户态图形库、显示服务器、内核 DRM/KMS 子系统以及 GPU 硬件驱动。很多性能问题并非出现在单一模块，而是链路中某一环的等待、拷贝、同步或格式转换被放大。本课程的目标，是让你具备“从现象定位到链路环节，再用可测量手段验证并优化”的工程能力，而不是停留在调参经验层面。
一、学习目标：从会用到会诊断
完成本课程后，你应当能够独立完成以下工作：
- 读懂一帧图形从应用提交到屏幕扫描输出的完整路径，明确各阶段的时间开销来源。
- 使用
perf、ftrace、drm_info、gpuvis、Mesa调试变量等工具采集图形栈关键指标。 - 区分 CPU 瓶颈、GPU 瓶颈、内存带宽瓶颈与同步等待瓶颈，并给出对应优化方向。
- 针对合成器、驱动、缓冲区管理、垂直同步等环节实施可验证的优化改动。
- 建立性能回归意识，用基准与追踪数据支撑优化结论。
二、核心概念：理解图形栈的四个关键词
帧与帧时间。图形系统以帧为基本单位，帧时间由应用渲染、合成、提交、扫描输出共同决定。稳定帧时间比平均帧率更重要，卡顿往往来自个别超长帧。
缓冲区与格式。像素数据存放在缓冲区中，格式（如 ARGB8888、NV12）、修饰符（modifier）和内存布局直接影响 GPU 与显示控制器能否零拷贝直通。
同步与垂直同步。GPU 渲染、CPU 提交与显示扫描之间需要同步。同步过早会阻塞，过晚会撕裂或丢帧，fence 与 vblank 是理解这一过程的关键对象。
合成与直通。合成器决定多个图层是叠加合成还是交给显示控制器硬件平面直通。直通失败通常意味着额外的 GPU 合成与内存带宽消耗。
三、整体知识框架与信号链
下图给出 Linux 图形栈的主干信号链：应用通过图形 API 提交命令，经 Mesa 或厂商用户态驱动转换为 GPU 命令，由内核 DRM 调度执行，最终通过 KMS 将帧缓冲扫描到显示设备。优化工作正是围绕这条链路上的提交、执行、同步与显示四个阶段展开。
四、工程实践路线：从测量到验证
性能优化必须遵循“先测量、再假设、后改动、再验证”的闭环。下面给出可落地的实践流程：
- 建立基线。在目标设备上运行固定场景，记录帧时间分布、GPU 占用、内存带宽与功耗。
- 定位瓶颈。用追踪工具判断时间消耗在提交、执行、同步还是显示阶段。
- 提出假设。例如“合成器未使用硬件平面导致额外 GPU 合成”。
- 实施改动。调整格式、修饰符、图层策略、同步策略或驱动参数。
- 回归验证。重复同一场景，对比基线与改动后的数据，确认无功能回归。
常用采集命令示例：
# 查看 DRM 设备与显示能力
drm_info | head -n 40
# 采集 GPU 与调度相关事件
sudo perf record -a -g -- sleep 5
sudo perf report
# 追踪 fence 与 vblank 时序
sudo trace-cmd record -e drm:\* -e fence:\*
sudo trace-cmd report | head -n 50
五、典型场景与常见误区
以一个视频播放场景为例：应用解码出 NV12 缓冲区，若合成器不支持该格式直通，就会触发 GPU 色彩空间转换与合成，导致带宽上升、功耗增加、帧时间抖动。优化方向是让显示控制器直接扫描 NV12 平面，避免中间 RGBA 转换。
| 常见误区 | 实际原因 | 正确做法 |
|---|---|---|
| 只看平均 FPS | 平均帧率掩盖了长帧卡顿 | 关注帧时间分布与 99 分位延迟 |
| 盲目提高 GPU 频率 | 瓶颈可能在同步或显示阶段 | 先定位瓶颈阶段再决定是否调频 |
| 忽略缓冲区格式 | 格式不匹配引发额外拷贝 | 对齐格式与修饰符，争取硬件直通 |
| 改动后不做回归 | 优化可能引入功能或稳定性问题 | 固定场景复测并保留对比数据 |
本课程后续将沿着这条信号链逐段深入：先建立测量能力，再分别剖析提交路径、GPU 执行、缓冲区与内存、同步机制、合成与显示，最终形成一套可复用的图形栈性能优化方法论。