1. 从一次移动端掉帧说起为什么要懂 GPU 执行指令去年帮一个朋友看他的 UE 移动端项目场景不大一个角色加几个特效在 PC 上跑得飞起一到中端安卓机上就掉到二十几帧。他第一反应是“模型面数太高”把角色从五万面砍到两万面帧数几乎没动。后来我让他把材质里的一个多层混合的 Shader 简化了一下帧数直接回到五十多。问题根本不在几何而在像素着色器里那堆 ALU 指令。这件事特别典型。很多人做 UE 优化习惯盯着 Draw Call、面数、贴图尺寸这些“看得见”的指标却忽略了 GPU 内部真正在干什么。Shader 优化这件事如果你不理解 GPU 是怎么执行指令的就只能靠猜——猜哪个节点贵、猜哪个分支拖后腿改来改去全凭玄学。而一旦你搞明白了 ALU、寄存器、指令发射这些底层概念你会发现优化方向一下子清晰了哪些操作是“免费”的哪些是“昂贵”的为什么有些写法看着简单实际很重为什么有些看着复杂反而更快。这篇内容就是想把这条链路讲透。从 GPU 执行一条 Shader 指令的完整流程说起聊到 UE 里 Shader 编译后的指令构成再落到具体的优化手段和实操排查方法。适合已经能写材质、但对底层执行机制一知半解的朋友也适合做移动端性能优化、想搞清楚“为什么慢”的从业者。我不会堆一堆术语吓人而是尽量用生活化的类比把原理讲明白再配上可以直接抄的排查步骤和参数判断方法。核心关键词就几个UE、Shader、GPU、ALU、寄存器。这几个词串起来就是一条从“你写的材质节点”到“显卡实际执行”的完整链路。把这条链路打通Shader 优化就不再是碰运气。2. GPU 到底怎么执行一条 Shader 指令2.1 从材质节点到机器指令一条指令的诞生你在 UE 材质编辑器里连的那些节点最终会经过编译器变成 GPU 能读懂的机器指令。这个过程大致分几步材质图先被翻译成 HLSL 中间代码然后由平台的 Shader 编译器比如移动端的 Mali 或 Adreno 编译器编译成目标 GPU 的指令集。你在编辑器里看到的节点数量和最终生成的指令数量往往不是一回事。举个直观的例子。一个Multiply节点加一个Add节点看起来是两个操作编译后可能就是一条乘加指令FMAFused Multiply-Add。而一个Power节点看着就一个实际可能展开成好几条指令因为 GPU 通常没有单条幂运算指令得用对数和指数组合实现。这就是为什么“节点少”不等于“指令少”。理解这一点很关键优化的对象是编译后的指令不是材质图上的节点。UE 提供了查看编译结果的手段后面会讲怎么用。2.2 ALU 是什么GPU 里的“计算工人”ALU 全称 Arithmetic Logic Unit算术逻辑单元。你可以把它想象成工厂流水线上的工人专门负责加减乘除、比较、位运算这些活。GPU 里 ALU 的数量非常多成百上千个这也是 GPU 擅长并行计算的原因——同一时间有大量工人各干各的。但工人再多活也是有成本的。每条 ALU 指令都要占用一个发射周期。如果一个像素着色器里有 200 条 ALU 指令而屏幕上有 200 万个像素要着色那就是 4 亿次 ALU 操作。移动端 GPU 的 ALU 吞吐量有限这个数字很容易就撑爆帧预算。所以 Shader 优化的一个核心目标就是减少每个像素需要执行的 ALU 指令数。注意是“每个像素”不是“整个 Shader”。一个只在顶点着色器里跑一次的复杂计算和一个在像素着色器里跑几百万次的计算代价完全不是一个量级。2.3 寄存器GPU 的“临时工作台”寄存器是 GPU 里速度最快的存储比显存、比 L1 缓存都快。ALU 做运算时操作数得先从寄存器里取算完的结果也得写回寄存器。你可以把寄存器理解成工人手边的工作台——台子越大能同时摆的零件越多工人干活越顺台子不够就得频繁去仓库显存取东西速度立刻掉下来。这里有个关键概念叫寄存器压力Register Pressure。一个 Shader 用的寄存器越多能同时驻留在 GPU 上的线程就越少因为寄存器总量是固定的。线程少了GPU 就没法用足够的并行度去掩盖内存访问的延迟性能就下来了。在移动端尤其明显。移动 GPU 的寄存器文件通常比桌面小得多一个 Shader 如果寄存器占用超标编译器会开始“溢出”Spill把本该放寄存器的数据挪到更慢的存储里性能断崖式下跌。这也是为什么移动端 Shader 要尽量写得“轻”。2.4 指令发射与延迟隐藏为什么并行度这么重要GPU 执行指令不是一条接一条串行跑的。现代 GPU 采用 SIMD单指令多数据架构一组线程通常 32 或 64 个叫一个 Wave 或 Warp共享同一条指令但各自处理不同数据。指令发射器每个周期挑一条准备好的指令发出去。问题在于内存访问的延迟很高——从显存取一个纹理样本可能要等几百个周期。如果这时候没有别的指令可以发射ALU 就闲着性能浪费。GPU 靠什么掩盖这个延迟靠同时驻留大量线程一个线程等内存的时候切换到另一个线程干活。而能驻留多少线程直接受寄存器用量影响。寄存器用得多能驻留的线程就少延迟隐藏能力就弱。这就把前面说的寄存器压力和性能联系起来了寄存器多 → 驻留线程少 → 延迟藏不住 → 性能差。这条因果链是 Shader 优化的底层逻辑之一。2.5 纹理采样与 ALU 的取舍很多人有个误区觉得纹理采样一定比计算贵。其实不一定。在移动端一次纹理采样Texture Fetch的代价和几条 ALU 指令差不多甚至更便宜。所以有时候把复杂的程序化计算“烘焙”成一张贴图去采样反而更快。但反过来纹理采样会占用纹理单元TMU而且采样有延迟。如果一个 Shader 里纹理采样过多TMU 成为瓶颈也会拖慢整体。所以这里有个平衡ALU 密集的 Shader 考虑用贴图换计算TMU 密集的 Shader 考虑用计算换采样。具体往哪边倒得看目标硬件的瓶颈在哪。判断方法后面会讲核心是先搞清楚你的 Shader 是 ALU-bound 还是 TMU-bound。这个判断做对了优化方向就不会错。3. UE 里怎么看到 Shader 的真实指令3.1 用 Shader 复杂度视图快速定位热点UE 编辑器里有个很实用的功能材质编辑器的Shader Complexity视图。在视口左上角的视图模式里能切到它用颜色把场景里每个像素的 Shader 开销可视化出来。绿色是便宜红色是昂贵。这个视图的好处是直观一眼就能看出哪个物体、哪个区域的材质最重。但它有个局限它显示的是相对复杂度不是精确的指令数而且不同平台的计算方式可能不一样。所以它适合做“初筛”帮你快速找到可疑对象但不适合做精确判断。我的习惯是先用 Shader Complexity 扫一遍场景把红色的物体记下来然后针对这些物体去查具体的指令统计。这样效率最高不用一上来就啃每个材质的编译日志。3.2 查看编译后的指令数与寄存器占用UE 提供了查看 Shader 编译统计的途径。在材质编辑器里有个Stats面板或者通过平台统计窗口能看到当前材质的指令数、纹理采样数、寄存器占用等数据。不同 UE 版本入口位置略有差异但核心数据都在。重点看几个数字Base Pass 的指令数这是像素着色器的主要开销直接决定每个像素的计算成本。纹理采样数采样越多TMU 压力越大。寄存器数量这个数字直接关系到能驻留多少线程。这里要提醒一句UE 显示的指令数是编译器优化后的估算值和最终 GPU 实际执行的指令可能有出入因为平台编译器还会做二次优化。但它作为相对参考是很有价值的——同一个项目里A 材质 150 条指令B 材质 300 条那 B 大概率更重。3.3 平台差异为什么 PC 上没事移动端就炸这是最容易被忽略的一点。同一个 Shader在 PC 和移动端编译出来的指令数可能差很多。原因有几个第一移动 GPU 的指令集和桌面不同。桌面 GPU 有些复杂指令是硬件直接支持的移动端可能得用多条简单指令模拟。比如某些三角函数、幂运算移动端展开后指令数会明显增加。第二移动端的精度处理不同。UE 里可以设置材质的精度Full Precision / Half Precision。Half 精度在移动端能显著减少寄存器占用和指令成本但用错了地方会导致画面出问题。这个后面单独讲。第三寄存器文件大小差异。桌面 GPU 寄存器多稍微超标也能扛移动端一超标就溢出性能直接崩。所以做移动端优化一定要在目标平台上查看编译统计不能拿 PC 的数据做判断。我见过太多项目在 PC 上调得好好的一上真机就傻眼。3.4 一个实操排查流程把上面的东西串成一个可执行的流程在目标平台上打开项目切到 Shader Complexity 视图找出红色区域对应的材质。逐个打开这些材质查看 Stats 面板里的指令数、采样数、寄存器占用。对指令数明显偏高的材质检查材质图里有没有可以合并、可以降精度、可以预计算的部分。修改后重新编译对比指令数变化再到真机上验证帧数。记录每次修改前后的数据形成自己的“优化账本”。这个流程看着简单但坚持做下来你会对“什么操作贵、什么操作便宜”建立起非常具体的直觉。这比看任何教程都管用。4. 落到实处的 Shader 优化手段4.1 减少 ALU 指令从源头砍计算减少 ALU 指令是最直接的优化。几个常用思路合并运算。能用一条 FMA 解决的别拆成乘和加两步。UE 的材质编译器通常会自动做这个优化但如果你在自定义节点里手写 HLSL就得自己注意。比如a * b c写成mad(a, b, c)在某些平台上更明确。避免昂贵的数学函数。Power、Sin、Cos、Atan2这些在移动端都不便宜。如果指数是常数比如x^2直接写成x * x别用Power节点。如果非要幂运算考虑用查表贴图替代。把常量计算挪到顶点着色器或 CPU。如果一个计算的结果在整个绘制过程中不变或者只随顶点变化就别放在像素着色器里。像素着色器是执行次数最多的阶段能省则省。用近似替代精确。很多视觉效果不需要数学上的精确。比如归一化向量在某些情况下可以用快速近似光照计算里的一些项可以用更简单的函数拟合。这需要你判断视觉上能不能接受属于“艺术与性能的权衡”。4.2 控制寄存器占用让线程住得下寄存器优化的核心是“别让编译器为难”。几个实操要点减少同时活跃的变量。如果一个中间变量算完就不用了尽量让它早点“死掉”这样寄存器能复用。写 HLSL 时变量的作用域越小越好别在一个大函数开头声明一堆变量然后慢慢用。慎用大数组和复杂结构体。数组会占用大量寄存器尤其是动态索引的数组编译器可能直接把它放到本地内存相当于溢出性能很差。控制分支。GPU 对分支的处理和 CPU 完全不同。如果一个 Wave 里的线程走了不同分支两条分支都得执行这叫“分支发散”。分支发散不仅浪费 ALU还会增加寄存器压力因为两条路径的变量可能都得保留。所以 Shader 里尽量用lerp、step这类无分支写法替代if。精度选择。移动端把不需要全精度的计算降到 Half能省寄存器和指令。颜色、UV、大部分光照项用 Half 通常没问题但涉及大数值、需要高精度累积的计算比如某些坐标变换还是得用 Full。这个要逐个验证不能一刀切。4.3 纹理与采样的优化别让 TMU 堵车纹理相关的优化核心是减少采样次数和降低采样成本。合并贴图通道。把多张灰度图打包到一张贴图的 RGBA 四个通道里一次采样拿到四个值。这是最经典也最有效的做法UE 里用Append和Component Mask就能实现。用 Mipmap 和合适的过滤。远处物体用高 Mip 级别减少纹理缓存压力。过滤模式也要注意各向异性过滤效果好但成本高移动端要慎用。避免依赖采样的依赖采样。就是用一个采样的结果去算另一个采样的 UV这种“依赖纹理读取”会打断 GPU 的预取延迟藏不住。能预计算的 UV 就预计算。考虑用计算换采样。前面说过如果 TMU 是瓶颈把一些简单的贴图采样换成程序化计算可能更快。比如一张简单的渐变图用lerp算出来可能比采样还便宜。4.4 分支与循环GPU 最不擅长的事GPU 天生不擅长分支和循环因为它的并行架构假设所有线程走同一条路。一旦有线程“掉队”整个 Wave 都得等。动态分支能免则免。如果分支条件是逐像素变化的那基本一定会发散。这种情况优先考虑用数学方法“抹平”分支。比如根据条件在两个值之间切换用lerp(值A, 值B, 条件)就比if-else好。循环要短且次数固定。固定次数的循环编译器可以展开反而没有分支开销。次数不固定的循环尤其是依赖运行时数据的尽量避免。如果非要循环把次数压到最低。用 Step 和 SmoothStep 做软过渡。很多原本需要分支的地方其实是在做“阈值判断”。用step或smoothstep能无分支地实现而且还能得到更平滑的过渡效果一举两得。4.5 精度与平台适配移动端的特殊照顾移动端 Shader 优化有一套自己的规则因为移动 GPU 的架构和桌面差异很大。Half 精度是好朋友但要会用。移动 GPU 对 Half 精度的支持通常比 Full 快一倍甚至更多寄存器占用也减半。但 Half 的数值范围小、精度低用错地方会出现色带、闪烁、计算错误。经验法则是颜色、UV、法线的归一化分量、大部分光照系数可以用 Half世界坐标、大范围数值、需要精确累积的用 Full。避免在移动端用桌面思维。桌面 GPU 有些“免费”的操作移动端可能要命。比如前面说的复杂数学函数、大数组、动态分支在桌面可能无所谓移动端就是性能杀手。针对目标 GPU 调优。不同厂商的移动 GPU不同架构对指令的偏好不一样。有的对某些指令有特殊优化有的没有。最靠谱的办法是在目标机型上实测别信“通用最优解”。5. 常见问题与排查技巧实录5.1 改了 Shader 帧数没变先确认瓶颈在哪这是最常见的困惑。你辛辛苦苦优化了 Shader帧数纹丝不动。大概率是瓶颈不在 Shader。GPU 渲染的瓶颈可能有好几个ALU、TMU、带宽、ROP光栅操作、顶点处理。如果瓶颈在带宽或者 Draw Call你优化 ALU 当然没用。怎么判断一个简单办法是做“极端测试”把某个材质的输出直接改成纯色去掉所有计算看帧数变化。如果帧数大涨说明这个材质的 Shader 确实是瓶颈如果没变那瓶颈在别处。另一个办法是看 GPU 的 Profiler 数据。UE 有ProfileGPU命令能给出各个阶段的耗时。如果 Base Pass 耗时占比很高那 Shader 优化就有意义如果瓶颈在别的阶段就得换个方向。5.2 寄存器溢出怎么发现和解决寄存器溢出Spill是移动端性能的隐形杀手。它不会报错但会让性能悄悄掉下去。发现方法查看编译统计里的寄存器数量如果接近或超过硬件的上限就要警惕。不同 GPU 的上限不同需要查对应硬件的文档。另一个信号是如果 Shader 逻辑不复杂但性能异常差也可能是溢出。解决方法减少同时活跃的变量拆分复杂函数降低精度去掉不必要的数组。如果实在降不下来考虑把一部分计算挪到顶点着色器或者用贴图预计算替代。5.3 精度问题导致画面异常怎么排查用了 Half 精度后画面出问题排查思路是逐个变量往上提精度直到问题消失。具体做法先把可疑的中间变量改成 Full看问题是否解决。如果解决了说明是这个变量精度不够。然后分析它的数值范围——如果范围很大或者需要高精度那就保持 Full如果只是偶尔出问题可能是某个中间步骤的累积误差考虑调整计算顺序减少误差。常见的精度坑UV 坐标做大范围平铺时Half 精度不够会导致纹理抖动世界坐标做距离计算时Half 范围不够会溢出颜色做多次累加时Half 精度不够会有色带。5.4 一张速查表症状与可能原因症状可能原因排查方向移动端掉帧PC 正常指令数超标、寄存器溢出、精度问题查目标平台编译统计优化 Shader 后帧数不变瓶颈不在 Shader用 ProfileGPU 看各阶段耗时画面出现色带、闪烁Half 精度不够逐个变量提精度排查复杂材质性能断崖寄存器溢出查寄存器数量减少活跃变量特效多时掉帧TMU 或带宽瓶颈减少采样合并贴图通道分支多的 Shader 很慢分支发散改用 lerp/step 无分支写法5.5 几个踩过的坑坑一迷信节点数量。前面说过节点数不等于指令数。我见过一个材质节点很少但指令数爆炸的因为用了几个Power和Sin。也见过节点一大堆但编译后很精简的因为都是简单运算被合并了。看指令数别看节点数。坑二在 PC 上调移动端。这个坑太常见了。PC 上跑得好不代表移动端没问题一定要在真机或目标平台上验证。模拟器和 PC 的 GPU 行为差异很大。坑三过度优化。不是所有 Shader 都需要优化。如果一个材质只占屏幕很小一块或者只在近处出现优化它的收益很低。把精力放在占屏比大、出现频率高的材质上性价比最高。坑四忽略顶点着色器。大家都盯着像素着色器但顶点着色器在某些情况下也会成为瓶颈尤其是顶点数多、顶点计算复杂的时候。顶点着色器的优化思路类似减少指令、控制寄存器、避免复杂函数。坑五不看编译警告。Shader 编译器有时会给出警告比如“寄存器压力高”“可能存在溢出”。这些警告很有价值别忽略。6. 我个人的一些实操体会做 Shader 优化这些年最大的体会是先测量再动手。凭感觉优化十有八九是白费力气。GPU 的行为和直觉往往相反你以为贵的可能很便宜你以为便宜的可能很贵。只有数据能告诉你真相。另一个体会是优化是个权衡游戏。没有“绝对最优”的 Shader只有在特定硬件、特定场景下的“相对更优”。同一个效果在高端机上可以用复杂 Shader 追求画质在低端机上就得用简化版保帧数。UE 的材质质量等级Quality Level就是干这个的善用它。最后分享一个小技巧建立一个自己的“指令成本参考表”。平时做项目时随手记录一些常见操作的指令数和性能表现比如“一次 Power 约等于几条 ALU”“一次纹理采样在某某机型上的耗时”。积累多了你就能在写材质的时候心里有数不用每次都去查编译统计。这个习惯坚持半年你对 Shader 性能的判断会准得吓人。Shader 优化这件事说到底是对 GPU 工作原理的理解深度决定的。你越懂它怎么干活就越知道怎么让它干得又快又好。从 ALU 和寄存器这些基础概念入手把底层逻辑打通剩下的就是实践和积累了。