1. 课程导入

嵌入式GPU图形调试工程，是一门把“图形渲染原理、GPU硬件行为、驱动与固件、系统级性能分析、可视化调试工具”串成闭环的工程实践课程。它不等同于桌面端的Shader调试，也不只是看帧率曲线；在资源受限、功耗敏感、显示链路复杂、驱动栈裁剪严重的嵌入式平台上，图形问题往往表现为花屏、撕裂、闪烁、掉帧、卡顿、黑屏、颜色异常、内存暴涨或偶发死机。要定位这些问题，必须同时理解GPU如何工作、数据如何流动、系统如何调度，以及调试工具能观测到什么。

一、学习目标：从“看得见”到“说得清、改得动”

完成本课程后，学习者应具备以下能力：第一，能读懂嵌入式图形系统的整体架构，明确应用、图形API、驱动、GPU固件、显示控制器、内存子系统之间的边界与接口；第二，能使用GPU厂商工具与系统级工具采集关键指标，如GPU利用率、带宽、Cache命中率、渲染通道耗时、Shader周期数、纹理采样开销、Overdraw、帧提交时序等；第三，能针对典型故障建立分层假设，例如把“花屏”拆解为纹理上传错误、格式不匹配、同步缺失、显示时序错误或内存越界；第四，能输出可复现、可验证、可回归的调试报告，而不是停留在“重启后好了”的经验判断。

二、核心概念：嵌入式GPU调试的五个关键词

• 渲染管线：顶点处理、图元装配、光栅化、片元着色、逐片元操作、帧缓冲写入。调试时要知道问题发生在哪个阶段。
• Tile-Based Rendering：多数嵌入式GPU采用分块渲染，把屏幕切成Tile，在片上高速内存中完成着色再写回。带宽与Tile尺寸、Render Pass划分强相关。
• 同步与依赖：Fence、Semaphore、Barrier、Render Pass依赖、Buffer生命周期。图形异常常源于“该等的没等，该放的没放”。
• 带宽与功耗：嵌入式GPU最稀缺的是内存带宽和热预算。很多“性能问题”本质是带宽问题或频率策略问题。
• 可观测性：没有计数器、没有Trace、没有帧捕获，调试就退化为猜测。工具链决定调试上限。

三、整体框架：从应用到像素的调试分层

下图给出嵌入式GPU图形调试工程的整体框架。它把系统分为应用层、图形API层、驱动与固件层、GPU硬件层、显示与内存子系统，并在右侧标出每层常用的观测手段与典型问题。调试时遵循“自顶向下定位、自底向上验证”的原则：先从应用与API层确认提交内容是否正确，再下探到驱动与硬件计数器确认执行行为，最后回到显示链路确认输出时序。

四、方法流程：一次完整调试的六个步骤

1. 现象固化：记录设备型号、GPU型号、驱动版本、系统版本、复现步骤、发生频率、是否与温度/电量/分辨率相关。
2. 指标采集：先抓帧率、帧时间、GPU利用率、带宽、频率、温度；再抓单帧Trace与GPU计数器。
3. 假设分层：把问题归入应用逻辑、API使用、驱动行为、硬件限制、显示时序、内存带宽六类之一。
4. 最小化复现：裁剪场景、替换纹理、降低分辨率、关闭后处理，构造最小可复现用例。
5. 对照验证：修改一个变量，观察指标变化；用“改前/改后”数据证明因果关系。
6. 修复回归：提交修复后，用同一套采集脚本回归，确认问题消失且无新瓶颈。

五、典型场景与误区复盘

场景一：某Android设备运行3D应用时偶发花屏。初步怀疑Shader错误，但帧捕获显示纹理格式为RGB565，而驱动按RGBA8888采样，导致颜色通道错位。根因是资源上传路径中格式转换缺失。场景二：UI滑动掉帧，GPU利用率仅40%，但带宽计数器接近峰值。根因是Overdraw严重与纹理未压缩，GPU在等内存。场景三：Vulkan应用在部分设备黑屏，Validation Layer无报错，最终发现是Render Pass的loadOp与显示控制器读取时机不匹配。

六、学习路径与工具清单

# 典型采集命令示例（Android/Linux）
adb shell dumpsys SurfaceFlinger --latency
adb shell cat /sys/class/devfreq/*/cur_freq
adb shell cat /sys/kernel/debug/mali0/gpu_utilization
perfetto -c config.pbtx -o trace.perfetto-trace

本课程后续将围绕上述框架逐层展开：先建立图形管线与Tile渲染的硬件直觉，再进入驱动、同步、内存与显示链路，随后用真实案例训练分层定位能力，最终形成一套可复用的嵌入式GPU图形调试方法论。掌握这套方法，你面对的不再是“玄学花屏”和“偶发掉帧”，而是可观测、可假设、可验证的工程问题。