3. GPU显示与渲染基础
在智能座舱域控制器中，高通8295的Adreno GPU承担着仪表、中控、副驾娱乐、HUD等多路显示内容的合成与渲染任务。理解GPU显示与渲染的基础概念，是后续进行性能调优、卡顿排查和多屏协同开发的前提。本章从图形渲染的基本概念出发，串联显示流水线、帧缓冲、垂直同步与刷新率这几个核心知识点，帮助建立完整的显示链路认知。
一、图形渲染基本概念
图形渲染的本质，是把应用层的场景描述（几何、材质、光照、图层）转换为屏幕上的像素颜色值。在8295平台上，渲染通常分为两个层面：GPU渲染与显示合成。GPU渲染负责把应用提交的绘制指令（Draw Call）执行成一张或多张纹理/图层；显示合成则负责把这些图层按Z序、透明度、缩放关系叠加成最终的一帧画面。
几个关键术语需要先厘清：
- 图元（Primitive）：GPU绘制的基本单位，通常是三角形。顶点着色器处理顶点坐标，光栅化把三角形转为片元。
- 片元（Fragment）：候选像素，经过片元着色器计算颜色、深度测试、混合后写入帧缓冲。
- 纹理（Texture）：GPU采样的图像数据，用于贴图、UI元素、视频帧等。
- 图层（Layer）：合成阶段的最小单元，一个应用窗口可能对应多个图层。
- 绘制调用（Draw Call）：CPU向GPU提交一次绘制命令，数量过多会成为CPU瓶颈。
在车载场景中，渲染负载具有明显的“多屏、多应用、低延迟”特征。仪表要求高帧率稳定，中控要求交互跟手，副驾娱乐可能播放视频。这些需求最终都落到GPU渲染与显示合成的资源竞争上。
二、显示流水线：从应用到屏幕
8295的显示流水线可以概括为“应用绘制 → SurfaceFlinger合成 → 显示控制器 → 面板扫描”四个阶段。应用通过Canvas、OpenGL ES或Vulkan把内容绘制到自己的Surface缓冲区；SurfaceFlinger作为Android的合成器，收集所有可见图层，决定哪些交给GPU合成、哪些交给硬件合成器（DPU）叠加；合成后的帧缓冲交给显示控制器（Display Controller），按扫描时序输出到MIPI DSI或DP接口，最终由屏幕面板逐行扫描显示。
这条流水线中，任何一个环节超时都会导致掉帧或卡顿。例如应用绘制过慢，SurfaceFlinger拿不到新缓冲，只能重复上一帧；GPU合成负载过高，合成时间超过一帧预算，就会错过垂直同步窗口；显示控制器带宽不足，则可能出现撕裂或闪烁。
关键路径：应用绘制 → 缓冲区入队 → SurfaceFlinger合成 → 帧缓冲提交 → 显示控制器扫描 → 面板显示。每一级都有独立的耗时预算，通常以“一帧时间”为上限。
三、帧缓冲与双缓冲/三缓冲机制
帧缓冲（Frame Buffer）是GPU或显示控制器直接读取的像素内存区域。为了避免“一边显示、一边被改写”造成撕裂，系统通常采用多缓冲机制：
- 单缓冲：应用直接写显示内存，简单但极易撕裂，车载中基本不用。
- 双缓冲：前台缓冲用于显示，后台缓冲用于绘制，绘制完成后交换（Swap）。若交换时机不当，仍可能等待。
- 三缓冲：增加一个待显示缓冲，允许GPU在显示当前帧时继续绘制下一帧，减少因错过VSync导致的卡顿，但会增加一帧延迟。
在8295的Android显示框架中，BufferQueue负责管理这些缓冲。应用是生产者，SurfaceFlinger是消费者。当缓冲区数量不足或释放不及时，生产者会被阻塞，表现为应用掉帧。
# 查看当前显示缓冲与合成状态（示意）
adb shell dumpsys SurfaceFlinger --latency
adb shell dumpsys SurfaceFlinger | grep -i "buffer"
adb shell dumpsys gfxinfo com.example.app
实际调优时，需要关注缓冲区的dequeue与queue耗时、GPU合成占比、以及是否频繁触发GPU合成回退。若发现某应用持续占用三缓冲仍掉帧，往往说明其单帧绘制时间已超过一帧预算，需要从渲染负载入手优化。
四、垂直同步与刷新率
垂直同步（VSync）是显示流水线的“节拍器”。它来源于显示面板的场同步信号，表示一帧扫描结束、下一帧即将开始。GPU和合成器在VSync到来时提交新帧，可以避免撕裂。Android的Choreographer、SurfaceFlinger的VSync分发都依赖这个信号。
刷新率（Refresh Rate）则是面板每秒扫描画面的次数，常见60Hz、90Hz、120Hz。8295支持多屏不同刷新率，也支持可变刷新率（VRR）以降低功耗。刷新率越高，单帧时间预算越短：60Hz为16.67ms，90Hz为11.11ms，120Hz为8.33ms。这意味着高刷屏对GPU渲染和合成的时间要求更苛刻。
| 刷新率 | 单帧时间预算 | 典型车载场景 | 调优关注点 |
|---|---|---|---|
| 60Hz | 16.67ms | 仪表、HUD | 稳定性优先，避免抖动 |
| 90Hz | 11.11ms | 中控主屏 | 交互跟手，合成耗时 |
| 120Hz | 8.33ms | 副驾娱乐、高刷屏 | GPU负载与带宽 |
提示：VSync是“提交时机”，刷新率是“显示节奏”。两者配合决定了一帧能否按时上屏。高刷新率并不自动等于流畅，若GPU渲染时间超过单帧预算，仍会掉帧。
五、案例与常见误区
某8295座舱项目在中控屏滑动列表时出现周期性卡顿。通过dumpsys gfxinfo发现，应用单帧绘制时间约14ms，接近60Hz预算，但合成阶段又额外消耗5ms，导致总耗时超过16.67ms，错过VSync。优化措施包括：减少过度绘制、合并Draw Call、将静态图层交给硬件合成器、降低不必要的透明度混合。调整后单帧总耗时降至11ms，滑动恢复顺滑。
常见误区有三点：
- 只盯GPU占用率：GPU占用不高也可能因CPU提交慢、合成器等待而掉帧。
- 认为三缓冲一定更好：三缓冲会增加延迟，对实时性要求高的倒车影像、HUD可能不利。
- 忽略多屏刷新率差异：不同屏幕VSync独立，跨屏动画若未对齐，会出现视觉不同步。
注意：在8295多屏项目中，仪表与中控可能运行在不同刷新率下。跨屏共享GPU资源时，必须分别评估各屏的单帧预算，避免高刷屏拖垮低刷屏的稳定性。