3、GPU调优：GPU频率管理、渲染管线优化、帧率控制策略

GPU调优这块，说实话，是平板电脑性能调优里最「吃经验」的部分。CPU调不好顶多是卡顿，GPU调不好，轻则掉帧，重则直接黑屏重启。我这些年踩过的坑，有一半都跟GPU有关。

咱们今天聊三个核心方向：频率怎么管、渲染管线怎么优化、帧率怎么控。这三个点搞明白了，你的平板在游戏和图形场景下基本就稳了。

3.1 GPU频率管理：别让GPU「忽快忽慢」

GPU频率管理，说白了就是决定「什么时候让GPU跑多快」。很多人觉得频率越高越好，其实不是。频率高了，功耗和发热就上去了，平板这种散热受限的设备，很容易触发降频。

我个人习惯用 动态频率调节（DVFS） 策略。但要注意，DVFS的响应速度很关键。我遇到过一个问题：游戏里突然出现大量粒子特效，GPU负载瞬间飙升，但DVFS反应慢了半拍，结果帧率直接掉到个位数。嗯，这就是典型的「调频滞后」。

核心原则： 频率变化要「快升慢降」。负载上来时，频率要迅速拉高；负载下去时，频率可以缓降，避免频繁波动。

具体怎么做？我建议用 多级频率阈值 来管理：

负载区间（GPU利用率） 目标频率 调整策略
0% - 30% 最低频率（如 200MHz） 保持低频，省电
30% - 60% 中频（如 500MHz） 缓慢升频，平滑过渡
60% - 85% 高频（如 800MHz） 快速升频，保证性能
85% - 100% 最高频率（如 1GHz） 立即拉满，但监控温度

这里有个坑：不要用单一的利用率阈值。我曾经在一个项目里只设了80%这一个阈值，结果GPU在79%和81%之间来回跳，频率也跟着上下乱窜，用户体验极差。后来我加了迟滞（hysteresis）机制，比如从低频升到中频需要利用率超过60%，但从高频降回中频需要利用率低于40%。这样频率就稳多了。

小技巧： 可以在驱动层加一个「频率锁定」接口。对于某些对帧率稳定性要求极高的场景（比如VR或AR），直接锁定一个中间频率，避免DVFS带来的波动。

3.2 渲染管线优化：别让GPU「空转」

渲染管线优化，说白了就是让GPU的每个环节都「有事干」，别闲着。你想想看，GPU里有几百个核心，如果因为管线设计不合理，导致大部分核心在等数据，那频率再高也没用。

我重点说三个方向：

3.2.1 减少Draw Call

Draw Call是CPU发给GPU的渲染命令。每次Draw Call都有开销，尤其是小物体的绘制。我见过一个项目，场景里有一千多棵小树，每棵树都是一个独立的Draw Call，结果CPU直接成了瓶颈，GPU利用率才30%。

解决办法是 合批（Batching）。把相同材质、相同网格的物体合并成一个Draw Call。比如那些小树，可以用实例化（Instancing）技术，一次Draw Call画一千棵树。

// 伪代码：实例化渲染
for (int i = 0; i < treeCount; i++) {
    // 以前：每个树一个Draw Call
    // DrawMesh(treeMesh, treeTransform[i], treeMaterial);
    
    // 优化后：一次Draw Call
    DrawMeshInstanced(treeMesh, 0, treeMaterial, treeTransforms, treeCount);
}

嗯，这里要注意：合批不是万能的。如果物体材质不同，或者需要单独裁剪，强行合批反而会降低效率。我建议把Draw Call数量控制在 200-300 以内，超过这个数就要考虑优化了。

3.2.2 优化Overdraw

Overdraw就是同一个像素被重复绘制了多次。说白了，就是浪费。比如你先画了背景，又在背景上画了不透明的物体，那背景的像素就白画了。

我常用的方法是 Early-Z测试。在像素着色器执行之前，先做一次深度测试，如果像素被遮挡了，就直接丢弃，不执行后续的着色计算。这能省下大量GPU计算资源。

注意： Early-Z测试对透明物体无效。透明物体需要从远到近排序绘制，否则会出现半透明叠加错误。我曾经因为没注意排序，导致一个玻璃杯的渲染效果完全不对，排查了半天才发现是绘制顺序的问题。

3.2.3 纹理压缩与带宽优化

GPU的显存带宽是有限的。如果纹理太大，GPU就得频繁从内存读取数据，造成带宽瓶颈。我建议使用 ASTC（自适应可伸缩纹理压缩） 格式，这是移动端最主流的纹理压缩方案。

举个例子：一张1024x1024的RGBA纹理，未压缩时是4MB。用ASTC 4x4压缩后，只有1MB左右，而且画质损失几乎看不出来。带宽占用直接降低75%。

经验之谈： 纹理的Mipmap一定要开。Mipmap虽然会多占用1/3的显存，但能显著减少远处物体的纹理采样开销。我在一个3D场景里做过测试，开启Mipmap后，GPU的纹理单元负载降低了40%以上。

3.3 帧率控制策略：稳定比高帧率更重要

帧率控制，很多人只盯着「跑多高」，却忽略了「稳不稳」。你想想看，一个游戏在60fps和30fps之间来回跳，体验还不如稳定在45fps。人眼对帧率波动非常敏感，尤其是从高帧率突然掉到低帧率时，那种卡顿感特别明显。

我常用的帧率控制策略有三种：

3.3.1 固定帧率锁定

最简单粗暴的方法。根据场景复杂度，锁定一个目标帧率。比如普通界面锁定30fps，游戏场景锁定60fps。优点是实现简单，缺点是灵活性差。

// 伪代码：固定帧率锁定
const int targetFPS = 60;
const float frameTime = 1000.0f / targetFPS; // 16.67ms

while (running) {
    float startTime = getCurrentTime();
    updateAndRender();
    float elapsed = getCurrentTime() - startTime;
    
    if (elapsed < frameTime) {
        sleep(frameTime - elapsed); // 等待剩余时间
    }
}

嗯，这里有个问题：sleep() 的精度不一定够。在Android上，sleep() 的最小粒度是1ms，而且可能被其他线程抢占。我建议用 忙等待（busy-waiting） 或者 vsync 来同步。

3.3.2 自适应帧率

根据GPU负载动态调整帧率。比如GPU利用率超过90%时，把帧率从60fps降到45fps，给GPU留出喘息空间。这样能避免因负载过高导致的突然掉帧。

我做过一个自适应算法：

  1. 每帧计算GPU利用率
  2. 如果利用率连续3帧超过85%，降低目标帧率5fps
  3. 如果利用率连续3帧低于60%，提高目标帧率5fps
  4. 帧率变化范围控制在30fps到60fps之间

这个算法在大多数场景下表现不错。但要注意，变化步长不能太大。我曾经设了10fps的步长，结果帧率在50fps和60fps之间来回跳，体验反而更差。后来改成5fps，配合平滑过渡，就好多了。

3.3.3 帧率与功耗的平衡

平板是电池供电的设备，不能为了帧率不管功耗。我建议在帧率控制中加入 功耗预算 的概念。

举个例子：假设电池剩余电量只能支持30分钟的高性能模式。那我们可以设定一个功耗上限，比如4W。当GPU功耗接近4W时，自动降低帧率或频率，保证续航。

我的做法： 在驱动层暴露一个「功耗预算」接口。上层应用可以设置当前场景的功耗上限，驱动根据这个上限动态调整GPU频率和帧率。这样既保证了性能，又控制了功耗。

我曾经在一个平板项目里用过这个方案。用户在看视频时，功耗预算设为2W，GPU跑在最低频率，帧率锁定30fps。用户玩游戏时，功耗预算设为6W，GPU跑在最高频率，帧率锁定60fps。效果很好，续航提升了将近40%。

避坑指南： 帧率控制一定要考虑 帧生成时间（Frame Time） 的稳定性。我曾经只关注平均帧率，结果发现虽然平均有55fps，但每帧的生成时间波动很大，有的帧只用了10ms，有的帧用了30ms。这种波动会导致明显的卡顿感。后来我改用 帧生成时间的标准差 作为优化指标，效果立竿见影。

好了，GPU调优这块就聊这么多。频率管理、渲染管线优化、帧率控制，这三个点环环相扣。频率管好了，渲染管线优化了，帧率自然就稳了。反过来，帧率控制好了，也能反过来指导频率管理。嗯，这就是一个系统工程。

← 上一章 📖 返回目录 下一章 →