移动端GPU带宽优化：纹理压缩与后处理管线改造实战

纹理和后处理的确是最典型的“搬运大户”。在移动端GPU和显存或者说是共用内存之间的带宽往往比GPU本身的算力更早成为瓶颈。很多时候你觉得自己瓶颈在像素着色器太复杂把Shader翻来覆去优化半天帧率纹丝不动结果把纹理格式从RGBA32换成ASTC帧率突然就上去了手机也不烫了。这篇文章我就结合最近的优化日志把这两个“惯犯”的作案手法、取证方式和整改方案一次说清楚。1. 发烫的物理课为什么“搬运”比“计算”更费电先从最底层的物理逻辑说起。手机SoC里GPU核心和内存DDR是两颗不同的芯片数据在它们之间传输的通道就是带宽。GPU要渲染一帧画面必须从内存里把纹理数据、顶点数据、帧缓冲数据全部“搬”到GPU内部处理完再“搬”回去。这个搬运过程每一比特数据的移动都要给总线充电、给内存刷新单位能耗比GPU内部做一次浮点运算高出一个数量级。所以“发烫优化”的核心很多时候不是减少GPU运算量而是减少数据搬运量。功率公式可以简化理解( P \propto C \times V^2 \times f )其中C是负载电容——对于内存总线来说负载电容非常大因为它要驱动整条物理走线。带宽占用越高单位时间内翻转的比特数越多功耗就呈线性甚至超线性上涨。这在手游上的体感就是玩《原神》这种开放世界模型面数并不比某些PC大作高多少但手机烫得快核心原因之一就是移动GPU要持续搬运超高分辨率的纹理和整屏特效缓存。用生活化类比GPU内部计算好比在厨房里切菜内存搬运好比从超市往家里搬菜。切菜再快如果买菜车一次只能装两棵白菜整个做饭流程还是快不起来而且来回跑路消耗的体力功耗远大于切菜本身。纹理和后处理之所以是“惯犯”就是因为它们每个帧都要不间断地搬运巨量数据而且搬运次数往往还不止一次。2. 纹理的搬运账单从RGBA32到ASTC的带宽算术纹理是所有渲染资源里体积最大的一类。一张2048×2048的RGBA32纹理未压缩时占16MB显存。你可能觉得16MB不算什么但关键不在容量而在采样时的带宽消耗。2.1 纹理带宽的精确计算公式每帧纹理带宽 采样次数 × 每次采样的数据量。一个典型移动端游戏帧假设场景里有200个物体每个物体平均被5张贴图影响Albedo、Normal、ORM、Mask、Lightmap每个物体每帧在像素着色器里平均采样30次屏幕分辨率是1125×2436iPhone X级别每个像素都跑一次像素着色器。粗略算一下屏幕像素数约274万总采样次数274万 × 30 ≈ 8220万次如果所有纹理都是RGBA32每像素32bit即4字节采一个bilinear的mipmap层级纹理实际读取的数据量要考虑缓存命中率移动端GPU纹理缓存命中率通常较高但即便是命中率70%每帧搬运的纹理数据量轻松超过200MB200MB每帧60帧就是12GB/s的带宽占用。手机内存带宽LPDDR4x双通道大约在34GB/s左右GPU还要同时处理顶点数据、帧缓冲读写、后处理pass很快就撞上带宽墙。撞墙后GPU被迫stall占用率上不去帧率暴跌手机发烫——因为总线一直在满负荷做无效功。2.2 ASTC压缩的真实收益换用ASTC 6×6块压缩每像素约0.89字节同样的采样量带宽直接从12GB/s降到约3GB/s直接省掉75%。这就是为什么现在的移动平台强制要求纹理用ASTC或者ETC2。具体的对照表纹理格式每像素占用2048×2048体积相同采样量下的带宽权重RGBA324字节16MB1.0基准RGBA162字节8MB0.5ETC2 RGBA0.67字节2.7MB0.17ASTC 6×60.89字节3.6MB0.22ASTC 4×40.4字节8MB0.5ASTC 8×80.5字节2MB0.125注意ASTC 4×4每像素0.4字节不对通常ASTC 4×4是1字节/像素6×6约0.89字节/像素8×8约0.5字节/像素。ASTC块越大压缩率越高但画质损失也越大。实际优化时的经验不需要Alpha通道的贴图优先ASTC 8×8画质损失在移动屏幕上肉眼几乎不可见需要Alpha的UI贴图用ASTC 6×6兼顾边缘质量法线贴图要求精度高建议ASTC 5×5或者4×4如果项目的最低端机型还在用不支持ASTC的老芯片比如某些低端ARM Mali早期型号保守方案是ETC22.3 纹理尺寸与mipmap的搬运数学用ASTC 8×8压缩一张4096×4096的贴图体积约8MB一张就顶16张1024×1024的贴图。这里必须强调体积和带宽有关但真正要命的其实是mipmap缺失。没有mipmap的纹理在透视缩小的情况下GPU会采样原始高清mip层级的纹理并做bilinear过滤。此时缓存命中率跌到惨不忍睹因为远处物体占屏幕面积小采样点在原始纹理上的分布却跨越巨大物理跨度缓存一行载入的数据只有少量被实际使用有效带宽利用率可能跌到30%以下。而正确生成mipmap后远处物体自动采小mip层每帧搬运的数据量可以降低90%。所以很多项目一上来就抱怨“贴图太多烧带宽”排查后发现根本不是贴图数量问题而是trilinear filter的mip bias设置错误或者干脆没生成mipmap。你只需要在导入设置里勾上Generate Mip Maps然后将LOD Bias尽量接近0就白赚一大截带宽。2.4 别忽略UI和粒子纹理UI是纹理搬运的重灾区。一个复杂UI界面大量九宫格拉伸的图、带阴影的按钮、动态数字图片每帧都要全屏刷新。粒子系统每帧生成几千个粒子每个粒子采样一张128×128的光点贴图——单个不大但粒子数量叠加上去后采样次数非常夸张。优化方式除了压缩格式还有一个隐蔽技巧UI缓存为单张RT。如果UI层没有严重动态变化比如战斗HUD中只有血量数字在变可以把整个UI面板烘焙到一张RT上每帧只搬运这张RT而不是几十上百张UI贴图。血量数字变化时只重绘该区域或者用局部Update。3. 后处理链路一帧被搬了N遍的“半成品”后处理是另一个搬运量漏洞。它的本质是“多Pass串行处理”——每个Pass都要读写整张屏幕RT。假设你的后处理链有5个PassBloom提亮 → 高斯模糊横向 → 高斯模糊纵向 → ToneMapping → 色差/暗角。那这一帧除了主场景渲染还有5次全屏RT读取5次全屏RT写入。我们算笔账主渲染分辨率为1125×2436每像素RGBA16后处理RT一般用半浮点每张全屏RT的读写带宽是 1125 × 2436 × 2字节 × 2读写 ≈ 11MB。5个Pass就是55MB注意这是每帧的增量。60帧时额外占3.3GB/s带宽。很多后处理链还远不止5个Pass美术一加再加大佬疯狂最后光后处理吃掉20GB/s都不稀奇。3.1 最容易忽略的RT类型开销很多团队后处理RT无脑用RGBA16或RGBA32F。其实大部分后处理效果用R11G11B10_FLOAT每像素4字节但精度足够就能满足亮度范围可以覆盖到大概±64000对HDR的亮度范围足够。RGBA16是每像素8字节R11G11B10只有4字节直接省一半。不需要Alpha通道的后处理链用R11G11B10一点问题没有。3.2 半分辨率后处理不是“降画质”是“省预算”Bloom、景深、运动模糊这类模糊类后处理数学上本来就是低通滤波。你可以在半分辨率甚至四分之一分辨率下做完整的模糊链再上混合回主RT。人对高频纹理的细节很敏感但对“模糊的模糊”没有任何感知。这个降分辨率操作能把模糊类后处理链的带宽消耗压缩到原来的1/4甚至1/16。以Bloom为例错误的做法是全分辨率RT → 全分辨率提亮 → 全分辨率模糊5次 → 全分辨率合成正确的做法全分辨率RT → 降采样到1/4分辨率 → 提亮 → 模糊2-3次 → 上采样到全分辨率 → 合成合成时加回原场景提亮和模糊都在低分辨率下做上采样混合后再做ToneMapping。视觉差异极小但带宽消耗差了近一个数量级。3.3 Pass合并的艺术来回切换最致命后处理链里最耗性能的不是计算而是RT切换。GPU在渲染Pass之间切换RenderTarget时需要flush管线、更新tile内存、同步数据带来严重的流水线气泡。移动端基于Tile-Based架构的GPUMali、Adreno尤其厌恶这种切换会丢失On-Chip高速缓存中的数据被迫写回DDR。实际优化手段合并相邻Pass如果两个Pass只是做颜色空间的简单线性变换比如LUT调色、伽马校正可以合并成一个Shader在一个Pass里完成避免两次RT读写利用FrameBuffer Fetch在移动端尤其是Mali GPU可以使用framebuffer_fetch扩展直接读取当前像素的值无需额外采样RT让若干Pass可以在同一个RT上原地计算避免频繁切换半/全分辨率RT尽量把同分辨率的Pass排在一起先做完所有全分辨率Pass再统一做半分辨率Pass减少分辨率切换引发的内存重绑定3.4 关于In-Game后处理裁剪还有一条战术优先级问题不是所有后处理都必须每帧全屏跑。景深只有镜头对焦变化时才需要平时可以缓存结果甚至直接关闭运动模糊只在高速移动时开启静止视角直接跳过色差/暗角属于静态全屏效果根本不需要实时计算直接预烘焙到一张覆盖层纹理上泛光Glow适配不同亮度区域时可以用阈值控制只处理超过阈值的像素亮度不足的区域直接跳过这些“视情况开关”的优化后处理是对带宽最大的尊重。4. 一场真实的带宽排查从Profiler数据到纹理替换光讲道理没用把排查链路完整走一遍才能找到最终能落地的优化方向。4.1 用Profiler找出搬运瓶颈我习惯用Unity Profiler Xcode InstrumentsMetal System Trace/ Snapdragon Profiler双管齐下。Unity Profiler能看到DrawCall、三角面和SetPassCall但看不到真实的带宽占用只能看到GPU时间。如果GPU时间高但DrawCall不高基本可以怀疑是带宽或像素填充率问题用Xcode的Metal System Trace可以看到每个RenderPass的带宽消耗和GPU利用率Adreno的Snapdragon Profiler会显示总线负载Mali可以用Streamline如果总线负载长期超过50%带宽基本就是瓶颈了4.2 纹理替换的实测数据最近处理的一个项目场景里有大量建筑外立面贴图都是2048×2048的RGBA32明显是为了法线贴图和Metalness贴图分开存而保留了Alpha通道。整个场景显存瞬间飙到2GB总线负载常年在70%以上手机游戏运行5分钟就发烫降频。我的排查步骤把打开场景前后显存占用和总线负载数据记录下来显存从1.2GB涨到2.1GB用Unity的Memory Profiler按“Texture”排序找出体积最大的top 20贴图发现大量2048×2048 RGBA32的建筑贴图用Texture Analyzer分析后发现Alpha通道全是1没有实际用途将这些贴图改为ASTC 8×8且把Shader里不需要Alpha的采样改成三通道采样结果显存占用降到约700MB总线负载从70%降到35%帧率从42FPS稳定到60FPS手机温度从46℃降到39℃你以为这就完了没有还有更隐蔽的坑……4.3 最隐蔽的坑体积纹理和探针除了常规2D纹理CubeMap和3D纹理体素化光照、体积雾的3D纹理消耗超级大因为它们天生就是“多面”或“多层”。一张1024×1024的Cube用ASTC 12×12压缩后仍然有320KB左右关键是采样的时候GPU需要跨多个面做三线性插值缓存命中率极低。尤其反射探针一个场景挂8个反射探针每个都生成CubeMap带宽直接爆表。这部分我个人的做法是反射探针数量压到2个以下且CubeMap分辨率用128或256远处的探针用SH球谐光照替代体积雾的3D纹理控制低分辨率比如64×64×32且用ASTC压缩部分GPU支持3D纹理ASTC不支持的低端机型直接砍掉体积雾效果4.4 纹理流送Texture Streaming的实用逻辑纹理流送相当于给纹理搬运做一个“饥荒管理”。核心思路只加载当前视野内需要的纹理mip层视角拉远后卸载高mip层回到近景时再动态加载。Unity的Texture Streaming APITexture2D.SetStreamingTexture可以配合LOD系统实现mip分级控制。经验值把最远mip层限制在256或512分辨率近景最高4K这套组合能显著降低内存中的纹理滞留间接降低带宽压力。但要注意流送有延迟如果玩家瞬移镜头会出现贴图突然模糊然后清晰的过程。解决方式是在瞬移时禁用流送强制加载完整mip。不要在战斗激烈时搞流送不然会出现敌人消失的奇观。5. 后处理管线重构一个4Pass改2Pass的完整案例说完纹理把后处理管线优化也走一遍这是我踩过坑之后总结出的经验。5.1 原有管线的问题一个赛车项目的后处理链原本是这样RT_A 主场景渲染RGBA16 RT_B Bloom提亮全分辨率RGBA16 RT_C 横向模糊全分辨率RGBA16 RT_D 纵向模糊全分辨率RGBA16 RT_E Bloom合成回RT_A全分辨率RGBA16 RT_F ToneMapping 色差全分辨率RGBA16 RT_G 暗角合成 UI全分辨率RGBA16这有7个RT每帧写7次、读6次光后处理每帧的带宽约 1125×2436×8字节×13 ≈ 285MB。60帧就是17GB/s——直接吃满整条总线5.2 重构方案我做的调整分辨率分级主场景RT用R11G11B10_FLOATBloom的提亮和模糊全部降到1/4分辨率281×609——不是是282×610左右Pass合并把ToneMapping和色差合并成一个Shader的两个Pass利用同一个RT、一个Pass输出到RT_F另一个Pass直接用FrameBuffer原地处理合并暗角暗角直接预烘焙成一张全屏UV网格纹理在UI合成Pass时叠加不开额外Pass减少写次数Bloom提亮和第一次模糊合并在同一个Pass里提亮结果直接写入半分辨率RT省去一次全屏读写利用Framebuffer FetchToneMapping 色差在碎片着色器里直接读取上一Pass的颜色值无需单独的采样纹理重构后的管线RT_A 主场景渲染R11G11B10 RT_B 降采样 提亮 第一次模糊1/4分辨率R11G11B10 RT_C 横向模糊1/4分辨率R11G11B10 RT_D 纵向模糊1/4分辨率R11G11B10 RT_A 上采样合成回主RTR11G11B10 RT_F ToneMapping色差暗角同一PassR11G11B10实际等效Pass数由5个减到2个模糊部分等效分辨率在1/4下运行带宽计算全分辨率两个Pass主场景 ToneMapping1125×2436×4字节×4 ≈ 44MB半分辨率/低分辨率三个Pass282×610×4字节×6 ≈ 4MB总共约48MB比原来的285MB降低83%。实际帧率提升约20~25%温度直观下降3-5℃。5.3 关于HDR和Color Grading的取舍很多团队看到网上教程就照搬“ACES ToneMapping 完整Color Grading LUT”。但移动端后处理链每多一个Pass都是一笔带宽。ACES是算法开销不额外吃带宽本质是一个复杂的像素着色器但对低端机来说像素着色器会拉高GPU ALU占用间接提高功耗。权衡后我的建议是中低端机用Uncharted2或Reinhard近似曲线做ToneMapping省ALU但保留无私高端机ACES LUTLUT贴图256×16体积小带宽可忽略Color Grading不要太嗨移动屏幕的色彩管理本身就很复杂调色过度反而失真6. 一个容易忽略的补充后处理与Tile-Based GPU的相处之道移动GPUAdreno、Mali、PowerVR都是Tile-Based架构它们有On-Chip的高速缓存Tile Memory。如果一个Pass写的RT在下一个Pass立即被读取并且分辨率完全一致那这块Tile数据可以留在On-Chip不需要写回DDR实现零额外带宽。这个特性的应用方式后处理链中相邻Pass分辨率一致时GPU可以自动复用On-Chip Tile Memory不需要出DDR前提是使用framebuffer_fetch或者subpass机制Vulkan的Subpass否则你仍然在读写DDR一旦中途换了RT比如从全分辨率降到半分辨率Tile Memory就失效了所以当你在移动端做后处理时尽量保持分辨率阶梯的一致性全分辨率阶段一口气做完所有全分辨率效果再降到半分辨率做模糊类效果一次性做完再升回全分辨率。不要“升-降-升-降”来回折腾那是给总线放血。Unity里用CommandBuffer.Blit或RenderGraph的Subpass即可实现。Metal里可用的framebuffer_fetch通过 [[color(0)]] 输入修饰符实现Vulkan支持输入AttachmentOpenGL ES 3.1支持GL_EXT_shader_framebuffer_fetch。7. 最终自查清单纹理和后处理的搬运量整改表优化完所有环节后把这张清单当成最终质检表逐项打勾缺哪项补哪项。检查项具体动作收益等级纹理格式所有无Alpha纹理切ASTC 8×8有Alpha切6×6高纹理Mipmap有透视缩小的纹理全部开启Mipmap并设合理LOD Bias极高纹理尺寸上限限制单张纹理上限场景贴图2KUI贴图1K中纹理图集大量小贴图合图集减少切换纹理的缓存失效率中反射探针CubeMap分辨率限制128或256数量压到2个内高UI缓存静态UI烘焙RT动态区域局部更新高后处理RT格式用R11G11B10_FLOAT/ R8G8B8A8替代RGBA16高半分辨率后处理Bloom/景深/运动模糊在1/4分辨率下运算极高Pass合并尽量一个Shader内做多步运算减少RT切换高Framebuffer Fetch相邻Pass使用On-Chip数据避免DDR读写极高后处理裁剪非必要效果色差/暗角/景深低频或预烘焙中等最后分享一点个人体会。纹理和后处理的优化核心思路永远是“减少搬运次数减少单次搬运体积提升搬运效率”。这三个方向分别对应合并Pass/降分辨率、换压缩格式/调RT类型、保持分辨率阶梯一致/利用On-Chip缓存。每次做性能优化时先在脑子里过一遍这三个维度很多方案的取舍就自动浮现了不必每次都从零开始翻文档。