嵌入式GPU编程实战：计算着色器、性能优化与Jetson开发

提起嵌入式GPU编程，很多人第一反应是：这不就是把显卡编程搬到嵌入式板子上吗？这句话对了一半。GPU确实是那颗GPU，但嵌入式环境里的存储模型、功耗墙、驱动差异和工具链，跟你在PC上写CUDA或者OpenGL完全是两种玩法。我这些年陆续在手机SoC、车机方案、NVIDIA Jetson这类核心板上做过图像处理、视觉算法和端侧AI的落地，最大的体会是：嵌入式GPU编程真正的门槛不是语法，而是你得先搞清楚自己到底在哪个GPU上、用哪一层软件栈、为哪一路数据做优化。这篇文章会把嵌入式GPU编程的几条路径拆开讲一遍，覆盖概念、硬件平台、计算着色器细节、性能优化方法和常用工具链，尽量给你一套可以直接上手的认知框架。

1. 嵌入式GPU编程到底是什么

1.1 同名帽子底下是三条技术路线

嵌入式GPU这个词，说到底是个筐。第一类最常见的，是手机、平板、车机、智能座舱以及各种IoT媒体设备里的SoC集成GPU。典型代表是ARM Mali、高通Adreno、Imagination PowerVR，今天绝大多数Android设备、不少车机系统的图形和计算，都跑在这些单元上。第二类是核心板或模组上带着一颗相对完整的GPU，最典型就是NVIDIA Jetson系列，能跑完整CUDA栈，广泛用在机器人、边缘AI、视觉检测设备上。第三类其实更偏概念延伸，指把桌面级GPU能力往嵌入式场景迁移，比如一些工业主板搭配独立低功耗GPU，或者带大核GPU的异构SoC。

这三条路线都叫嵌入式GPU，但驱动模型、编程方式、踩坑点完全不同。你要是把手机上的开发经验直接搬到Jetson上，会发现不少基础假设不成立；反过来，拿着完整CUDA优化经验去调Mali，也可能死得很难看。这篇文章重点放在最普遍的两类：一类是SoC内置GPU上的图形和通用计算，主要通过OpenGL ES或Vulkan的计算着色器来写；另一类是Jetson这类嵌入式GPU模组，用CUDA做并行计算。两条路线我都实际做过，下面讲的基本都是项目里趟过的经验。

1.2 与桌面GPU编程的三大本质差异

嵌入式GPU和桌面GPU之间有三条硬区别，理解了这三条，后面很多优化决策就顺理成章了。

第一，嵌入式GPU没有独立显存。桌面显卡有自己的专属GDDR显存，带宽动不动就几百GB/s，而手机SoC上的GPU和CPU共享同一块LPDDR内存，常见带宽也就几十GB/s量级，Jetson系列稍微好一些，但同样不是GPU独享。这意味着嵌入式GPU编程中，内存访问模式几乎决定了性能上限。你写的任何Kernel，本质上都是在跟CPU、NPU、编解码器抢同一份内存带宽。

第二，功耗和热是硬墙。手机GPU的持续功耗一般压在4到8W，散热稍微差一点的设备，冲到十几瓦附近就开始降频。Jetson这类模组虽然允许的功耗范围更大，但也有严格的散热限制。很多优化手段的终极目标并不是让GPU算得更快，而是让它在算同样数据时消耗更少的带宽和功耗，从而稳定在更高的频率点附近。

第三，渲染架构的差异。移动端主流的Mali、Adreno、PowerVR都是Tile-Based架构，也就是基于小块的渲染架构，PowerVR的叫法更特殊一些，叫TBDR。GPU不是把整个画面直接画到显存，而是先把渲染目标切成一个个小tile，在片上高速缓冲里完成计算后再写回主存。这对图形渲染的影响非常直接：RenderPass内部的临时数据最好留在片上，频繁在Pass之间读写全屏纹理，反而会触发主存回写，性能非常难看。这一点在计算着色器上同样有影响，因为它决定了你对“读写一张全屏图像”这件事的代价判断。

提示：很多人第一次做嵌入式端GPU优化，拿着PC上“整套链路生成几十层中间纹理”的思路来套，结果发现帧率惨不忍睹，根本原因就是忽略了共享带宽和Tile架构的双重约束。

2. 从硬件到API：嵌入式GPU的产品地图

2.1 四类平台与它们的技术脾气

嵌入式GPU硬件平台，我习惯用下面这张表来梳理，在选型和预判问题时非常方便。

实际项目里，设备数量最多的还是Mali和Adreno，因为Android生态没办法挑芯片，算法往往要能在两家GPU上同时跑。这两家的脾气差异相当明显。Mali对工作组大小和寄存器使用很敏感，稍不注意就掉性能；Adreno对内存布局相对友好，但驱动偶发问题比Mali多一些。我的通常做法是：图形层优先使用Vulkan，纯计算类任务也优先走Vulkan计算管线。

2.2 API选型：为什么我建议优先走Vulkan计算管线

在SoC内置GPU上，当前主流计算入口有OpenGL ES 3.1/3.2的计算着色器、Vulkan计算管线、OpenCL，如果做iOS还得加一个Metal。我的建议很直接：如果产品只做Android，且是从零开始的新项目，优先选Vulkan。原因不是Vulkan在每个设备上都更快，而是它能提供更清楚的内存控制、更明确的barrier语义、以及更细的同步控制。对于嵌入式这种对性能和功耗都很敏感的场景，这些可控性是后期优化的底气。

但这不是说OpenGL ES 3.1计算着色器没价值。前期验证算法逻辑、快速做原型时，GLES的开销小很多，管线搭建快，调试工具也更顺手。尤其当你的产品还有一些老设备需要兼容时，GLES可能是唯一能在所有目标机型上稳定跑完整链路的方案。我自己的项目里经常是两套并存：一套GLES原型用来验证算法，一套Vulkan版本用来收敛性能。

Vulkan不一定在所有嵌入式设备上都比GLES快。有些老Mali驱动的Vulkan实现并不完善，同样的计算shader反而跑不过GLES 3.1版本。所以选API之前，先到目标芯片的白皮书和驱动发布说明里确认支持程度，别在立项时想当然。

3. 计算着色器核心细节：线程、内存与同步

3.1 线程模型与local_size选择

计算着色器与图形着色器最大的差异在线程模型。你写的是一个个invocation，但GPU实际调度时，会把它们分组执行。硬件每次发射一组指令给执行单元，组内所有invocation执行同一条指令。遇到分支时，同一执行组里部分invocation走A路径、部分走B路径，那就只能把两条路径都跑一遍，不走的线程被掩蔽掉。这就是分支发散。

移动端GPU的分支发散代价比很多人想象中大。尤其Mali这类面向能效优化的架构，它对分支和复杂控制流的容忍度比较低。代码里一旦出现基于gl_GlobalInvocationID取模后的分叉逻辑，性能波动会很明显。解决发散问题的办法通常是两条路：能把分支往外提就往外提，比如传一个uniform控制所有invocation走同一方向，避免intra-wave发散；如果确实需要逐元素决策，可以改用数值方法把两条路径合并成同一个表达式。

local_size的选择也需要单独说。我发现很多人照搬桌面GPU的习惯，上来就写layout(local_size_x = 256)甚至512。问题是移动GPU和桌面GPU的调度资源差别很大，桌面CUDA里常用的occupancy优化思路，在移动端并不能简单平移。local_size设得大，每个工作组占用的寄存器资源也高，可能引发寄存器溢出；设得小，又可能无法填满硬件执行单元。最稳妥的办法是在目标设备上跑一组对比实验，从64到256，分几档观察耗时，而不是凭直觉选一个好看的数字。

3.2 shared memory的容量、barrier与内存屏障

计算着色器里可以用shared memory，也叫group shared memory或local memory，让一个工作组内的invocation交换数据，速度比走全局内存快得多。但在嵌入式GPU上，shared memory并不是无限供应的。Vulkan规范里有个maxComputeSharedMemorySize参数，由设备自己决定，很多移动GPU的上限在16KB到32KB之间。我建议在下发一个使用大块shared memory的Kernel之前，先在目标设备上查一下这个上限，千万别在PC上写好了直接搬过来。桌面显卡动辄给到48KB甚至更高，很容易让你产生“shared memory很大”的错觉。

shared memory的同步必须显式调用barrier。GLSL里是barrier()，作用是在当前工作组内做执行屏障，确保所有invocation都执行到同一位置后才继续往下走。这里有个最常见的坑：把barrier()写在条件分支里。当组内不同invocation对bool值的判断不一致，一部分线程进入分支等屏障，另一部分线程根本没进分支，执行就会卡死或者产生未定义行为。GLSL规范要求barrier必须被组内所有invocation执行到，所以它只能出现在uniform control flow中。

另一个容易忽视的点是内存屏障。barrier只保证执行顺序，不保证内存可见性。如果你在shared memory里写数据，然后barrier，又去读另一个invocation刚写的内容，通常还需要一个memoryBarrierShared()来确保写操作对其他invocation可见。实际开发里还有更隐蔽的情况：同一个shader里既有shared memory的读写，又有imageStore操作，如果缺少对应的内存屏障，某些invocation读到的是旧值，图像上就会出现一种非常难查的随机花屏。

3.3 一个能直接跑起来的高斯模糊示例

这里写一个非常经典的GLES 3.1计算着色器示例，用来做两趟分离高斯模糊的水平方向。注意这个shader故意用了最基础的imageLoad/imageStore，目的是把内存访问的代价讲清楚，后续你可以根据自己的设备情况换成采样器版本。

#version 310 es layout(local_size_x = 256) in; layout(binding = 0, rgba8) readonly uniform highp image2D uInput; layout(binding = 1, rgba8) writeonly uniform highp image2D uOutput; uniform ivec2 uSize; uniform bool uHorizontal; const float kernel[5] = float[5]( 0.227027, 0.1945946, 0.1216216, 0.054054, 0.016216 ); vec3 loadPixel(ivec2 pos) { return imageLoad(uInput, clamp(pos, ivec2(0), uSize - ivec2(1))).rgb; } void main() { ivec2 pos = ivec2(gl_GlobalInvocationID.xy); if (pos.x >= uSize.x || pos.y >= uSize.y) { return; } vec3 result = imageLoad(uInput, pos).rgb * kernel[0]; for (int i = 1; i < 5; i++) { if (uHorizontal) { result += loadPixel(pos + ivec2(i, 0)) * kernel[i]; result += loadPixel(pos - ivec2(i, 0)) * kernel[i]; } else { result += loadPixel(pos + ivec2(0, i)) * kernel[i]; result += loadPixel(pos - ivec2(0, i)) * kernel[i]; } } imageStore(uOutput, pos, vec4(result, 1.0)); }

这个例子有几个点想强调一下。首先是分离高斯。二维高斯是可分离的，所以先做一遍水平模糊，再做一遍垂直模糊，得到的结果和一次二维卷积等价，但采样次数大幅下降。嵌入式平台的带宽非常宝贵，能用两次一维卷积解决的问题，绝不做一个完整的二维Kernel。

其次是边界处理。用imageLoad读越界坐标时，返回的是零值而不是边缘像素，这会导致画面边缘明显发黑。所以我在loadPixel里主动clamp坐标，把越界读变成边缘像素的重复，效果类似采样器里的CLAMP_TO_EDGE。如果你改用sampler2D配合texture()读取，同时把采样器的寻址模式设置成CLAMP_TO_EDGE，边界问题就不需要手动处理了，而且纹理管线通常比imageLoad的缓存友好度更高，缺点是不能再写入非绑定的输出纹理。

最后是uHorizontal这个uniform方向开关。因为它不是逐invocation变化的，整个工作组内的判断是一致的，所以不会产生分支发散。水平Pass和垂直Pass共用一个shader，只是uniform状态不同，减少代码维护成本。

4. 嵌入式GPU性能优化的关键指标与手段

4.1 内存带宽才是第一瓶颈

做嵌入式GPU优化，第一步不是打开Profiler看ALU占用率，而是先数一遍：每个像素的数据在这条处理链路上被访问了多少次？每次访问要消耗多少字节？一张1080P的RGBA8纹理大约是8.3MB，如果后处理链路里有三张这样的中间纹理、每张被读写两次，那光中间结果的带宽开销就到50MB以上。再按照设备30到60fps的目标去估算，这部分消耗占整体GPU带宽预算的比例会高得惊人。

所以很多看似“GPU很忙”的性能问题，实际根本不是GPU计算能力不够，而是内存带宽被吃满了。判断方法也简单：把Kernel里的运算逻辑精简到极致，帧率没有明显变化，或者Profiler显示内存读取量远高于理论最低值，那就基本可以确认瓶颈在带宽。

知道了这个前提，优化方向就清晰了。能用低精度绝不用高精度，比如RGBA8能表达的信息就不要用RGBA32F；能少一次中间写就少一次，比如把多个图像算子合并到一次Pass里，而不是每个算子都产生一张新纹理；能用硬件压缩帧缓冲格式的，尽量使用AFBC、UBWC这类片上压缩机制。这些手段的核心只有一个：降低主存访问量。

4.2 常见优化手段速查表

下面这些手段是我在项目里反复使用、验证有效的，按优化目标整理成了一张速查表。

这里特别提一下“一个invocation处理多个像素”的思路。移动端GPU在调度大量细粒度任务时，本身就有不小的固定开销。让一个线程沿着水平方向连续处理两到四个像素，能用更好的空间局部性摊薄调度成本，同时提高内存访问的连续性，对带宽利用率的改善非常明显。代价是代码稍微复杂一点，尾部不足一个线程宽度的区域需要额外处理。

4.3 occupancy、寄存器与分组大小的取舍

桌面CUDA生态里，occupancy是一个很常用的性能指标，但在移动端GPU上，一定要谨慎地对待它。移动GPU硬件的执行宽度、寄存器堆大小、调度策略跟桌面GPU完全不同，在桌面上把occupancy拉满往往能隐藏内存延迟，在移动端却可能因为每线程占用资源过高而触发寄存器溢出，反而掉性能。

我在一个Mali G78设备上调Kernel时遇到过很典型的例子：同样一份直方图统计逻辑，local_size_x设为128时，每线程寄存器占用很低，吞吐稳定；改成256后，单个工作组的资源需求暴增，调度器无法有效排满执行单元，整体反而慢了一截。后来我在别的芯片上也复现过类似现象，结论是local_size并不是越大越优。

所以，关于分组大小，我给一个简单可操作的建议：算法原型阶段就把local_size做成可配置的参数，在目标设备上分别跑64、128、256三组测试，记录吞吐和耗时。哪个数据好，就选哪个。不要觉得调参麻烦，这种十几分钟的实验，往往比凭经验改半天shader逻辑更有效。

5. 调试与性能分析工具链

5.1 跨厂商的帧调试与GPU计数器工具

嵌入式GPU开发里，最怕的就是在两块不同芯片上看到完全不同的现象。RenderDoc是跨平台的帧调试工具，支持Vulkan和GLES，可以通过Android加adb连接设备抓帧。它的好处是能帮你看到每一次dispatch、每个descriptor绑定、每张资源图在Kernel执行前和执行后的内容，非常适合用来验证算法的数据流是否正确。

另一个值得装的是Android GPU Inspector，也就是AGI。它能同时抓取Mali、Adreno以及部分其他GPU的底层硬件计数器，比如着色器周期、纹理单元利用率、内存读取量这些关键数据。实际做性能分析时，我会先用RenderDoc确认“算得对不对”，再用AGI确认“慢在哪里”。两步分开走，能少走很多弯路。

提醒：不要在还没确认数据流正确之前就急着做性能分析。GPU出问题的表现经常是花屏、黑屏、错位，但这些症状背后可能是边界条件、资源生命周期或者同步问题，直接去分析性能只会浪费大量时间。

5.2 厂商级工具与Jetson的Nsight组合

如果你的目标平台集中在ARM Mali上，很值得学习ARM Streamline Performance Analyzer。它能够拿到比通用工具更细粒度的Mali内部stall原因、L2缓存命中率、执行引擎利用率等数据。高通平台则主要用Adreno GPU SDK配合RenderDoc和自定义timestamp来做分析。厂商工具的学习成本不低，但碰到通用Profiler解释不了的怪问题时，它们往往能直接揭示答案。

到了NVIDIA Jetson这条线，工具链就清晰很多。Nsight Systems适合看整个应用的时间线，包括CPU和GPU的同步等待、内存传输、kernel启动开销；Nsight Compute适合对单个CUDA Kernel做深度分析，可以查occupancy、内存吞吐、指令混合、warp stall原因，非常直观。再加上tegrastats看实时功耗和温度曲线，基本能覆盖Jetson上层应用的所有性能排查场景。

这些工具本身不复杂，真正的难点是培养“先看计数器再猜原因”的习惯。我见过不少新手，Kernel一慢就打开代码开始猜，猜中就算运气好，猜不中就反复瞎改，最后越改越乱。嵌入式GPU调试更像是做排查实验：一次只改一个变量，通过Profiler数据验证结果，而不是靠灵感。

6. Jetson这些GPU模块的编程路径差异

6.1 CUDA在嵌入式模块上的编程体验

如果你在手机SoC上写计算着色器一段时间后再去看NVIDIA Jetson，会发现编程体验完全不同。Jetson上跑的是NVIDIA完整GPU架构，支持全套CUDA栈，你可以直接写CUDA C++ Kernel，能用cuBLAS、cuDNN、TensorRT这些成熟库，开发效率高很多。跟手机GPU相比，Jetson的GPU行为更像桌面GPU，调度更可预测，调试门槛也低不少。

对很多做机器人和边缘视觉的团队来说，Jetson这条路径的上手成本远低于在Mali上做通用计算。原因很简单：CUDA生态的资料太丰富了，社区里能搜到几乎所有常见问题的答案。而在Mali或Adreno上用Vulkan写计算着色器，很多问题只能在厂商的技术论坛和晦涩的文档里慢慢找。

但Jetson本质上仍是嵌入式平台，内存带宽有限，CPU与GPU共享同一物理内存。这意味着你在PC上习以为常的cudaMemcpy行为并不一定是好方案。数据量不大时，直接让GPU和