GPU着色器性能优化实战技巧

可视化演示

动态演示GPU着色器性能优化实战技巧的核心机制，通过输入/处理/存储/输出四种模式展示关键概念与交互流程。

ALU指令开销——灶台上的刀工

后厨里最勤快的岗位是灶台。切丝、焯水、爆炒，每个动作都要真金白银的时间。同样一道宫保鸡丁，老师傅三刀切完，新手下锅前还要翻出雕花刀法显摆一圈——菜是更好看，可排队的客人等不起。着色器里的ALU指令，就是灶台上的这些动作：越少，出菜越快。

GPU执行着色器时，每一行数学计算（加减乘除、三角函数、幂运算）都会被编译成一条或多条ALU指令。顶点着色器处理每个顶点，片元着色器处理每个像素，这些计算是流水线上最频繁的动作。程序员随手写下的pow、sin、sqrt，在移动端GPU上可能比普通乘法贵几十倍。

优化的第一个方向是“化简刀法”。利用三角恒等式把多个昂贵函数合并成一个；把逐像素重复的计算提到顶点阶段，让GPU只算一次再插值；对颜色、UV这类对精度不敏感的数据使用half（半精度）类型——移动端GPU的half吞吐往往是float的两倍。下面这个恒等式是化简的经典例子：

灶台的刀工省下来了，锅就能多颠几下、多出几道菜。着色器里类似的化简可以一个材质一个材质地做，积少成多，帧率自然回升。

纹理采样优化——冷库取料要省着跑

灶台旁修了一座大冷库。取肉、拿菜、回灶台，一来一回的时间够在案板上切完一整盘。最怕的是厨师明明只需要一点肉末，却每次都搬出整扇排骨在灶台上解冻。GPU世界里，这座冷库就是显存和纹理单元：一次采样不只是“读个数”，而是把纹素从显存搬到片上，再做双线性或三线性过滤。

纹理采样在GPU流水线里是出了名的“慢动作”。ALU计算在寄存器里直接完成，而采样要过缓存、走显存带宽，还可能没命中缓存，延迟完全不是一个量级。所以同样的效果，能用计算拼出来的尽量别采样；必须采样的，就要想办法让每次采样“少搬点东西”。

最有效的三板斧：一是MIP贴图，远处和倾斜的表面自动取低分辨率层级，单次带宽骤降；二是纹理压缩格式（移动端用ASTC/ETC），带宽和显存占用都能砍半；三是把多个小纹理合成一张图集，减少状态切换。MIP层级怎么选，由屏幕空间梯度决定：

冷库门开得越少、每次拿得越精准，灶台就能一直转不停。纹理带宽也一样——带宽不爆，GPU的其余单元才喘得过气。

动态分支处理——加辣不加辣的分岔路口

后厨接到十份同样的盖饭外卖，九个要辣、一个不要。聪明的厨师不会给每份单独开火：他先把辣的和不辣的分开排队，同一锅出的都是同一种口味。但如果订单混合排成一队，每份都得在“要不要加辣”上犹豫一下，整排锅都得停下来等那位犹豫的客人。

GPU的SIMT架构正是这样：一个线程束（warp）里32个像素被同一套指令驱动。代码里写if (x > 0.5) ... else ...，只要这32个像素里有一个往左走、其余往右走，GPU就得把左右两条路都执行一遍，再按掩码合并结果。这就是“动态分支发散”的代价——不是选择，而是加法。

优化思路有三条：一是提高分支一致性，把条件相同的像素或几何尽量分到同一个批次；二是用小分支替换大分支，把可预测的步骤化简；三是用数学技巧消灭分支，比如用smoothstep、lerp做渐变过渡，而不是生硬的if。要不要保留一个分支，可以用期望开销模型来算：

让口味一致的订单排在同一队，整排灶台就能全速前进。把发散的分支改成一致的数学过渡，GPU的指令流水线也就不会再“两头空转”。

寄存器压力管理——案板空间的精打细算

每个灶台前只有一块案板。备菜时食材摊得太多，案板放不下，就得把暂时用不上的食材堆到身后的架子上——每次要用都得伸手去够，一来一回全是额外动作。GPU着色器里的寄存器，就是这块案板。

着色器运行时，局部变量、中间计算结果都住在寄存器里。寄存器的总量是硬件定死的，每个线程能分到的数量有限。程序员如果同时声明太多变量、让中间量活得太久（生命周期过长），编译器就会把一部分变量“溢出”（spilling）到本地内存，访问速度一下子慢几十倍。

管理手法：缩短变量生命周期，用完一个丢一个；合并可复用的中间量；拆分长表达式，别让几十个临时量同时活着；避免在像素阶段展开过大的循环。这些做法的最终目的，是提高占用率（occupancy）——让更多线程能同时驻留，用并行隐藏延迟。占用率与寄存器用量的关系很直接：

案板清爽，备菜就能流水线作业；寄存器清爽，SM里就能多驻留一批线程，等纹理数据时其他线程照常干活，GPU就不容易“干等”。

调试工具定位——带秒表的后厨巡查员

后厨一乱，光靠经验猜不出哪里慢。有经验的大店会请一位巡查员，拿着秒表和录像机站在角落：把顾客从下单到上菜的每一道工序计时、录像，再慢放回看——是灶台空转？冷库排队？还是传菜通道堵塞？GPU世界的这位巡查员，叫RenderDoc。

RenderDoc是图形开发最常用的帧调试与性能分析工具。它可以捕获一帧渲染画面和全部命令流，回放任意一条DrawCall，查看顶点/片元着色器的输入输出、资源绑定状态，还能读GPU性能计数器和时间戳，把“感觉卡”变成“数据卡”。

排查步骤：捕获一帧；按GPU耗时给DrawCall排序，找出最贵的那几个；打开对应着色器的性能统计，看ALU、纹理采样、内存访问各占多少；用比例公式量化瓶颈类型——ALU-bound还是bandwidth-bound，决定不同的优化方向：

巡查员的秒表不会说谎。优化有了数据支撑，就不必再“拍脑袋改代码”，每一次改动都能在回放里看到帧时变化，效率高得多。

移动端实战——省电的移动餐车

移动端的GPU不是大饭店，更像一辆移动餐车：灶台小、发电机（电池）有限、还不能过热。同样的菜单在固定大厨房里没问题，搬上餐车就得精打细算——宁可少出两道硬菜，也要保证排队顾客每份都能热乎端出。

移动端GPU的功耗大头是带宽和像素填充。屏幕分辨率高、半透明层叠多（Overdraw严重）、纹理全用RGBA未压缩格式，都会让带宽和功耗爆炸；一旦芯片过热降频，帧率立刻雪崩。所以移动端优化的目标不是“极限画质”，而是“在功耗预算内稳住帧率”。

常用招数：开启Early-Z让被遮挡的像素在着色前就被剔除，减少Overdraw；纹理统一用ASTC/ETC压缩；复杂光照烘焙到光照贴图，运行时只做插值；再配合自适应分辨率——帧时超了，就按比例降低渲染分辨率，像素量按平方缩减，帧时迅速回落：

移动餐车不追求满汉全席，但求每单都不糊锅、不断电。合理的LOD、压缩和分辨率策略，能让手机在发热降频前稳稳跑满帧，玩家体验和电池寿命两头都保住。

AI 应用场景

Python 演示

class GpuShader:    def __init__(self, alu_ops=0, tex_samples=0, branch_div=0.0, regs=0):        self.alu_ops = alu_ops        self.tex_samples = tex_samples        self.branch_div = branch_div        self.regs = regs     def estimate_cycles(self):        alu_cost = self.alu_ops * 1.0        tex_cost = self.tex_samples * 4.0        branch_cost = 1.0 + self.branch_div * 2.0        reg_cost = self.regs / 32.0        return (alu_cost + tex_cost) * branch_cost + reg_cost     def diagnose(self):        tips = []        if self.alu_ops > 16:            tips.append("ALU偏重: 尝试half精度或三角恒等式化简")        if self.tex_samples > 4:            tips.append("采样偏多: 考虑MIP层级与纹理合并")        if self.branch_div > 0.3:            tips.append("分支发散高: 按分支条件分组绘制")        if self.regs > 64:            tips.append("寄存器压力大: 缩短变量生命周期")        if not tips:            tips.append("开销均衡, 继续观察")        return tips  def main():    before = GpuShader(alu_ops=24, tex_samples=6, branch_div=0.5, regs=80)    after = GpuShader(alu_ops=12, tex_samples=3, branch_div=0.1, regs=48)    for name, shader in (("优化前", before), ("优化后", after)):        print("===", name, "===")        print("预估周期:", round(shader.estimate_cycles(), 1))        for tip in shader.diagnose():            print("-", tip)    bt = before.estimate_cycles()    at = after.estimate_cycles()    print("=== 提速 ===")    print("帧率提升约:", round(bt / at, 2), "倍")  if __name__ == "__main__":    main()

1. self.tex_samples = tex_samples记录每个像素的纹理采样次数，对应“冷库取料次数”。
2. tex_cost = self.tex_samples * 4.0一次采样折算4个ALU周期，因为要搬显存数据还要做过滤。
3. branch_cost = 1.0 + self.branch_div * 2.0发散率越高，整体开销按倍数放大，体现“两条路都要走”。
4. reg_cost = self.regs / 32.0寄存器越多，对占用率的侵蚀越大，对应案板被摊满。
5. if self.regs > 64:超过64个寄存器通常已逼近移动端上限，提示压缩变量生命周期。
6. before = GpuShader(alu_ops=24, tex_samples=6, branch_div=0.5, regs=80)构造优化前的高开销着色器，四项指标全部超标。
7. bt / at用优化前后预估周期之比衡量提速倍数，让优化效果一目了然。

常见误区

面试题