1. 从一次掉帧说起为什么需要理解 GPU 指令执行去年帮一个朋友看他的 UE 项目场景不算复杂一个室内展厅几盏动态光几块半透明玻璃结果在目标设备上跑起来帧率死活上不去GPU 时间稳定在 22ms 左右下不来。他第一反应是模型面数太高于是疯狂减面从 200 万砍到 80 万帧率几乎没动。这就是典型的没搞清楚瓶颈在哪就动手。后来我把他的材质逐个过了一遍发现问题根本不在面数而在于几个材质的 Pixel Shader 里塞了大量无谓的 ALU 运算——一堆可以提到 Vertex Shader 或者干脆烘焙掉的计算全堆在像素阶段每帧重复算。改完之后 GPU 时间降到 9ms 出头。这件事让我再次确认一个观点UE 的 Shader 优化本质上不是调参数而是理解 GPU 到底怎么执行你写的那些指令。这篇内容就是围绕这个核心展开的。我会从 GPU 的指令执行模型讲起把 ALU、寄存器、线程束这些概念用大白话拆开然后落到 UE 的 Shader 编译产物上告诉你哪些写法会浪费 ALU、哪些操作会拖累寄存器占用、为什么有时候看起来更简单的 Shader 反而更慢。适合已经能写材质、但对底层执行机制一知半解的技术美术和图形程序也适合想从会连节点进阶到知道为什么这么连的开发者。核心关键词就几个UE、Shader、GPU、ALU、寄存器。这几个词串起来就是一条从硬件到引擎再到你手上材质节点的完整链路。把这条链路打通优化才有方向不然就是瞎猜。2. GPU 执行指令的底层逻辑先搞懂它和 CPU 的根本差异2.1 GPU 不是更快的 CPU而是更宽的 CPU很多人第一次接触 GPU 编程会有一个误解觉得 GPU 就是核心更多、频率更高的 CPU。这个理解会直接导致优化方向跑偏。CPU 的设计哲学是低延迟它假设你有一堆逻辑复杂、依赖关系强的任务所以它花大量晶体管去做分支预测、乱序执行、大缓存目的就是让单条指令流尽可能不等待。一个 CPU 核心同一时刻真正并行执行的指令可能就几条但它把每条指令的延迟压得很低。GPU 的设计哲学完全相反是高吞吐它假设你有一大堆彼此独立、逻辑简单的任务比如几百万个像素各自算颜色所以它不追求单条指令快而是追求同一时刻有成千上万条指令在跑。代价就是单条指令的延迟很高一次内存访问可能要等几百个周期。这个差异决定了在 GPU 上隐藏延迟靠的是人多不是跑得快。你有足够多的独立任务填满执行单元延迟就被掩盖了任务不够多执行单元就空转。这就是为什么 GPU 优化里并行度永远是第一位的。2.2 线程、线程束与 SIMT 执行模型GPU 上最小的执行单元叫线程Thread但硬件从来不是一条一条执行线程的。它把线程按固定数量打包成一组NVIDIA 叫Warp通常 32 个线程AMD 叫 Wavefront通常 64 个UE 里你不太需要区分但概念要清楚。关键点在于同一个 Warp 里的所有线程在同一时刻执行的是同一条指令。这就是 SIMTSingle Instruction, Multiple Threads模型。32 个线程一起做加法一起做乘法一起访问内存。这带来一个非常要命的后果——分支发散Divergence。如果 Warp 里的线程因为某个 if 判断走了不同路径硬件没法同时执行两条路径只能先让一部分线程执行 A 路径、另一部分闲着再反过来执行 B 路径。两条路径的耗时相加而不是取最大值。我见过太多材质里写这种逻辑if (distance 100) { color ComputeFar(); } else { color ComputeNear(); }如果这个判断在屏幕上是一半近一半远的分布那这个 Warp 就要把两个分支都跑一遍。正确做法是尽量用lerp、step、smoothstep这类无分支写法让所有线程走同一条指令流float t step(100, distance); color lerp(ComputeNear(), ComputeFar(), t);注意这里ComputeNear()和ComputeFar()都会被求值看起来算得更多了但在 GPU 上这反而更快因为没有发散所有线程齐步走。这是 GPU 优化里反直觉但极其重要的一条。2.3 ALUShader 里真正干活的单元ALUArithmetic Logic Unit算术逻辑单元是 GPU 里负责做加减乘除、比较、位运算的硬件单元。你在材质里连的每一个数学节点最终都会变成 ALU 指令。一个 SMStreaming Multiprocessor流多处理器可以理解为一个 GPU 的小核心里通常有多个 ALU 分区每个分区每个周期能处理一定数量的指令。UE 的 Shader 编译统计里会给你一个Instruction Count指令数这个数字大致反映的就是 ALU 的工作量。但这里有个坑指令数不等于执行时间。因为 ALU 指令和内存访问指令Texture Sample、Load走的是不同的流水线它们可以重叠。一个 Shader 有 200 条 ALU 指令但只有 2 次采样可能比一个 50 条 ALU 但 8 次采样的 Shader 更快。所以看优化效果永远要结合具体瓶颈不能只盯指令数。2.4 寄存器Shader 性能的隐形天花板寄存器Register是 GPU 上最快的存储ALU 运算的操作数基本都来自寄存器。每个线程都有自己的一份寄存器但寄存器总量是固定的一个 SM 里寄存器文件就那么大。这就产生了一个核心矛盾一个 Shader 用的寄存器越多能同时驻留的线程就越少。举个具体例子。假设一个 SM 的寄存器文件是 65536 个这是常见规模每个线程用 32 个寄存器那这个 SM 最多能驻留 2048 个线程如果某个 Shader 每个线程要用 64 个寄存器那最多只能驻留 1024 个线程。线程数少了一半用来隐藏内存延迟的人手就少了一半一旦遇到采样等待执行单元就容易空转。这就是为什么寄存器压力Register Pressure是 Shader 优化的核心指标之一。UE 里你可以在 Shader 编译统计里看到寄存器使用情况或者在平台特定的分析工具里查看。寄存器占用过高往往不是因为算法复杂而是因为变量作用域太大编译器不敢复用寄存器中间结果太多同时活着的值太多循环展开过度每个迭代都占一份寄存器后面我会专门讲怎么压寄存器。3. UE Shader 编译链路你的节点是怎么变成 GPU 指令的3.1 从材质图到 HLSL中间发生了什么你在材质编辑器里连的节点并不是直接变成 GPU 指令的。中间要经过好几层材质图 → 材质表达式树编辑器把你的节点组织成一棵树。表达式树 → HLSL 代码UE 的材质编译器把树翻译成 HLSL 源码。这一步会做常量折叠、公共子表达式消除等优化。HLSL → 平台中间码通过平台的 Shader 编译器比如 DXC、FXC 或各平台的工具链编译成中间表示。中间码 → GPU 机器码驱动或平台工具做最终优化和指令调度生成 GPU 真正执行的机器码。关键认知你在材质图里看到的简洁不代表最终指令简洁。编译器会做很多你看不见的事有些优化很聪明有些则因为信息不足而保守。理解这条链路你才知道哪些优化该在材质层做哪些该交给编译器。3.2 指令数、寄存器数、占用率三个必须一起看的指标UE 的 Shader 编译统计在材质编辑器里点 Stats 或看平台输出会给你几个关键数字指标含义优化方向Instruction CountALU 等指令总数减少冗余计算合并运算Register Count每线程寄存器占用缩小变量作用域减少同时存活的值Texture Samples采样次数合并采样用图集降分辨率Occupancy理论线程驻留率由寄存器、共享内存等共同决定这三个指标是联动的。你减少指令数可能因为循环展开反而增加了寄存器你压寄存器可能因为拆分了计算而增加了指令。优化永远是权衡不是单点最优。我个人的经验是先看 Occupancy如果占用率已经很低比如低于 50%优先压寄存器如果占用率健康但指令数爆炸优先减 ALU。方向对了改起来才有效率。3.3 为什么看起来一样的两个 Shader 性能差很多这里举个我实际遇到的例子。两个材质功能都是基础色 × 光照 一张遮罩图控制高光肉眼看节点几乎一样但一个 GPU 时间 3ms另一个 5ms。差异出在一个细节慢的那个把遮罩图的采样放在了光照计算之后而且遮罩值参与了多个后续运算。编译器为了保留这个值给它分配了额外的寄存器导致整个 Shader 的寄存器占用从 28 涨到 41占用率掉了一档。快的那个把遮罩采样提前并且尽早把结果消费掉寄存器就压下来了。这个例子说明节点的顺序、值的生命周期会实实在在影响寄存器分配。这不是玄学是编译器寄存器分配算法的必然结果。理解这一点你就能主动去喂编译器更好的代码结构。4. 实操把 ALU 和寄存器优化落到具体材质上4.1 减少 ALU从能算到该不该算减少 ALU 的核心思路是能提前算的提前算能烘焙的烘焙能省的省。第一类常量计算提到 CPU 或材质参数。很多材质里会写sin(time * 2 3.14)这种如果2和3.14是固定的那time * 2 3.14里只有time是变量其余都是常量。编译器一般能折叠但如果表达式复杂到编译器不敢动就会每帧算。稳妥做法是把常量部分预先算好作为参数传进来。第二类顶点能算的别放像素。光照方向、视角相关的量如果变化频率低可以放 Vertex Shader 算完插值过去。像素阶段每帧要跑几百万次顶点阶段可能只有几万次差两个数量级。第三类用数学恒等式化简。比如pow(x, 2)直接写x * xnormalize如果已知长度就省掉开方。这些在高级 Shader 里是常识但在材质图里很多人不注意。第四类查表代替计算。复杂的三角函数、指数运算如果精度要求不高可以用一张小纹理查表。一次采样换几十条 ALU在 ALU 瓶颈的场景下很划算。4.2 压寄存器让值的寿命尽可能短寄存器优化的核心是缩短每个值的生命周期。一个值从被算出来到被最后使用这段时间它一直占着寄存器。寿命越短同时活着的值越少寄存器压力越小。具体做法就近计算就近使用。不要在一开始把所有中间量都算出来存着用到的时候再算。避免超长表达式。一个几百项的表达式编译器要同时保留所有中间结果寄存器直接爆。拆成几步每步算完就消费掉。复用变量。如果两个计算不会同时用到可以让它们共用寄存器编译器通常会自动做但代码结构清晰有助于它判断。控制循环展开。UE 里有些节点会触发循环展开次数越多寄存器占用越高。能用循环就用循环别手动展开。我实测过一个案例一个程序化噪声材质原本寄存器占用 56占用率只有 37%。把中间计算拆成三段、每段算完立即用掉之后寄存器降到 34占用率回到 62%GPU 时间降了约 30%。改动很小效果很明显。4.3 分支与循环GPU 上最贵的两种控制流前面讲过分支发散的问题。这里补充循环。GPU 上的循环如果迭代次数是编译期已知的常量编译器通常会展开如果是动态的就会保留循环结构。动态循环的问题在于循环体内的寄存器需求要乘以同时活跃的迭代数而且循环控制本身也要占指令。在 UE 材质里循环一般出现在 Custom 节点或者某些程序化节点里。我的建议是迭代次数固定且少比如 4 次以内展开没问题。迭代次数多或者动态尽量改成用纹理查表或者用数学近似。如果非要循环把循环体内的计算压到最简减少每次迭代的寄存器需求。提示UE 的材质编译器对 Custom 节点的优化能力有限因为它是黑盒。Custom 节点里写的 HLSL 如果结构不好编译器很难帮你救回来。所以 Custom 节点里的代码要格外注意寄存器和分支。4.4 采样优化ALU 之外的另一个大头虽然这篇重点是 ALU 和寄存器但采样和它们是联动的。一次纹理采样会占用寄存器来存结果还会触发内存访问。减少采样次数间接也减轻了寄存器压力。几个实用技巧合并通道把多张灰度图打包进一张图的 R/G/B/A 通道一次采样拿四个值。降低分辨率遮罩、噪声这类低频信息用低分辨率纹理采样缓存命中率更高。Mipmap 用起来远处物体用高 Mip减少采样带宽。避免依赖采样如果某个采样结果只用来做简单判断考虑用顶点数据或常量代替。5. 常见问题与排查实录5.1 帧率上不去但 GPU 时间也不高怎么回事这种情况通常是CPU 瓶颈或者同步等待。GPU 时间不高说明 GPU 没满负荷但帧率还是低那可能是Draw Call 太多CPU 提交命令来不及。Shader 编译卡顿首次遇到新材质时。GPU 和 CPU 之间有同步点比如 Readback 操作。排查方法用平台的 GPU 分析工具看时间线如果 GPU 有大段空闲基本就是 CPU 或同步问题跟 Shader 优化无关。5.2 减了指令数性能反而下降这通常是因为寄存器占用上升了或者占用率掉了。减少指令的某些手段比如手动展开、增加中间变量会增加寄存器压力。这时候要看整体不能只看指令数。还有一种可能是改变了瓶颈类型。原本是 ALU 瓶颈你减了 ALU结果变成采样瓶颈总时间没降甚至升了。优化要针对当前瓶颈瓶颈转移了就要换方向。5.3 同一个 Shader 在不同设备上表现差异巨大GPU 架构差异是根本原因。不同厂商、不同代际的 GPUALU 数量、寄存器文件大小、缓存策略都不一样。一个在高端卡上跑得飞起的 Shader在移动端可能因为寄存器不够而占用率暴跌。应对策略针对目标设备做优化别拿开发机当唯一标准。移动端尤其要注意寄存器因为移动 GPU 的寄存器文件通常更小。UE 的移动渲染路径Mobile Preview能帮你提前发现问题。5.4 常见问题速查表现象可能原因排查方向GPU 时间高帧率低ALU 或采样瓶颈看指令数和采样数GPU 时间不高但帧率低CPU 瓶颈或同步看 GPU 时间线空闲减指令后更慢寄存器上升或瓶颈转移看寄存器数和占用率移动端比 PC 慢很多寄存器不足或带宽限制移动预览 降精度特定视角卡顿分支发散或缓存失效检查视角相关分支5.5 几个我踩过的坑坑一迷信节点少就是快。节点少不代表指令少一个复杂节点可能展开成几十条指令几个简单节点组合反而更优。要看编译后的统计不要看节点数量。坑二忽略精度。UE 里float和half的选择对移动端影响很大。half占的寄存器更少ALU 吞吐也可能更高。能用half的地方别用float。坑三在像素阶段做顶点该做的事。这个前面说过但真的太多人中招。任何每个像素都算一遍但结果其实只跟顶点有关的计算都应该往上提。坑四Custom 节点当万能药。Custom 节点灵活但编译器优化能力弱而且容易写出寄存器爆炸的代码。能用内置节点组合出来的尽量别用 Custom。6. 一套可复用的 Shader 优化检查流程把上面的内容整理成一套流程下次遇到性能问题可以照着走第一步定位瓶颈。用 GPU 分析工具看时间分布确认是 ALU、采样、带宽还是 CPU。别猜看数据。第二步看三个指标。指令数、寄存器数、占用率。占用率低优先压寄存器指令数高优先减 ALU。第三步检查分支和循环。有没有视角相关的分支有没有动态循环能无分支化的无分支化能查表的查表。第四步检查值的生命周期。中间结果是不是活得太久能不能就近算就近用表达式能不能拆短第五步检查精度和采样。该用 half 的用 half该合并的采样合并该降分辨率的降。第六步在目标设备上验证。开发机跑得好不算数目标设备尤其是移动端才是标准。这套流程我自己用了很多次基本能覆盖 80% 的常见问题。剩下的 20% 往往是引擎层面的坑比如渲染路径选择、后处理叠加、材质域设置等那些需要结合具体项目分析。最后分享一个我个人的习惯每次做完一个材质我都会习惯性看一眼编译统计把指令数和寄存器数记下来。时间长了你对什么样的写法大概是什么开销会有直觉。这种直觉比任何工具都值钱。Shader 优化说到底是个经验活而经验的来源就是一次次把底层原理和实际现象对上号。GPU 怎么执行指令这件事想明白了UE 里那些材质节点在你眼里就不再是黑盒而是一行行可以推敲的指令。