我见过不少项目在做 UE Shader 优化的时候习惯性地盯着材质编辑器的 Instruction Count 抠指令结果 GPU 时长纹丝不动也见过有人把整个后处理链砍掉一半帧率却直线回升。差别在于前者在优化“纸面上的指令”后者在优化“GPU 真正花掉的时间”。要理解 GPU 真正花掉的时间就得回到它怎么执行指令这件事上。这篇文章不打算罗列优化清单而是想用一个更底层的视角——从 GPU 的线程调度、warp、寄存器、带宽这些执行细节出发把 UE 里常见的 shader 优化手段重新推导一遍。适合正在做渲染优化、但总感觉差口气的技术美术和开发朋友。1. GPU 怎么执行 Shader 指令从跑腿小哥模型到 warp1.1 一个跑腿小哥模型SIMT 到底是什么先把 GPU 想象成一支外卖配送团队。CPU 是少数几个非常聪明、能独立决策的资深骑手遇到路口可以自行判断怎么走GPU 则是上千个动作高度同步的新手小哥他们同时骑车出发但听的是同一个大喇叭广播“所有人左转”“所有人右转”。GPU 的线程调度就是这么干的——它不是每个线程独立取指令而是一组线程共享同一条指令流同时执行。这个模型叫 SIMTSingle Instruction, Multiple Threads和 CPU 上的 SIMD 不太一样。SIMD 是单个线程里用向量寄存器同时处理多份数据而 SIMT 是给你写了 N 个逻辑线程硬件把它们捆成一束执行。NVIDIA 把这束线程叫 warp一个 warp 通常 32 个线程AMD 在老架构上叫 wavefront规模是 64 个线程RDNA 之后也改成了 32。有一点必须刻在脑子里一个 warp 内的线程必须“步调一致”。如果 32 个线程走了不同分支比如一半满足 if、一半走进 else硬件只能先执行 if 路径屏蔽掉不满足的线程再执行 else 路径屏蔽掉另一半。这段叫 warp divergence它不会像 CPU 分支预测失败那样造成流水线冲刷但代价是串行执行两个路径吞吐直接减半。我们后面说 UE 里分支优化本质上都是在规避这件事。所以 GPU 的执行单位不是“一个线程”而是“一个 warp”。你在材质编辑器里看到的任何像素级条件判断都要换算成 warp 内的一致性去考虑。1.2 wavefront、CTA 与 kernel绕不开的三个概念在很多技术文章里能看到 kernel、CTA 这些词UE 开发朋友可能陌生但它们和我们写的 shader 其实是一回事。kernel 可以理解为一个跑在 GPU 上的完整程序Pixel Shader、Compute Shader 最终编译出来都是 kernel。GPU 不关心这代码是美术写出来的材质连线还是不透明程序写的通用计算反正最后都是一段指令流被塞进执行单元里跑。CTA 是 Cooperative Thread Array 的缩写直接翻译是“协作线程数组”。再往上抽象一层GPU 启动一个 kernel 时会把整个任务切成很多线程块每个线程块内部的线程可以协作能访问共享内存、能同步这个线程块就是 CTA。在 UE 里写 ComputeShader 时用的 ThreadGroup就是 CTA 的软件形态。一个 CTA 又由多个 warp 组成。为什么理解这个有实际意义因为 CTA 的大小、一个 SM 上能驻留多少 CTA直接影响占用率和资源分配。如果你把一个 compute 的 ThreadGroup 设得特别大共享内存就会吃紧SM 能同时驻留的组数变少设得太小又可能浪费调度带宽。UE 里不少开发者对 ThreadGroupSize 的调整完全靠猜其实就是没把 CTA 和 warp 的关系理清楚。1.3 指令吞吐与内存延迟GPU 真正在乎的两件事从硬件的角度看GPU 优化永远围绕两个瓶颈转计算吞吐和内存延迟。计算吞吐很好理解。ALU算术逻辑单元每周期能执行多少条指令SFU特殊函数单元处理 sin、cos、log、exp 等超越函数时吞吐又不一样。某些函数看着简单实际开销是普通加减法的好几倍这一点在谈指令预算时展开。内存延迟就更关键。GPU 访问显存的延迟动辄几百个周期甚至更多比 ALU 执行一条加法慢了两个数量级。单线程去等数据CPU 会做分支预测、乱序执行来藏延迟GPU 的思路更粗暴——靠并行度堆。一个 warp 因为读取纹理卡住了调度器立刻切到另一个已经准备好的 warp 继续算。只要 SM 上有足够多的 warp 轮流填满每个周期GPU 就不会“饿肚子”。这就是 occupancy占用率为什么重要。占用率可以粗略理解为一个 SM 上“常驻的 warp 数量”和“理论上限”的比值。占用率低了可切换的 warp 变少内存延迟藏不住ALU 空转性能就掉。我们现在耳熟能详的“Shader 太复杂导致占用率下降”本质就是寄存器或者线程数把 SM 的资源吃满挤掉了本可以并行执行的 warp。搞明白这一层再看 UE 里的 shader 优化思路会清晰很多要么减少每个线程的工作量要么提高 SM 上并行 warp 的数量要么减少内存访问的流量。所有优化技巧最后都能归到这三条上。2. 从硬件模型推导 UE Shader 优化指令数、寄存器与 occupancy2.1 指令数不是纸面数字pow、sqrt 与常见高成本节点很多人看材质编辑器里的 NumMaterialInstructions把它当成 GPU 真实耗时这是个初级误区。材质编辑器的统计只是编译中间表示的大致指令数真正下发到硬件后因为指令融合、特殊函数展开、平台差异实际指令完全不同。举一个最常见的例子pow。材质里写 pow(NdotH, power)GPU 上大概率不是一条指令。常规实现是把它转换成 exp2(power * log2(NdotH))这中间就多出 log2、乘法、exp2 三步操作每步还可能由 SFU 执行。SFU 的吞吐通常远低于普通 ALU——这也是为什么“少用 pow、少用 sin/cos、少用 sqrt”这类经验永远不过时。不是这些函数真有多复杂而是它们不在通用 ALU 流水线上。再比如 normalize。看上去是几个乘法加一个 sqrt可编译器还会做倒数开方近似指令数比想象中多。材质编辑器里一个 Fresnel 节点、一个 Custom 表达式都可能展开成三四十条硬件指令。我在项目里见过有人用 Custom 写了三十行云里雾里的数学结果 Stats 面板显示 200 指令换成预计算 Lookup Table 后直接砍到 70。要亲眼看到这些数字建议还是配合 RenderDoc、Nsight Graphics 这类工具去查硬件编译后的统计比材质编辑器里的估算靠谱得多。优化指令数有几个实际可操作的套路把高次 pow 用二次曲线或多项式近似替代前提是你知道视觉容差在哪把视角相关、光源方向相关的计算挪到 UV 空间用纹理预计算利用 mada*bc指令融合让编译器把你的乘加组合起来而不是拆开。2.2 寄存器压力与 occupancyGPU 到底能同时跑多少个 warp占用率不只是看 warp 多就行得先看寄存器够不够。每个线程的局部变量、中间结果都存在寄存器里Shader 越复杂、临时变量越多每个线程占用的寄存器就越多。寄存器不是无限的一个 SM 上寄存器文件总量固定以桌面 NVIDIA GPU 为例常见是 64K 个 32 位寄存器。做个粗略算术假设一个 Shader 每个线程只用 40 个寄存器一个 warp 有 32 个线程就是 32 × 40 1280 个寄存器寄存器总量 65536 个理论上能让 51 个 warp 驻留。但如果材质写得很野每个线程占 128 个寄存器一个 warp 就要 4096 个寄存器理论可驻留 warp 数直接掉到 16 个左右。当大部分 warp 都在等纹理采样结果时调度器手里没有足够多的“备用 warp”填补空槽ALU 就开始空转。这就是为什么很多次我们砍了指令数帧率没变化而只是减了几个中间变量、把若干节点合并成一次计算性能反而上去了——因为寄存器压力降了占用率和延迟隐藏能力上来了。UE 里怎么应对一是避免一个材质里塞进大量 FeatureUber Material 在编辑器里很容易管理但编译后寄存器压力巨大。二是别滥用切成多个小块材质函数再拼起来指令数不一定会变少变量生命周期却可能变长导致寄存器更紧张。三是考虑用 half 精度。移动平台对 half 的收益非常明显桌面端有些 RHI 会因此把半精度提升为单精度效果看平台不能一概而论。想精确确认保险的做法还是看 Nsight 里每个 Shader 的 Register Count 和 Occupancy 数据。2.3 带宽和纹理采样数据流量往往比计算更先爆ShitShader 计算再快如果数据搬不动照样卡。带宽瓶颈常常被忽略因为在材质编辑器里看不出纹理采样背后的流量。GPU 访问数据有清晰的层级每个 SM 有 L1 缓存和共享内存整个 GPU 共享 L2最后是显存 DRAM。缓存命中率高等效带宽就高一旦采样模式很差比如全屏随机访问贴图、UV 抖动剧烈Cache Miss 飙升真实流量全压在显存上速度会掉一个数量级。UE 后处理里这个问题尤其明显。一次全屏模糊需要读取整张贴图写出一张中间 RT高斯模糊两次就是两张全屏纹理的读写。分辨率越高流量增长越夸张4K 下光是一次全屏 RT 读写就可能吃掉上百 GB/s 的带宽。我见过很多人优化 Bloom 时拼命改 Filter 参数最后发现把中间 RT 从 Float32 换成 Float16或者把两个 PASS 合并帧率直接涨了百分之二十。这背后就是带宽。纹理格式也很关键。手机上用 ASTC桌面上用 BC7都能显著降低带宽占用。但代码里如果随意把纹理 Filter 打开、Mip 关闭采样器就会被迫加载多级细节Cache 效率变差。项目里材质复合得厉害时常见优化是把几张 Mask 合并进 Texture 的 RGBA 通道减少一次独立采样。一次采样是一条独立的带宽请求通道再多也只是多传几十字节但采样次数才是真正的成本。2.4 动态分支与 StaticSwitch分支在 GPU 上是被“大家一起跑”的把分支放回 warp 模型里一切就清楚了。分支本身不是洪水猛兽关键看分支条件是否 warp uniform整个 warp 都走同一分支性能无损只有一部分线程走 if、另一部分走 else就会串行执行。UE 材质里有两类分支选择StaticSwitch 是编译期开关运行时值其实是材质参数编译 Shader 时会根据参数直接裁剪掉无效分支生成不同变体Branch 节点是真正的动态分支编译器在 GPU 上生成条件跳转。很多人误以为加了 Branch 就一定会变快不是的。如果那个 branch 条件是采样贴图得到的、或者是像素位置算出来的不同像素结果不同动态分支大概率不如不做——两个路径都要跑还浪费了调度资源。正确的姿势是让分支条件尽量来自 Uniform比如 Instance Data、全局 Scalar 参数、材质参数集的某个值。这样硬件在同一个 draw call 里所有像素拿到的是同一个值warp 内不会发散。另一个思路是改用 StaticSwitch让不用的功能完全不进 Shader 变体这比动态分支更彻底。如果一定要在材质里做像素级动态分支那意味着你正在为一个长尾效果牺牲大部分像素的执行效率。我更建议把这个效果拆成独立 pass 或独立材质用 stencil 或遮罩只服务于真正需要的区域。3. 实战路径先用工具定位热点再做分层优化3.1 打开 GPU Visualizer 和 Shader Complexity看热点在哪里动手优化前先回答一个问题时间到底花在哪个 pass、哪个 draw call 上没有这个数据所有优化都是在盲调。UE 提供了最简单直接的定位方式运行时打开 ProfileGPU或者在编辑器 Tools 菜单找 GPU Visualizer它能列出每一帧所有 GPU pass 的耗时。先看耗时倒序排前面的 pass通常会是 BasePass、Shadow Depth、某几个后处理。如果 SinglePass 特别高再去看是哪个材质在拖后腿。Editor 视图模式里的 Shader Complexity 也能帮快速判断把视图切到 Shader Complexity场景里一片红代表像素着色复杂度高但注意它反映的是指令与采样开销并不直接代表带宽和寄存器更多是“侦查工具”。想要更深入就得用外部工具。RenderDoc 适合看管线状态、资源绑定、每个 draw 的 Shader 分析Nsight GraphicsNVIDIA能提供精确到指令数、寄存器数、占用率甚至内存吞吐的统计是 Windows 平台的硬核选项。AMD 平台也有配套的 RGP 工具。移动端可以用 Mali Offline Compiler 或 PowerVR 工具离线分析 Shader 编译产物。一个容易忽略的坑笔记本或者移动设备在 Profiling 时受功耗和温度影响GPU 频率大幅波动数据很不稳定。测前最好锁频或者至少记录功耗状态否则你“优化成功”了可能只是天气变冷了。3.2 材质、光照与渲染路径的三层优化定位到热点后我习惯把优化拆成三层单独考虑逐层收敛。第一层是材质本身。单个材质内部的计算量、采样数、函数复杂度是最大的可控变量。指令数、寄存器、分支、采样通道都集中在这一层。常见手段用 LUT 替代表达式、用多项式近似替代三角函数、合并纹理通道、优化 Shading Model。还有一个思路是让一部分计算只在需要时发生比如把高频噪声留在顶点阶段或者用 Material Function 封装但用 StaticSwitch 控制开关。第二层是光照。UE 默认的 shading model 很重动态光越多每个像素要做的工作越多。项目从编辑器 demo 到正式包最常见的优化之一就是减少重叠的逐像素光源把远距离光砍成 SH 或烘焙结果。Light Function、自阴影、动态反射探针都是成本项能关就关。DBuffer、Decal、体积雾这类全屏效果在移动端尤其要小心它们会破坏延迟管线的许多优化假设。第三层是渲染路径本身。Deferred 管线的 BasePass 要写 GBuffer存储带宽远超 ForwardForward 管线遇到大量半透明物体又会出现像素重复计算。移动端项目通常更倾向 Forward因为 GBuffer 的带宽开销在移动平台被放得很大。后处理链的 RT 数量、分辨率、格式也是路径层优化的核心漏斗。三层之间有耦合比如一个材质用了 Pixel Depth Offset可能在第一层看着不贵却让 GPU 无法用 Early-Z 提前剔除被遮挡像素最终抬高了整个 BasePass 的像素执行量。这也是为什么不要只盯单层优化。3.3 三个高频场景的优化取舍植被、半透明、全屏后处理拿植被来说它容易卡的原因往往不是 Shader 指令多而是几何碎片太多、Overdraw 严重。每片叶子都是独立的三角形近看远处压到屏幕上一堆半透明像素PS 执行次数暴涨。做植被材质时优先保证两个点尽量无光照或简化光照模型用 Vertex Animation 替代逐像素法线动画Shader 里只保留必要的采样数wind 计算也尽量放顶点。再配合 LOD、材质通道裁剪才能真正解决帧率问题。半透明物体的代价在“像素重复”和“无法利用 Early-Z”。半透明要么需要从远到近渲染要么靠排序算法近似每个半透明像素可能被后面更近的半透明像素完全盖住但白跑了一遍。优化半透明核心是减少半透明面积或者让半透明物体数量尽量稀疏。粒子上用 Mask 代替半透明、远处粒子降成不透明片是见效很快的手段。全屏后处理之前提过多次根本思路就是降低流量降低中间 RT 分辨率、用半分辨率做模糊类效果、一次采样多取数据、尽可能合并多个后处理 PASS。Bloom 这类的效果如果内存和算力都不是问题最简单的优化是别用浮点格式做中间缓存。4. 常见问题与排查速查从现象到对策4.1 典型问题速查表现象、成因与优先动作现象可能原因优先排查方向GPU 占用高Shader Complexity 却不高带宽或者填充率瓶颈Nsight 看 Memory Throughput检查纹理格式、RT 读写、Overdraw单个材质明显拖慢指令数、寄存器、分支发散查看该材质变体的硬件指令和寄存器减临时变量、换半精度切换材质、切换武器明显卡顿PSO 编译 / Shader 变体生成预编译缓存减少材质 Feature 组合手机发热大帧率勉强稳住ALU 或带宽消耗过高降半精度、降分辨率、减少采样数加一个模糊泛光就掉一半帧后处理带宽爆炸降分辨率、合并 PASS、改用更紧凑的 RT 格式这张表不解决全部问题但能帮你快速划定方向。记住占用率低、指令数高优先砍指令占用率不低、内存吞吐高优先压带宽占用率低、内存吞吐也低反而要怀疑是不是 CPU bound 或者绘制调用太碎。4.2 我踩过的几个真实坑指令陷阱、Early-Z 失效与多余 Pass第一个坑是过度依赖数学函数简化。我有一阵子特别热衷把 Fresnel、Pow 改成各种多项式逼近改完发现帧率没变化。后来用 Nsight 看原来显卡编译器早把不少复杂函数优化成预计算表或者专用 SFU 指令了真正吃亏的反而是我改出来的那堆分支和额外乘法。经验是优化前先看硬件统计再决定要不要动公式。第二个坑是 Pixel Depth Offset。为了让地面贴花与地形混合更自然我在材质里开了 Pixel Depth Offset结果 BasePass 整体费了一截。原因前面提过一旦 Shader 在像素阶段改了深度GPU 就没办法在 Early-Z 阶段提前剔除被遮挡的像素所有原本应该被深度测试挡掉的像素都会完整执行一遍 PS。正确做法是在不支持深度写入的场景里选另一个混合方案比如 Depth Fade而不是靠改深度去融合。第三个坑是没用对 Profiler 数据。有段时间我在手机项目上测试每次改了材质都拿 editor 截图对比数据一团乱。后来才发现是设备温度变化导致 GPU 降频优化看起来忽好忽坏。从那以后我跑性能对比一定先让机器预热、锁频再在同一场景同一相机位连续跑几遍取中位数。4.3 优化前必须确认的一个技术细节硬件频率与 Profiler 数据无论是 Nsight、RenderDoc 还是 UE 内置工具Profiler 返回的时间都是基于真实硬件运行的。如果这个硬件正在动态调频你拿到的帧时间就不是稳定可控的数据。桌面 GPU 在负载高时 Boost 到很高频率负载低时又降下来这就导致一个一个第次修改前后对照不稳定。笔记本场景尤其严重因为功耗墙和散热共同影响 GPU 频率可能你只是把风扇转速调高了帧数就上去了。移动端的话建议跑功耗模式下的性能别开性能模式对比因为大多数真实用户用的是默认模式。要让优化结论可信就得把频率变量控制住否则比对结果就是碰运气。另外Nsight Graphics 这类工具在抓取时本身可能影响运行频率它有时会自动锁频。如果你发现 Profiler 里 GPU 频率比平时明显偏低或偏高不要急着下结论先把锁频打开再做前后对照。我个人的习惯是每次接到 Shader 优化任务先打开 GPU 统计看 pass 耗时排行再用 Nsight 看 Compute 和 Memory 两条吞吐曲线。如果 Compute 接近满载我就去砍指令、砍函数、减寄存器如果 Memory 接近满载我就先去压纹理格式、降 RT 分辨率、合并 PASS。这两年实践下来这个习惯帮我避开了绝大多数“白改”的折腾。先把执行模型和带宽模型想清楚再谈优化才是真正的捷径。