移动端GPU带宽优化：纹理压缩与后处理Pass减负实战

做发烫优化做了这么多期纹理和后处理这两个“搬运量”大户几乎每次出现发热问题都能看到它们的身影。这一篇我不绕弯子直接抓这两个惯犯。先说清楚一件事设备为什么会发烫本质上就是单位时间内数据搬运量太大GPU 的计算单元和内存控制器长期处于高负载功耗上去了热量自然散不掉。而纹理采样和后处理全屏 Pass恰恰是移动端 GPU 里搬运量最大的两个环节。我见过太多项目模型面数砍了一轮又一轮粒子数量减了一半结果发热问题还在最后用 Profiler 一查罪魁祸首就是一张超大纹理和一条充满冗余 Pass 的后处理链。这篇就把它们的底细彻底扒干净。做手机游戏、AR/VR、实时渲染工具的同学可以直接照着文里的思路排查刚入行想搞懂“性能优化到底在优化什么”的新手也能从中建立一套完整的带宽意识。1. 追凶第一步搞懂纹理和后处理凭什么“搬运量”最大1.1 纹理带宽层面的隐形黑洞纹理占用的不光是显存容量真正要命的是采样时消耗的带宽。片元着色器每处理一个像素就要从显存里取一次纹理数据。做一个粗糙的估算1080p 分辨率下每个像素只做一次纹理采样一帧就要读取 1920 × 1080 × 4 字节大约 8MB 数据。跑 60 帧每秒就是 480MB。注意这只是一个纹理、一次采样的理想情况。真实项目里几乎没有这么温柔的场景。一个片元里采样四五张纹理是常态再加上 mipmap 切换、各向异性过滤的额外采样搬运量瞬间翻好几倍。比如各向异性过滤开到 16x某些角度下每个像素的采样次数可能翻几倍带宽消耗直接爆炸。更隐蔽的是很多美术资源喜欢用 4096 甚至 8192 分辨率的贴图这些贴图如果在屏幕上只占几百个像素绝大部分采样都在浪费带宽而且浪费得毫无意义。我自己在真机上抓数据时发现很多发热严重的场景纹理相关的带宽占比能到 40% 以上。这个时候你去找 CPU 的 GC 问题去优化逻辑代码一点用都没有因为瓶颈在内存控制器那边整个系统都在忙着搬运像素数据。1.2 后处理把整帧画面一遍遍搬来搬去后处理的问题更直观。每做一个后处理效果就是一次全屏 Pass读整张颜色缓冲做一轮计算再写回新缓冲。一个 Bloom 效果可能需要降采样到 1/4 分辨率、做两次模糊、再上采样合并这就四五个全屏 Pass 了。如果项目里再叠上景深、运动模糊、色彩校正、暗角、噪点整条后处理链跑下来十个 Pass 很常见。这意味着什么1080p 的 RGBA16F 浮点缓冲一个 Pass 读写就要搬约 16MB 数据8 字节每像素 × 2 次。十个 Pass 就是 160MB 每帧60 帧每秒接近 10GB 的搬运量。这个数字放在移动端发热几乎不可避免。特别是有些项目习惯创建一堆 Render Target来回切换。Render Target 切换在移动端 GPU 上的开销比 PC 端大得多每一次切换可能都要 flush 管线代价极高。所以我常说后处理链优化的核心就一句话减少全屏读写的次数控制缓冲的数据格式。1.3 “搬运量”的量化理解带宽如何转化为发热为了更好理解可以把 GPU 想象成一个工厂显存是仓库计算单元是工人。纹理采样和后处理全屏读写相当于工人反复从仓库搬货。仓库的传送带内存总线宽度有限搬运量一大传送带就堵住了工厂只能加电加速功耗随之飙升。有个简单的公式可以估算发热趋势功耗 ≈ 动态电容 × 电压的平方 × 主频。总线堵了之后GPU 会把频率拉高试图缓解瓶颈电压也跟着上去功耗呈平方级增长温度自然压不住。这就是为什么解决发热问题往往不是降频而是减少搬运量——把不必要的纹理采样、多余的 Pass 砍掉之后GPU 不需要那么高的频率也能跑满帧率体温自然下降。我实际测试过的印象很深某个场景把带宽从 12GB/s 降到 7GB/s 之后功耗降了将近 1.2W电池温度下降了大概 3 度。所以优化发热问题盯着带宽这个核心指标比盲目改代码、砍画质要有效得多。2. 纹理减负实操格式、尺寸、mipmap 三板斧2.1 纹理压缩格式选型选对格式等于直接减负一半我在项目里见过很多“搬运量”失控的案例根源就是纹理格式没有任何优化。美术直接丢一张未压缩的 RGBA8888 纹理进来或者项目为了省事把所有纹理都转成同一种格式完全不考虑平台差异。这种做法在发热优化里属于技术债早晚要还。纹理压缩这块移动端最值得掌握的是 ASTC 和 ETC2PC 端则用 BC7。做个简单对比格式每像素位数特点适用平台RGBA888832 bpp无压缩画质最好带宽灾难不推荐用于运行期资源ETC2 RGB4 bpp压缩比高Android 全兼容Android 基础兜底ETC2 RGBA8 bpp带 alpha压缩比适中Android alpha 图ASTC 4x48 bpp画质接近 RGBA体积 1/4iOS / 中高端 AndroidASTC 8x82 bpp体积 1/16远看画质可接受大尺寸背景、低频纹理BC78 bpp画质好但移动端兼容性差PC / 主机ASTC 最大的优势是块尺寸可变4x4 到 12x12 都可以选。块越大压缩率越高画质损失也越大。实际项目里我习惯这样分配角色贴图、UI 大图用 ASTC 4x4 或 6x6场景大纹理、远景贴图用 ASTC 8x8能肉眼看出区别的地方再局部换成高规格。如果目标平台包含低端 Android建议保留一套 ETC2 作为 fallback在加载时按机型选择加载哪套纹理。做纹理压缩格式切换时必须在目标手机上肉眼检查一遍高光边缘、天空渐变、UI 文字这三类最容易出问题的区域。ASTC 在高频细节多的地方会有块状噪声金属高光边缘容易发糊如果美术验收时没发现上线后就会被玩家截图吐槽。2.2 纹理尺寸与 mipmap别让“高清”变成“发热元凶”格式之外纹理解析度和采样策略是更大的“搬运量”决定因素。这一步建议用“屏幕占比预算”的思路来管。一张 UI 背景图屏幕宽最多占 1080 像素美术却给了 4096 的原始图这就是浪费。3D 模型贴图同理先看模型在镜头里最大可能占多大再反推纹理尺寸。场景中最常见的 2048 贴图实际渲染可能只用了屏幕的三分之一完全可以降到 1024 甚至 512。mipmap 这一点很多人容易忽略。没有 mipmap 的纹理在物体远离相机时采样点会稀疏地落在大纹理上显存缓存命中率极低带宽消耗成倍增长。打个比方你要在一张世界地图上找某个城市的名字可你偏偏要凑近了看每次只能看到一小块找起来又慢又累。有了 mipmap相当于提前准备好不同缩放级别的地图看远处时直接用缩略版效率高得多。各向异性过滤也要控制。手机上开 4x 或 8x 就足够了16x 在斜视角场景下带宽消耗明显增加视觉差异却微乎其微。我用 RenderDoc 抓过帧对比同样的场景各向异性从 16x 降到 4x纹理带宽能省下近 20%。这里多说一句。做离线重建或者扫描资源的团队应该遇到过 openmvs 这类工具生成的纹理贴图动辄 8K 甚至更高。直接把这种贴图扔进实时引擎根本跑不动。这类资源导入引擎之前一定要先做好尺寸规划、格式压缩和 mipmap 生成否则它就是移动端的发热炸弹。2.3 纹理图集与纹理流送从低频细节里再“榨”一笔还有一种不易察觉的浪费来自大量重复的小纹理。我见过一个项目的 UI 界面有两百多张 256×256 的小图标每张都单独采样、单独切换绘制开销和带宽开销翻倍。解决办法是合并成图集不仅减少绘制批次还能缓解纹理切换的开销。不过图集有个副作用mipmap 会导致相邻贴图边缘渗色。解决方法是每张纹理在原始图集里预留 padding或者叫“内边距填充”需要美术在出图时预留。我在项目里固定用 4px 的 padding然后开启纹理的 mipmap 和无缝采样基本能杜绝边缘混色问题。对于那些地图巨大、场景广阔的开放世界项目纹理流送几乎是必备手段。只加载相机附近需要的纹理块远处的直接使用低精度版本。这个方案做起来相对复杂但收益非常大。如果你的项目目前不需要这么重型的方案也可以用更简单的方式替代把场景里的纹理分成“贴脸可见”“中距离可见”“远距离可见”三个级别运行时按相机距离切换对应的 mipmap 级别效果也非常明显。另外做纹理资源规划时可以借鉴图像分析领域提取纹理特征的做法用灰度共生矩阵算出对比度、能量、熵这些指标评估哪些纹理的“视觉复杂度”高哪些纹理的细节本来就少。在实时渲染里我们可以用同样的思路做资源分级高频细节丰富的纹理保留高分辨率、高标准压缩格式大面积的墙面、地面、天空这类低频纹理优先降级为低分辨率、高压缩格式。这比美术凭感觉拍脑袋定尺寸靠谱得多。3. 后处理减负实操用最少次数搬运换最大画质收益3.1 先算一笔账你的后处理链到底搬了多少数据做机加工的朋友听到“后处理”想到的是 Hypermill、UG 这些 CAM 软件里把刀路数据转成机床代码的环节核心是数据再编排、再输出。图形渲染里的后处理本质上也是同一套逻辑把已经渲染好的像素数据再搬出来做一轮加工然后写回。所以在优化之前先给自己算笔账。假设你的项目是 1080p 分辨率后处理缓冲用的是 RGBA32F每像素 16 字节。一帧画面只读一次就是 8.3MB读写各一次就是 16.6MB。如果后处理链有 6 个 Pass一帧就要搬约 100MB60 帧每秒就是 6GB/s。这个数字已经很可怕了。这里有一个经验法则后处理缓冲的格式能不用浮点就不用浮点能用半浮点就不用全浮点。RGBA16F8 字节每像素比 RGBA32F 直接省一半带宽如果某个 Pass 用不到 alpha 通道R11G11B10 是更好的选择纯色彩操作甚至可以直接用 R10G10B10 或 RGBA8。把几个 Pass 的缓冲格式降下来带宽降幅立竿见影画面几乎看不出区别。3.2 分辨率分级低频率特效放心用低分辨率后处理效果的“感知频率”不同对分辨率的需求差异极大。Bloom、景深、运动模糊、屏幕空间环境光遮蔽SSAO这些效果本质上是低频信息降到 1/4 甚至 1/8 分辨率做视觉上没人看得出来但带宽能省一大截。我在项目里常用的策略是这样特效类型推荐分辨率原因Bloom 光晕1/4 或 1/8光晕是低频扩散低分辨率影响微弱景深模糊1/4模糊本身就是降频操作运动模糊1/4高频细节本来就糊掉了SSAO / 环境光遮蔽1/2 或 1/4遮蔽是低频信息分辨率要求低色彩校正、色调映射全分辨率或 1/2涉及边缘锐利变化降太多会出现色阶断层抗锯齿TAA / FXAA全分辨率抗锯齿就是为了处理亚像素边缘必须全分辨率拿 Bloom 来说很多引擎默认从一开始就在全分辨率做降采样其实完全没必要。Bloom 的正确做法应该是先把高亮区域降采样到 1/4 或 1/8在低分辨率下做几次模糊再逐级上采样合并回去。这样整条链路的移动量只是全分辨率方案的 1/16 左右视觉差异微乎其微。3.3 合并 Pass 与减少 Render Target 切换把“搬运次数”降下来后处理优化里最直接的“减搬”手段就是把多个 Pass 合并成一个。我有一个很深的体会每次创建新的 Render Target 并切换过去移动端的代价比你想象的大得多它可能强制 GPU 等待上一次渲染全部结束造成流水线气泡。常见的合并手法暗角、噪点、色彩分级这类简单效果全部写进色调映射的 Shader一个 Pass 完成景深的散景模糊和 Bloom 的模糊可以共用中间缓冲只需要在算法上做点小调和如果项目里同时有体积光和泛光可以先在低分辨率下算出光照贡献再一次性合成。我见过最夸张的方案调整是一条原本 12 个 Pass 的后处理链最后优化成 5 个 PassBloom 半分辨率处理暗角/噪点/色彩校正全并入最后的 Tonemap Pass景深只保留近景半分辨率模糊另外两个特效直接砍掉。画质整体几乎没变化但带宽少了将近一半。说到合并思路其实和 AI 推理里的后处理流程是相通的。做过 YOLO 这类目标检测项目的人都知道模型输出的一堆候选框如果在 GPU 上频繁做解码、NMS中间 buffer 来回创建销毁性能也会非常难看。优化思路同样是合并 kernel、减少中间数据往返把多次小搬运合并成一次大搬运CPU 与 GPU 之间的同步次数降下来性能自然就上去了。3.4 后处理发热排行哪些特效是“惯犯”中的“惯犯”根据我在多个项目的统计后处理特效的“发热贡献”大致可以排个序特效发热贡献备注多层 Bloom / 高质量光晕极高多重降采样上采样搬运量爆炸屏幕空间反射SSR极高每个像素多次 ray march计算量巨大体积光 / 体积雾高通常要多次 ray march 采样 3D 纹理高质量景深散景高大半径模糊采样次数多时域抗锯齿TAA中高历史缓冲读写叠加抖动和重投影计算SSAO / HBAO中低分辨率下可接受全分辨率则偏大色调映射 / 色彩校正低单 Pass 简单计算不占带宽暗角 / 噪点低可以并入其他 Pass成本极低我在移动端项目里优先砍掉的高发热特效排第一的是 SSR。手机屏幕上小反射细节肉眼很难分辨但发热贡献却排在最前面性价比极低。其次就是多层 Bloom把层数从 4 层降到 2 层发热能明显下降。体积光和景深优先降低分辨率和采样次数不要轻易删因为它们对画面氛围帮助很大。4. 实战复盘一次“电量哗哗掉”的优化全程4.1 现象与 Profile 数据去年我接手过一个中重度 3D 项目帧率稳在 60但在中端 Android 手机上玩 15 分钟电量掉了接近 20%电池温度摸上去明显发烫已经到 43°C 左右。用 Snapdragon Profiler 抓数据结果非常典型指标优化前GPU 总线带宽11.8 GB/s纹理采样占比41%后处理 Pass 数11帧渲染时间GPU12.5ms电池温度15分钟43.1°C这个场景并没有特别复杂的物理、粒子特效问题几乎全部集中在纹理和后处理上。所以定位方向很明确按纹理、后处理两块逐个排查。4.2 纹理维度从一张“8K”纹理开始查先查纹理。我把场景里的纹理资源列了一张清单按分辨率和格式排序结果一眼就看到问题某几个核心场景物体用的是 4096×4096 的 RGBA8888 未压缩纹理还有大量 2048 纹理即使屏幕占比并不高。另外部分地面贴图没勾选 mipmap采样缓存命中率低得离谱。处理方式如下将所有 4096 纹理降到 2048并在导入管线里统一转成 ASTC 6x6detail 纹理保留 ASTC 4x4地面、墙面这类大面积低频细节贴图直接降到 1024用 ASTC 8x8所有纹理开启 mipmap各向异性过滤统一改为 4x在场景里单独检查 UI 背景确认没有隐藏的大尺寸纹理“漏网”。改完之后带宽数据立刻下降。纹理采样在总线带宽中的占比从 41% 降到 22%这一项就省下了约 25% 的总带宽。4.3 后处理维度把一条“十一道工序”流水线砍到五道接着处理后处理链。原工程的后处理链有 11 个 Pass从上到下依次是Tonemap → Bloom含 4 次降采样、4 次模糊、2 次上采样→ DOF → 色差 → 暗角 → 噪点 → 颜色分级这条链子里色差Chromatic Aberration在手机屏幕上几乎不可感知砍掉没有任何损失。暗角和噪点直接并进最后的 Tonemap Shader完全不额外占 Pass。DOF 从全分辨率降为 1/4 分辨率实现。Bloom 的光晕模糊在 1/8 分辨率下做然后逐级上采样合并。优化后的后处理链长这样Tonemap 暗角 噪点 颜色分级1 Pass→ Bloom1/8 分辨率模糊 上采样合并共 3 Pass→ DOF1/4 分辨率2 Pass总 Pass 数从 11 降到 6缓冲格式从 RGBA16F 为主降到部分 Pass 使用 R11G11B10。4.4 优化前后数据对比最终在真机上跑了同场景、同机型、同样 15 分钟测试数据对比如下指标优化前优化后变化GPU 总线带宽11.8 GB/s7.2 GB/s-39%纹理采样占比41%22%-19pp后处理 Pass 数116-5帧渲染时间GPU12.5ms9.3ms-25.6%电池温度15分钟43.1°C39.4°C-3.7°C平均功耗4.6W3.7W-0.9W温度从 43°C 附近降到了 39°C 左右功耗降了接近 1W。帧渲染时间也缩短了说明 GPU 不再是满负荷运转。这里要强调一下整个过程中我没有降低任何画质档位只是把“搬运量”压了下来这就回到了我反复说的那句话发热问题的本质是搬运量问题不是你画质好不好的问题。5. 问题速查与定位技巧5.1 常见问题速查表问题现象可能的纹理原因可能的后处理原因温度高但 GPU 占用不高纹理格式未压缩/带宽型瓶颈RT 切换频繁GPU 等待帧率波动明显mipmap 缺失缓存命中率低Pass 过多每帧搬运量不稳滑动场景突然发烫大面积纹理动态加载视口变化触发全屏重算发热集中在复杂画面高频细节纹理过多全分辨率 Bloom/DOF/SSR长时间运行后变卡纹理缓存未释放后处理缓冲未滚动复用低端机特别容易热ASTC 不支持回退到了 ETC2 高规格Pass 未按性能档位动态调整5.2 高效定位“搬运量”消耗点的方法真机调试工具优先用 Snapdragon Profiler高通平台和 Xcode GPU Frame Capture苹果平台。打开 GPU 计数器里的 Busy / Stall 指标和带宽读数能直接看到哪一大类资源消耗最多。如果你手头没有这么细的工具还有个非常高效的二分法把所有纹理临时替换成 1×1 白图跑一轮测试看温度和功耗再把后处理链全部关掉跑一轮看数据和耗电。两次结果一对比立刻能判断是纹理还是后处理的“搬运量”更大。我经常用这个方法在新项目里快速定位发热来源十分钟就能出结论。另外用 Unity 或 UE 的同学可以在 Frame Debugger 里按 “RenderTarget” 列表看每个 Pass 的缓冲格式和尺寸。如果一个项目的 RT 列表里有大量 RGBA16F/32F 而且尺寸是屏幕分辨率这就是后处理搬运量过高的直接证据。5.3 踩了几次坑之后我总结的经验后处理 Shader 里最容易藏雷的写法是在循环内部做“随机访问”式采样。比如为了做模糊效果写了多层 for 循环每层采样附近 20 个像素。这种写法在 PC 上没感觉在移动端上带宽瞬间爆炸。正确的做法是先把采样次数压到合理范围或者用两个 Pass 分别做水平方向和垂直方向的高斯模糊用 9-tap 甚至 5-tap 就能达到肉眼理想的效果。关于减 Pass要注意半分辨率处理边缘闪烁的问题。半分辨率下做景深时前景和背景的交界处容易闪烁或出现拖影尤其是有 alpha 混合的物体交界。解决办法是对深度和物体 ID 做边缘检测交界区域回退到全分辨率处理但只处理局部不增加全屏 Pass。低规格机型适配也是一个重点。同样是 Android 手机高端机可以全特效低端机必须要动态关掉一些高发热效果。我建议内置三档画质低端机直接砍掉 Bloom 里最重的那层光晕、SSR 直接关闭、DOF 降半分辨率中端机保持后处理默认配置但锁 30 帧或使用自适应分辨率高端机再上全部特效。这套“分级方案”比一个画质选项打天下要合理得多。材质这块还有一个常见失误用金属高光比较强的材质时纹理压缩格式的块状噪声会被放大得非常明显看起来像表面有一层脏东西。遇到这种情况优先检查是不是 ASTC 压缩比太高把次要通道比如粗糙度、金属度拆到单独的 4 bpp 纹理里主反照率保持 6x6 或 4x4通常能解决问题代价是增加一次纹理采样但对总体带宽来说反而是节省的。最后分享一个小技巧。在项目初期就建立“搬运量预算”的概念像管理内存一样管理纹理和后处理 Pass。给后处理设置单帧全屏读写次数的上限超出即报警给纹理设置全场景总采样带宽预算超了就自动降级。这样做两三个版本之后团队里的美术和 TA 都养成了自发检查资源体积、合并 Pass 的习惯发热问题会越来越少而不是每次上线前靠优化师去“救火”。