2. 嵌入式GPU基础
嵌入式GPU调试的第一步，不是急着抓帧或看日志，而是建立一张“从应用命令到屏幕像素”的完整心智地图。只有知道一个三角形在硬件里经过了哪些模块、哪些缓存、哪些队列，才能在画面异常时快速判断问题出在驱动、管线状态、着色器还是内存带宽。本节围绕GPU架构、图形管线、渲染流程、主流嵌入式GPU平台与图形API展开，为后续的抓帧、性能分析和故障定位打基础。
一、嵌入式GPU的典型架构
嵌入式GPU与桌面独显在架构理念上相通，但更强调面积、功耗与带宽约束。一个典型的移动GPU通常包含以下部分：
- 命令处理器（Command Processor）：从命令缓冲区读取驱动提交的GPU命令，分发给后续固定功能单元和着色器核心。
- 几何/顶点处理单元：执行顶点着色、图元装配、裁剪与视口变换。
- 光栅化单元（Rasterizer）：把三角形转换为片元，生成覆盖信息。
- 着色器核心（Shader Core）：统一或分立的顶点/片元/计算着色器执行单元，是并行计算的主体。
- 纹理单元（TMU）与ROP：负责纹理采样、过滤，以及深度测试、混合和写入帧缓冲。
- 片上缓存与Tile Memory：移动GPU普遍采用分块渲染（Tile-Based Rendering），把屏幕切成小块，在片上高速内存中完成渲染后再写回系统内存，显著降低带宽。
理解“分块”非常关键：很多嵌入式GPU的中间结果并不直接写主存，而是留在Tile Memory中。若调试时发现中间Render Target读取异常，往往与Tile的解析（resolve）和存储（store）行为有关。
二、图形管线的阶段划分
图形管线可以理解为一条“流水线”，每个阶段只做一件事，阶段之间通过寄存器、缓冲区和片上存储传递数据。以OpenGL ES/Vulkan为代表的现代管线大致分为：
- 顶点获取与顶点着色：读取顶点属性，执行顶点着色器，输出裁剪空间坐标。
- 图元装配与裁剪：把顶点组成三角形、线段或点，裁掉视口外的部分。
- 光栅化：把图元离散为片元，并插值顶点属性。
- 片元着色：执行片元着色器，进行纹理采样、光照计算等。
- 逐片元操作：深度测试、模板测试、混合，最终写入帧缓冲。
调试时，管线阶段对应着不同的“可疑点”：顶点位置错乱优先查顶点着色器和矩阵；纹理错位优先查UV与采样状态；颜色异常优先查混合与颜色空间；深度冲突优先查深度测试和精度。
三、渲染流程与分块渲染
嵌入式GPU普遍采用分块渲染（Tile-Based Rendering, TBR）。其流程是：驱动先把一帧的绘制命令按Tile分箱（Binning），每个Tile只处理落在其中的几何；然后在片上Tile Memory中完成该Tile的着色与混合；最后把Tile解析并写回系统内存。这样做的核心收益是减少对主存的读写次数，从而降低功耗和带宽压力。
调试提示：在TBR架构下，如果某个Render Target被频繁切换或需要CPU读取，会触发Tile的store/resolve，带来额外带宽开销。抓帧时若看到“resolve”或“store”相关调用，应重点关注它是否必要。
四、常见嵌入式GPU平台与图形API
嵌入式GPU平台种类多，调试工具链差异大。下表列出常见平台及其典型图形API，便于在拿到设备后快速判断调试路径。
| 平台/厂商 | 典型GPU架构 | 常见图形API | 调试关注点 |
|---|---|---|---|
| ARM Mali | Midgard / Bifrost / Valhall | OpenGL ES、Vulkan | Tile分箱、着色器核心占用、带宽 |
| Qualcomm Adreno | Adreno 系列 | OpenGL ES、Vulkan | Binning、GMEM、驱动状态 |
| Imagination PowerVR | Rogue / A系列 | OpenGL ES、Vulkan | TBDR延迟渲染、HSR |
| NVIDIA Tegra | 基于桌面GPU的移动SoC | OpenGL ES、Vulkan、CUDA | 统一内存、计算与图形互操作 |
| 国产嵌入式GPU | 自研或授权架构 | OpenGL ES、Vulkan、OpenCL | 驱动成熟度、扩展支持 |
图形API方面，OpenGL ES在嵌入式领域历史最久、兼容性最好，适合快速验证；Vulkan提供更显式的命令缓冲、内存管理和多线程能力，但调试复杂度更高；OpenCL/Vulkan Compute则用于通用计算与图形互操作。实际项目中，很多设备同时支持多套API，调试时要先确认应用实际走的是哪条路径。
五、案例与常见误区
某车载仪表项目在Mali GPU上出现“偶发花屏”，抓帧后发现某个中间Render Target在Tile resolve时被提前读取，导致部分Tile数据未完成写入。问题根因不是着色器，而是渲染顺序与同步对象使用不当。这类问题在TBR架构上很典型：CPU看到的“已完成”与GPU实际“已写回”并不等价。
常见误区：把桌面GPU的调试经验直接套到嵌入式GPU上。桌面GPU多为立即模式渲染（IMR），中间结果直接写显存；嵌入式GPU多为TBR/TBDR，中间结果在片上。忽略这一差异，容易误判带宽、同步和Render Target读取问题。
建立正确的GPU架构与管线认知后，后续的抓帧工具选择、性能计数器解读和故障树分析才有落脚点。建议在每台目标设备上先跑一个最小三角形或简单纹理案例，确认API路径、驱动版本和渲染模式，再进入复杂场景调试。