搞了快十年的渲染我一直有个体会UE 里做 Shader 优化绕不开一个问题——你根本不了解 GPU 是怎么“跑”你的指令的。很多人包括我自己早期优化都靠玄学把材质节点拆了又合并把 if 换着写法结果 Profile 一下发现帧耗时几乎没变甚至更差了。直到后来把 GPU 指令执行的基本原理补齐回头看那些优化动作才明白哪些是白费功夫哪些才是真正值钱的。这篇内容我就从 GPU 怎么执行指令这个底层起点开始聊一路说到 UE 里 Shader 优化具体怎么落地。适合已经被 UE 材质系统搞上手、但又不太清楚 “GPU 到底凭什么累、为什么卡” 的人。看完你至少能建立一套自己的判断一个材质烂不烂、一段自定义节点值不值得合、一个效果是不是白加钱先看什么指标、再去动什么刀。1. GPU 指令成本拆解为什么“会写”Shader 不等于“会优化”1.1 先说我那个白忙一周的反面案例早年在做一个移动端项目有个半透明特效材质Shader 复杂度明显偏高。当时我花了一整天把二十多个材质节点合并成了几个 Custom 节点把四五个乘加操作手动化简Instruction Count 从一百多降到了五六十。心里美滋滋觉得这次至少能省 30% 的像素开销。结果上真机一测整个 Pass 的耗时几乎没变化。最崩溃的是 RenderDoc 抓帧发现那个特效的瓶颈根本不在 ALU而在 Texture Fetch 和带宽——它每次像素都要采样三四张贴图还有两个是全屏尺寸的高精度 RT。我化简那几十条加减乘除在整体耗时里占比连 2% 都不到。这个经历让我明白一件事GPU 上一条 Shader 指令的成本不是“CPU 里一条汇编指令”那种概念不能靠拍脑袋估。你得先知道这条指令在 GPU 上是怎么被安排的谁来执行、什么时候执行、执行完结果放在哪、后续谁在等它。这些决定了它到底贵不贵。1.2 指令、带宽、延迟Shader 性能的三根支柱在 GPU 里Shader 指令从发射到出结果基本绕不开三个维度指令Instruction/ALU、内存带宽Bandwidth、延迟Latency。指令像素着色器里做的加减乘除、点积、rsqrt、pow、saturate 等操作最终都会转成 GPU 标量或向量指令。ALU 成本就是这些指令本身的计算开销。带宽Shader 请求纹理采样、读顶点属性、写 RenderTarget这些都是和显存/缓存打交道。移动端 GPU 里带宽尤其金贵因为内存带宽有限功耗大头也在这。延迟一条指令从开始执行到出结果往往要好几个周期。尤其纹理采样延迟可以达到几百个周期。GPU 靠海量并行线程来隐藏这个延迟而不是像 CPU 那样靠乱序执行。大多数新手优化只盯着第一个“指令数”而真正拖垮帧的是后两者。指令数降了但帧率没变大概率是瓶颈在带宽或者延迟隐藏上你砍的正好不是关键路径。1.3 从 ALU 成本的三种形态看优化方向GPU 里同一段 Shader 代码不同架构下生成的指令序列差别很大但大体上有三种典型的成本形态纯算术型例如距离计算、法线扰动、菲涅尔近似主要是 MAD乘加、向量点积这类指令。这种代码对 ALU 占用比较敏感化简公式和用近似函数收益最大。访存密集型例如多层法线混合、多层细节纹理、动态 Cube 采样成本大头在采样指令和带宽上。这种代码做 ALU 化简没用减少采样次数、降低采样分辨率、合并通道才是正路。依赖链过长型例如在循环里做迭代式的噪声计算每条结果依赖上一条结果。这种代码数学运算不多但延迟隐藏很差GPU 的并行优势发挥不出来。看一个材质卡不卡先别急着化简公式先在 RenderDoc 或 GPU 调试器里看它是哪种形态再决定从哪一刀下。2. 指令级优化把 Shader 抠到字节码粒度2.1 精度选择为什么有用——half 背后的暗刀UE 材质编辑器里每个节点都可以设置浮点精度Float32 位、Half16 位等。很多人以为这只是一个“精度够不够用”的开关其实在移动 GPU 上它直接关系指令的成本和寄存器的占用。移动端 GPU 多数是 16 位和 32 位混合执行架构。使用 half 类型时寄存器和内部数据通路的宽度减半带宽消耗减半速度经常翻倍。最典型的例子是高通的 Adreno很多 ALU 指令在 half 下能同时处理两倍通道数。UE 里对移动端材质通常建议打开“Use Full Precision”之外的选项或者把能降精度的部分用 Half 精度去跑。但这里有个隐蔽的坑你在材质节点编辑器里选了 Half编译器未必真的把关键链路转成 half反过来你全链路用了 Float也可能只比 Half 慢一点点。所以别只在编辑器里看设置要到实际生成的 Shader 字节码里验证很多平台用 Mali Offline Compiler 或 PVRShaderEditor 能直接看到每条指令的操作数精度。2.2 分支指令的代价动态分支为什么“平摊”不掉GPU 的着色器里写 if 不是不可以但你要理解它是怎么执行的。GPU 执行 Shader 的基本单位是“波前”Wavefront / Warp一般 32 或 64 个线程同时执行同一条指令。如果这 32 个线程里有一部分要走 if 分支另一部分要走 else 分支那 GPU 就必须把两条路径都执行一遍然后根据“执行掩码”丢弃不需要的结果。这就是所谓分支分歧Divergence。比如你写if (uv.x 0.5) { color texture2D(TexA, uv); } else { color texture2D(TexB, uv); }在 GPU 上如果相邻像素落在 uv.x 两侧那么这个 if 分支指令本身不贵但分支体内的两张纹理采样会被全部执行。你以为只采样了一张其实硬件帮你采样了两张再丢弃一半。能不写动态分支就尽量别写如果必须分支尽量按屏幕空间的大块区域做“uniform 分支”整个 wavefront 走同一方向或者把分支向量化成选择color lerp(tex2D(TexA, uv), tex2D(TexB, uv), step(0.5, uv.x));——但这也会导致两张纹理都被采样要注意权衡。UE 材质编辑器里如果用 Static Switch本质上是在编译期就选好方向运行时无分支成本这种是最安全的。2.3 数学函数的隐藏指令序列UE 里常用的节点比如 Power、Sqrt、Noise、三角函数它们在 GPU 上不是一条指令而是一串指令。pow(x, y)如果 y 是编译期常量一般可以转成exp2(log2(x) * y)需要一条log2和一条exp2移动端还有快速近似版本。sqrt(x)通常生成rsqrt(x)加一次乘法或者sqrt专用指令成本不高。sin/cos移动端常见做法是查表加插值精度和成本差异很大极少数情况下会用多项式展开。noiseUE 的 Noise 节点在移动端默认可能就是一堆 permutation 和 hash 计算指令数量几十上百非常贵。除非必要否则尽量烘焙到纹理里采样。我的建议是先统计材质里哪些节点贡献了主要指令数比如用 Material Stats 窗口看 Instruction Count再用r.ShaderComplexity可视化确认热点区域。很多看似无害的数学节点指令数远超你的直觉。2.4 把表达式“喂”给 Custom 节点化简的边界UE 节点图复杂到一定程度后几十个节点会生成大量中间临时变量每个变量都会占用寄存器指令也可能变得冗余。这时候很多人会把整个表达式塞到 Custom 节点里写 HLSL比如float3 N normalize(WorldNormal); float3 V normalize(CameraVector); float NdV saturate(dot(N, V)); float fresnel pow(1.0 - NdV, 5.0); return lerp(SpecColor, FresnelColor, fresnel);确实可控性更强指令序列更清晰但我吃过亏Custom 节点里的代码在 PC 和移动端表现不一致尤其涉及atan2、length这类函数跨厂商编译器优化的结果差别很大。所以建议是复杂数学用 Custom 没问题但一定要在目标设备上验证结果不要只盯着 PC 画质看。3. 从指令到线程Warp、占用率和内存带宽才是水泥3.1 Warp 分歧的一个直观理解上面已经提了分支分歧我想用更生活化的方式再说一遍因为它真的太重要了。想象你是一个体育老师你带队 32 个人跑步。你喊“立正”——所有人必须同时做这个动作谁要是慢了整个队伍就得等你。GPU 也是这么干的一个 wavefront 里的线程必须执行同一条指令。如果其中一个人要跑 100 米而其他人要跳高那老师只能先让所有人跳一遍再让所有人跑一遍最后假装某些人没干过。这就是分支分歧的成本本质。只要一个 wavefront 里有人走进了分支体整条 wavefront 都要为那个分支付出代价。很多“这样写能省一半指令”的代码在 GPU 上不仅没省反而可能因为分支而更慢。如果分支条件是在 CPU 侧固定的例如一个全局 uniform 开关整个 wavefront 都走同一方向这时 if 和 static switch 基本等价因为不会产生 divergence。但如果是 per-pixel 的连续变化量比如 uv、噪声值那就是分歧重灾区。3.2 占用率和延迟隐藏为什么寄存器越少越流畅GPU 有一个指标叫 Occupancy占用率简单说就是每个 SM / 执行单元上同时驻留了多少个 wavefront。占用率越高调度器越容易在等待纹理返回时切换去执行其他 wavefront从而完成延迟隐藏。Shader 编译出一个重要参数寄存器数量。一个 Shader 占用的寄存器越多硬件能驻留的线程就越少。比如一块硬件一个 SM 最多能驻留 64 个 wavefront你的 Shader 平均用了 16 个寄存器那也许能驻留 32 个如果平均用了 32 个寄存器可能就只能驻留 16 个。占用率降低遇到高延迟指令时硬件没别的活可干管线就空转了。这就是为什么有时候你辛辛苦苦把 ALU 指令数从 80 降到 60帧率却没什么变化——因为你没降寄存器占用率纹丝不动。反过来说优化 Shader 时看“寄存器压力”往往比看指令数更重要。实操建议编译后查看sstats或离线编译器的寄存器报告关注最大的那个 kernel。减少临时变量数量、缩短变量生命周期通常在函数末尾一次性算临时结果的写法更容易让编译器复用寄存器。警惕大循环内的长依赖链循环展开可能降低占用率。3.3 内存带宽移动端真正的“硬通货”所有 Shader 优化到最后最贵的往往是带宽。移动端 GPU 的显存带宽远小于桌面端而且访问功耗极高——带宽一高设备发热和降频立刻报复你。带宽消耗主要集中在纹理采样每采样一张纹理都需要从缓存或显存读取数据。Mip 层级不匹配、纹理格式不合适、各向异性过滤开太大都会放大流量。RenderTarget 写入全屏特效里每多一个 RT就多一次全屏带宽吞吐。half 分辨率比全屏的四分之一带宽流量收益非常直接。顶点数据顶点格式弄成 32 位浮点四分量比压成 16 位要多一倍以上的带宽顶点量大时非常可观。在 UE 里优化移动端 Shader 时我有个原则能采一次就不要采两次能降 mip 就不要用高精度采样能在 vertexshader 算完就传 interpolator不要放在 pixelshader 里重算。UE 的纹理节点如果开了“Preserve Size”之类选项会绕过 mipmap 链直接采样高清结果不要随便开。还有一个常见坑把一张 4K 纹理拖进材质哪怕只采样一个 uv 区域硬件也会按完整纹理缓存行读取内存流量并不会因为你只采一小块而减少。4. 落到 UE 产线一个可执行的 Shader 优化工作流4.1 第一步先确认瓶颈是 PS 还是别的打开 UE 的stat gpu或者用ProfileGPU抓一帧先看你的目标 Pass 是Bound在 VertexShader、PixelShader还是纯带宽/填充率。有时候你会惊讶地发现一个非常复杂的材质根本没进性能热点——因为场景里它只覆盖了极少数像素反而一个看似简单的 UI 材质因为全屏大四边形成了耗电冠军。用r.ShaderComplexity可视化场景颜色越红代表 Shader 越贵。我实测过很多次同一个场景阳光下的山体材质因为覆盖面积大红得发烫但它并不一定是最需要优化的——如果它只占屏幕 5% 像素再贵也是九牛一毛。所以优化的第一步永远是定位看它在哪、覆盖多大、采样多频繁。4.2 第二步用离线编译器看真实的指令和寄存器有了热点目标之后去 Mobile 平台的离线编译器里看代码而不是只在 UE 材质编辑器里看节点数。工具方面MaliMali Offline Compiler命令行能看到 ALU 周期、负载、寄存器、指令条数非常直观。AdrenoAdreno GPU Profiler 或者 GPU SDK 里的 Adreno Offline Compiler。桌面 N 卡可以用 NVIDIA Nsight Graphics抓帧之后查看对应的 DXBC/DXIL/SPIR-V不过操作门槛高一点。用离线编译器时关注三列Instruction Cache Hit、Cycles、Register Usage。如果一个 Shader 指令数不高但寄存器很高说明可能临时变量太多如果一个 Shader 周期数高但 ALU 指令不高那基本是访存或依赖延迟拖的。不要只盯着 Instruction Count 单指标下判断。4.3 第三步UE 材质层对症下药瓶颈定位清楚以后再到材质层面操作。我按频率排序的优化手段合并数学节点UE 的每个节点都会生成中间变量和额外指令把多个线性操作合并到一个 Custom 节点或MaterialFunction里能显著减少临时寄存器和指令。这个收益在移动平台上尤其明显。避免动态分支把 per-pixel 的分支用材质里的 Static Switch、Static Bool 或节点参数编译期分支替代。如果一定要运行时条件尽量改成数值选择lerp(a, b, saturate(cond))。减少采样次数多层法线混合尽量用一张纹理打包通道比如把粗糙度、AO、金属度全塞进一张 RMA 贴图别拆成三张贴图三路采样。精度分级除了采样坐标和输出大部分中间量用 Half 即可。尤其移动端不要舍不得。删除无用联结很多时候节点图里挂了调试输出忘记断开编译器虽然会优化死代码但别依赖它手动删掉更安心。4.4 第四步渲染 Pass 和频率层面的降本Shader 指令优化做到一定程度后你会发现收益有天花板。真正的飞跃往往来自“减少执行次数”。把一些低频计算从 PixelShader 挪到 VertexShader例如只用顶点位置算出的距离衰减、物体级的光照参数放进顶点着色器算好用插值器传给像素着色器。只要没有高频率变化视觉差异很小但每像素省下一堆指令。使用 Half Res对某些全屏特效比如景深、体积光在 half 分辨率下渲染再上采样带宽和填充率直接砍到四分之一。UE 里用 SceneTexture 节点读取 half res 的中间结果时注意 UV 要乘上分辨率比例。减少 Overdraw透明材质、粒子、植被重叠的像素越多PS 执行次数越高。调小粒子发射量、用 DepthFade 提前裁剪有时候比优化 Shader 本身更有效。5. 工具链与真实工程经验别只信 PC 渲染结果5.1 常用工具和各自最擅长的事下面是我常用的组合不一定全但足够覆盖大多数 UE Shader 优化场景工具/功能干什么最靠谱备注UEProfileGPU看整个帧的 Pass 耗时分配先看大方向别纠结细节UEstat gpu实时看 RenderThread/GPU 时间消耗适合快速对比改动前后RenderDoc抓帧查单 Pass 的硬件计数器、纹理绑定、Shader 源码桌面和移动模拟端都好用Mali Offline Compiler查 ARM GPU 的目标指令数、周期、寄存器安卓旗舰机最常用Adreno GPU Profiler查高通 GPU 的 wavefront 占用率、带宽、ALU 利用率需要 Adreno 设备配合Nsight Graphics桌面 N 卡的精确定位包括 SM 占用率、指令混合做 PC 优化时使用UEr.ShaderComplexity可视化屏幕上的 Shader 成本热点快速找到大面积高亮区域5.2 我在项目中踩过的几个典型坑只在编辑器里看材质节点数就下结论节点数量不等于指令数量。编译器会合并常量折叠、公共子表达式有时二十个节点的材质只有十条指令有时五个节点的材质因为一个 noise 生成了两百条指令。把 Transparent 的 Shader 优化放在第一优先级很多时候半透明物体会因为混合排序导致重复绘制这种场景瓶颈是填充率而不是指令。先减少重复绘制再谈 Shader 精简。忘记移动端和桌面端的差异同一段pow、cos在 Adreno 和 Mali 上的展开指令数量可能差 3 倍以上。桌面 N 卡优化完一定到目标机器上再离线编译看一遍别偷懒。过分相信一个小技巧的截图收益今天优化了一个 shader帧数特别好结果第二天场景里换了个更贵的后处理整体又卡了。优化是持续推进的事每帧的预算要留余量。5.3 优化不动了怎么办把性能预算留给玩家最后我想说一点额外的东西如果你的 Shader 优化做到“看每个 Pass 都觉得过得去”但整体帧数还是不稳那问题往往不在 Shader而在 DrawCall、场景复杂度、后处理链、CPU 端的 Gameplay 线程、甚至内存带宽被贴图格式霸占。这时候再抠 Shader 指令就是往漏水的桶里倒水。我自己的经验是给项目定一个“Shader 性能预算表”每个角色材质允许多少 ALU、多少个纹理采样、最大寄存器数写在文档里新材质合入前先走一遍离线编译器。养成这个习惯以后场景性能不太容易出现突发性崩溃因为问题在源头就被拦住了。我现在做新项目的优化早就不是“哪里卡改哪里”了而是先立预算和度量体系——没有度量的优化都是自我安慰。你要是刚从节点图化简这条路走出来建议也从搭一套工具链和预算表开始。 GPU指令原理详解：UE材质Shader优化实战
搞了快十年的渲染我一直有个体会UE 里做 Shader 优化绕不开一个问题——你根本不了解 GPU 是怎么“跑”你的指令的。很多人包括我自己早期优化都靠玄学把材质节点拆了又合并把 if 换着写法结果 Profile 一下发现帧耗时几乎没变甚至更差了。直到后来把 GPU 指令执行的基本原理补齐回头看那些优化动作才明白哪些是白费功夫哪些才是真正值钱的。这篇内容我就从 GPU 怎么执行指令这个底层起点开始聊一路说到 UE 里 Shader 优化具体怎么落地。适合已经被 UE 材质系统搞上手、但又不太清楚 “GPU 到底凭什么累、为什么卡” 的人。看完你至少能建立一套自己的判断一个材质烂不烂、一段自定义节点值不值得合、一个效果是不是白加钱先看什么指标、再去动什么刀。1. GPU 指令成本拆解为什么“会写”Shader 不等于“会优化”1.1 先说我那个白忙一周的反面案例早年在做一个移动端项目有个半透明特效材质Shader 复杂度明显偏高。当时我花了一整天把二十多个材质节点合并成了几个 Custom 节点把四五个乘加操作手动化简Instruction Count 从一百多降到了五六十。心里美滋滋觉得这次至少能省 30% 的像素开销。结果上真机一测整个 Pass 的耗时几乎没变化。最崩溃的是 RenderDoc 抓帧发现那个特效的瓶颈根本不在 ALU而在 Texture Fetch 和带宽——它每次像素都要采样三四张贴图还有两个是全屏尺寸的高精度 RT。我化简那几十条加减乘除在整体耗时里占比连 2% 都不到。这个经历让我明白一件事GPU 上一条 Shader 指令的成本不是“CPU 里一条汇编指令”那种概念不能靠拍脑袋估。你得先知道这条指令在 GPU 上是怎么被安排的谁来执行、什么时候执行、执行完结果放在哪、后续谁在等它。这些决定了它到底贵不贵。1.2 指令、带宽、延迟Shader 性能的三根支柱在 GPU 里Shader 指令从发射到出结果基本绕不开三个维度指令Instruction/ALU、内存带宽Bandwidth、延迟Latency。指令像素着色器里做的加减乘除、点积、rsqrt、pow、saturate 等操作最终都会转成 GPU 标量或向量指令。ALU 成本就是这些指令本身的计算开销。带宽Shader 请求纹理采样、读顶点属性、写 RenderTarget这些都是和显存/缓存打交道。移动端 GPU 里带宽尤其金贵因为内存带宽有限功耗大头也在这。延迟一条指令从开始执行到出结果往往要好几个周期。尤其纹理采样延迟可以达到几百个周期。GPU 靠海量并行线程来隐藏这个延迟而不是像 CPU 那样靠乱序执行。大多数新手优化只盯着第一个“指令数”而真正拖垮帧的是后两者。指令数降了但帧率没变大概率是瓶颈在带宽或者延迟隐藏上你砍的正好不是关键路径。1.3 从 ALU 成本的三种形态看优化方向GPU 里同一段 Shader 代码不同架构下生成的指令序列差别很大但大体上有三种典型的成本形态纯算术型例如距离计算、法线扰动、菲涅尔近似主要是 MAD乘加、向量点积这类指令。这种代码对 ALU 占用比较敏感化简公式和用近似函数收益最大。访存密集型例如多层法线混合、多层细节纹理、动态 Cube 采样成本大头在采样指令和带宽上。这种代码做 ALU 化简没用减少采样次数、降低采样分辨率、合并通道才是正路。依赖链过长型例如在循环里做迭代式的噪声计算每条结果依赖上一条结果。这种代码数学运算不多但延迟隐藏很差GPU 的并行优势发挥不出来。看一个材质卡不卡先别急着化简公式先在 RenderDoc 或 GPU 调试器里看它是哪种形态再决定从哪一刀下。2. 指令级优化把 Shader 抠到字节码粒度2.1 精度选择为什么有用——half 背后的暗刀UE 材质编辑器里每个节点都可以设置浮点精度Float32 位、Half16 位等。很多人以为这只是一个“精度够不够用”的开关其实在移动 GPU 上它直接关系指令的成本和寄存器的占用。移动端 GPU 多数是 16 位和 32 位混合执行架构。使用 half 类型时寄存器和内部数据通路的宽度减半带宽消耗减半速度经常翻倍。最典型的例子是高通的 Adreno很多 ALU 指令在 half 下能同时处理两倍通道数。UE 里对移动端材质通常建议打开“Use Full Precision”之外的选项或者把能降精度的部分用 Half 精度去跑。但这里有个隐蔽的坑你在材质节点编辑器里选了 Half编译器未必真的把关键链路转成 half反过来你全链路用了 Float也可能只比 Half 慢一点点。所以别只在编辑器里看设置要到实际生成的 Shader 字节码里验证很多平台用 Mali Offline Compiler 或 PVRShaderEditor 能直接看到每条指令的操作数精度。2.2 分支指令的代价动态分支为什么“平摊”不掉GPU 的着色器里写 if 不是不可以但你要理解它是怎么执行的。GPU 执行 Shader 的基本单位是“波前”Wavefront / Warp一般 32 或 64 个线程同时执行同一条指令。如果这 32 个线程里有一部分要走 if 分支另一部分要走 else 分支那 GPU 就必须把两条路径都执行一遍然后根据“执行掩码”丢弃不需要的结果。这就是所谓分支分歧Divergence。比如你写if (uv.x 0.5) { color texture2D(TexA, uv); } else { color texture2D(TexB, uv); }在 GPU 上如果相邻像素落在 uv.x 两侧那么这个 if 分支指令本身不贵但分支体内的两张纹理采样会被全部执行。你以为只采样了一张其实硬件帮你采样了两张再丢弃一半。能不写动态分支就尽量别写如果必须分支尽量按屏幕空间的大块区域做“uniform 分支”整个 wavefront 走同一方向或者把分支向量化成选择color lerp(tex2D(TexA, uv), tex2D(TexB, uv), step(0.5, uv.x));——但这也会导致两张纹理都被采样要注意权衡。UE 材质编辑器里如果用 Static Switch本质上是在编译期就选好方向运行时无分支成本这种是最安全的。2.3 数学函数的隐藏指令序列UE 里常用的节点比如 Power、Sqrt、Noise、三角函数它们在 GPU 上不是一条指令而是一串指令。pow(x, y)如果 y 是编译期常量一般可以转成exp2(log2(x) * y)需要一条log2和一条exp2移动端还有快速近似版本。sqrt(x)通常生成rsqrt(x)加一次乘法或者sqrt专用指令成本不高。sin/cos移动端常见做法是查表加插值精度和成本差异很大极少数情况下会用多项式展开。noiseUE 的 Noise 节点在移动端默认可能就是一堆 permutation 和 hash 计算指令数量几十上百非常贵。除非必要否则尽量烘焙到纹理里采样。我的建议是先统计材质里哪些节点贡献了主要指令数比如用 Material Stats 窗口看 Instruction Count再用r.ShaderComplexity可视化确认热点区域。很多看似无害的数学节点指令数远超你的直觉。2.4 把表达式“喂”给 Custom 节点化简的边界UE 节点图复杂到一定程度后几十个节点会生成大量中间临时变量每个变量都会占用寄存器指令也可能变得冗余。这时候很多人会把整个表达式塞到 Custom 节点里写 HLSL比如float3 N normalize(WorldNormal); float3 V normalize(CameraVector); float NdV saturate(dot(N, V)); float fresnel pow(1.0 - NdV, 5.0); return lerp(SpecColor, FresnelColor, fresnel);确实可控性更强指令序列更清晰但我吃过亏Custom 节点里的代码在 PC 和移动端表现不一致尤其涉及atan2、length这类函数跨厂商编译器优化的结果差别很大。所以建议是复杂数学用 Custom 没问题但一定要在目标设备上验证结果不要只盯着 PC 画质看。3. 从指令到线程Warp、占用率和内存带宽才是水泥3.1 Warp 分歧的一个直观理解上面已经提了分支分歧我想用更生活化的方式再说一遍因为它真的太重要了。想象你是一个体育老师你带队 32 个人跑步。你喊“立正”——所有人必须同时做这个动作谁要是慢了整个队伍就得等你。GPU 也是这么干的一个 wavefront 里的线程必须执行同一条指令。如果其中一个人要跑 100 米而其他人要跳高那老师只能先让所有人跳一遍再让所有人跑一遍最后假装某些人没干过。这就是分支分歧的成本本质。只要一个 wavefront 里有人走进了分支体整条 wavefront 都要为那个分支付出代价。很多“这样写能省一半指令”的代码在 GPU 上不仅没省反而可能因为分支而更慢。如果分支条件是在 CPU 侧固定的例如一个全局 uniform 开关整个 wavefront 都走同一方向这时 if 和 static switch 基本等价因为不会产生 divergence。但如果是 per-pixel 的连续变化量比如 uv、噪声值那就是分歧重灾区。3.2 占用率和延迟隐藏为什么寄存器越少越流畅GPU 有一个指标叫 Occupancy占用率简单说就是每个 SM / 执行单元上同时驻留了多少个 wavefront。占用率越高调度器越容易在等待纹理返回时切换去执行其他 wavefront从而完成延迟隐藏。Shader 编译出一个重要参数寄存器数量。一个 Shader 占用的寄存器越多硬件能驻留的线程就越少。比如一块硬件一个 SM 最多能驻留 64 个 wavefront你的 Shader 平均用了 16 个寄存器那也许能驻留 32 个如果平均用了 32 个寄存器可能就只能驻留 16 个。占用率降低遇到高延迟指令时硬件没别的活可干管线就空转了。这就是为什么有时候你辛辛苦苦把 ALU 指令数从 80 降到 60帧率却没什么变化——因为你没降寄存器占用率纹丝不动。反过来说优化 Shader 时看“寄存器压力”往往比看指令数更重要。实操建议编译后查看sstats或离线编译器的寄存器报告关注最大的那个 kernel。减少临时变量数量、缩短变量生命周期通常在函数末尾一次性算临时结果的写法更容易让编译器复用寄存器。警惕大循环内的长依赖链循环展开可能降低占用率。3.3 内存带宽移动端真正的“硬通货”所有 Shader 优化到最后最贵的往往是带宽。移动端 GPU 的显存带宽远小于桌面端而且访问功耗极高——带宽一高设备发热和降频立刻报复你。带宽消耗主要集中在纹理采样每采样一张纹理都需要从缓存或显存读取数据。Mip 层级不匹配、纹理格式不合适、各向异性过滤开太大都会放大流量。RenderTarget 写入全屏特效里每多一个 RT就多一次全屏带宽吞吐。half 分辨率比全屏的四分之一带宽流量收益非常直接。顶点数据顶点格式弄成 32 位浮点四分量比压成 16 位要多一倍以上的带宽顶点量大时非常可观。在 UE 里优化移动端 Shader 时我有个原则能采一次就不要采两次能降 mip 就不要用高精度采样能在 vertexshader 算完就传 interpolator不要放在 pixelshader 里重算。UE 的纹理节点如果开了“Preserve Size”之类选项会绕过 mipmap 链直接采样高清结果不要随便开。还有一个常见坑把一张 4K 纹理拖进材质哪怕只采样一个 uv 区域硬件也会按完整纹理缓存行读取内存流量并不会因为你只采一小块而减少。4. 落到 UE 产线一个可执行的 Shader 优化工作流4.1 第一步先确认瓶颈是 PS 还是别的打开 UE 的stat gpu或者用ProfileGPU抓一帧先看你的目标 Pass 是Bound在 VertexShader、PixelShader还是纯带宽/填充率。有时候你会惊讶地发现一个非常复杂的材质根本没进性能热点——因为场景里它只覆盖了极少数像素反而一个看似简单的 UI 材质因为全屏大四边形成了耗电冠军。用r.ShaderComplexity可视化场景颜色越红代表 Shader 越贵。我实测过很多次同一个场景阳光下的山体材质因为覆盖面积大红得发烫但它并不一定是最需要优化的——如果它只占屏幕 5% 像素再贵也是九牛一毛。所以优化的第一步永远是定位看它在哪、覆盖多大、采样多频繁。4.2 第二步用离线编译器看真实的指令和寄存器有了热点目标之后去 Mobile 平台的离线编译器里看代码而不是只在 UE 材质编辑器里看节点数。工具方面MaliMali Offline Compiler命令行能看到 ALU 周期、负载、寄存器、指令条数非常直观。AdrenoAdreno GPU Profiler 或者 GPU SDK 里的 Adreno Offline Compiler。桌面 N 卡可以用 NVIDIA Nsight Graphics抓帧之后查看对应的 DXBC/DXIL/SPIR-V不过操作门槛高一点。用离线编译器时关注三列Instruction Cache Hit、Cycles、Register Usage。如果一个 Shader 指令数不高但寄存器很高说明可能临时变量太多如果一个 Shader 周期数高但 ALU 指令不高那基本是访存或依赖延迟拖的。不要只盯着 Instruction Count 单指标下判断。4.3 第三步UE 材质层对症下药瓶颈定位清楚以后再到材质层面操作。我按频率排序的优化手段合并数学节点UE 的每个节点都会生成中间变量和额外指令把多个线性操作合并到一个 Custom 节点或MaterialFunction里能显著减少临时寄存器和指令。这个收益在移动平台上尤其明显。避免动态分支把 per-pixel 的分支用材质里的 Static Switch、Static Bool 或节点参数编译期分支替代。如果一定要运行时条件尽量改成数值选择lerp(a, b, saturate(cond))。减少采样次数多层法线混合尽量用一张纹理打包通道比如把粗糙度、AO、金属度全塞进一张 RMA 贴图别拆成三张贴图三路采样。精度分级除了采样坐标和输出大部分中间量用 Half 即可。尤其移动端不要舍不得。删除无用联结很多时候节点图里挂了调试输出忘记断开编译器虽然会优化死代码但别依赖它手动删掉更安心。4.4 第四步渲染 Pass 和频率层面的降本Shader 指令优化做到一定程度后你会发现收益有天花板。真正的飞跃往往来自“减少执行次数”。把一些低频计算从 PixelShader 挪到 VertexShader例如只用顶点位置算出的距离衰减、物体级的光照参数放进顶点着色器算好用插值器传给像素着色器。只要没有高频率变化视觉差异很小但每像素省下一堆指令。使用 Half Res对某些全屏特效比如景深、体积光在 half 分辨率下渲染再上采样带宽和填充率直接砍到四分之一。UE 里用 SceneTexture 节点读取 half res 的中间结果时注意 UV 要乘上分辨率比例。减少 Overdraw透明材质、粒子、植被重叠的像素越多PS 执行次数越高。调小粒子发射量、用 DepthFade 提前裁剪有时候比优化 Shader 本身更有效。5. 工具链与真实工程经验别只信 PC 渲染结果5.1 常用工具和各自最擅长的事下面是我常用的组合不一定全但足够覆盖大多数 UE Shader 优化场景工具/功能干什么最靠谱备注UEProfileGPU看整个帧的 Pass 耗时分配先看大方向别纠结细节UEstat gpu实时看 RenderThread/GPU 时间消耗适合快速对比改动前后RenderDoc抓帧查单 Pass 的硬件计数器、纹理绑定、Shader 源码桌面和移动模拟端都好用Mali Offline Compiler查 ARM GPU 的目标指令数、周期、寄存器安卓旗舰机最常用Adreno GPU Profiler查高通 GPU 的 wavefront 占用率、带宽、ALU 利用率需要 Adreno 设备配合Nsight Graphics桌面 N 卡的精确定位包括 SM 占用率、指令混合做 PC 优化时使用UEr.ShaderComplexity可视化屏幕上的 Shader 成本热点快速找到大面积高亮区域5.2 我在项目中踩过的几个典型坑只在编辑器里看材质节点数就下结论节点数量不等于指令数量。编译器会合并常量折叠、公共子表达式有时二十个节点的材质只有十条指令有时五个节点的材质因为一个 noise 生成了两百条指令。把 Transparent 的 Shader 优化放在第一优先级很多时候半透明物体会因为混合排序导致重复绘制这种场景瓶颈是填充率而不是指令。先减少重复绘制再谈 Shader 精简。忘记移动端和桌面端的差异同一段pow、cos在 Adreno 和 Mali 上的展开指令数量可能差 3 倍以上。桌面 N 卡优化完一定到目标机器上再离线编译看一遍别偷懒。过分相信一个小技巧的截图收益今天优化了一个 shader帧数特别好结果第二天场景里换了个更贵的后处理整体又卡了。优化是持续推进的事每帧的预算要留余量。5.3 优化不动了怎么办把性能预算留给玩家最后我想说一点额外的东西如果你的 Shader 优化做到“看每个 Pass 都觉得过得去”但整体帧数还是不稳那问题往往不在 Shader而在 DrawCall、场景复杂度、后处理链、CPU 端的 Gameplay 线程、甚至内存带宽被贴图格式霸占。这时候再抠 Shader 指令就是往漏水的桶里倒水。我自己的经验是给项目定一个“Shader 性能预算表”每个角色材质允许多少 ALU、多少个纹理采样、最大寄存器数写在文档里新材质合入前先走一遍离线编译器。养成这个习惯以后场景性能不太容易出现突发性崩溃因为问题在源头就被拦住了。我现在做新项目的优化早就不是“哪里卡改哪里”了而是先立预算和度量体系——没有度量的优化都是自我安慰。你要是刚从节点图化简这条路走出来建议也从搭一套工具链和预算表开始。