第7章 CPU/GPU功耗优化

课程目录第7章 CPU/GPU功耗优化

CPU/GPU功耗优化：频率调度策略、大小核绑定、渲染负载均衡、GPU频率与帧率联动

各位同学，今天我们来聊聊相机功耗优化里最硬核的一块——CPU和GPU怎么省电。

说实话，我早年做相机性能优化时，踩过最大的坑就是「只管帧率不管功耗」。结果呢？相机跑得飞快，手机烫得能煎鸡蛋。用户骂娘，产品经理拍桌子。后来我才明白，功耗优化不是限制性能，而是让每一毫瓦电都花在刀刃上。

7.1 频率调度策略：别让CPU「瞎忙活」

CPU频率调度，说白了就是决定「什么时候跑多快」。我见过不少团队，上来就把CPU锁死在最高频——帧率是稳了，但功耗直接爆炸。

正确的做法是什么？按需分配。相机管线里，每一帧的处理时间窗口是固定的（比如16.6ms @60fps）。你不需要全程满频跑，只要在关键路径上保证算力够用就行。

核心原则：频率 = f(负载)。负载高就升频，负载低就降频。别让CPU闲着没事干还跑在2.8GHz。

我习惯用 cpufreq 的 interactive 或 schedutil 调度器。schedutil 是内核原生的，能根据调度器负载直接算频率，响应更快。

// 示例：通过 sysfs 设置 schedutil 调度器
echo "schedutil" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

// 调整 hispeed_freq 和 hispeed_load，避免频繁跳频
echo 1400000 > /sys/devices/system/cpu/cpu0/cpufreq/schedutil/hispeed_freq
echo 85 > /sys/devices/system/cpu/cpu0/cpufreq/schedutil/hispeed_load

我的经验：别把 hispeed_load 设得太低（比如70%以下），否则CPU会频繁冲高频，功耗反而增加。85%左右是个不错的起点。

7.2 大小核绑定：把活分给「对的人」

现在的手机都是大小核架构（比如4大+4小）。大核性能强但功耗高，小核省电但算力弱。怎么分配？

我见过最蠢的做法——把整个相机进程绑到大核上。你想想看，UI线程、IPC通信、内存拷贝这些轻量级任务，完全可以在小核上跑。只有图像处理、算法计算这些重活才需要大核。

我的建议：

小核（Cortex-A55等）： 处理中断、IPC、内存管理、UI更新
大核（Cortex-A76/A78等）： 跑ISP pipeline、3A算法、HDR合成
超大核（Cortex-X系列）： 只在极端场景（比如4K 60fps录像）启用

// 示例：通过 pthread 设置线程亲和性
#include <pthread.h>
#include <sched.h>

void bind_to_core(pthread_t thread, int core_id) {
    cpu_set_t cpuset;
    CPU_ZERO(&cpuset);
    CPU_SET(core_id, &cpuset);
    pthread_setaffinity_np(thread, sizeof(cpu_set_t), &cpuset);
}

// 将算法线程绑定到大核（core 4-7）
bind_to_core(algo_thread, 4);

注意：别把所有线程都绑死。留一些弹性，让调度器在负载波动时能动态迁移。我曾经因为绑得太死，导致小核满载、大核空闲，功耗反而更高。

7.3 渲染负载均衡：别让GPU「旱的旱死，涝的涝死」

GPU渲染负载均衡，说白了就是让每一帧的渲染任务均匀分布到各个GPU核心上。不均匀会怎样？有的核心忙到冒烟，有的核心在摸鱼。整体帧率没降，但功耗上去了。

我遇到过最典型的场景：相机预览界面，GPU要同时处理预览帧渲染、UI overlay、动画效果。如果这些任务都挤在同一个核心上，那个核心的频率会被拉得很高。

解决方案：

使用多独立渲染通道： 把预览帧、UI、动画分到不同的渲染通道
利用Vulkan的异步计算队列： 把后处理任务丢到计算队列，不阻塞主渲染
动态调整渲染分辨率： 低负载时降分辨率渲染，高负载时恢复

// 示例：Vulkan 多队列提交
VkQueue graphics_queue, compute_queue;
vkGetDeviceQueue(device, queue_family_graphics, 0, &graphics_queue);
vkGetDeviceQueue(device, queue_family_compute, 0, &compute_queue);

// 主渲染提交到 graphics_queue
VkSubmitInfo graphics_submit = { ... };
vkQueueSubmit(graphics_queue, 1, &graphics_submit, VK_NULL_HANDLE);

// 后处理提交到 compute_queue，不阻塞主渲染
VkSubmitInfo compute_submit = { ... };
vkQueueSubmit(compute_queue, 1, &compute_submit, VK_NULL_HANDLE);

避坑指南：我曾经在某个项目里，把后处理也丢到graphics queue里，结果GPU核心负载不均，功耗高了15%。改成compute queue后，问题立刻解决。

7.4 GPU频率与帧率联动：别让GPU「空转」

这是最容易被忽视的点。很多团队的GPU频率策略是：只要GPU有负载，就升频。但你想过没有？如果当前帧率只有30fps，GPU完全可以在低频下完成任务，为什么要跑高频？

正确的做法：让GPU频率跟随目标帧率动态调整。

目标帧率60fps → GPU频率拉满，保证每帧16.6ms内完成
目标帧率30fps → GPU频率降低，只要33.3ms内完成就行
预览界面静止 → GPU频率降到最低，甚至进入idle状态

// 伪代码：帧率-频率联动逻辑
void adjust_gpu_freq(int target_fps) {
    int frame_time_ms = 1000 / target_fps;
    int gpu_freq = calculate_freq_from_frame_time(frame_time_ms);
    
    // 写入GPU频率
    write_to_sysfs("/sys/class/kgsl/kgsl-3d0/devfreq/cur_freq", gpu_freq);
    
    // 设置频率上下限，避免跳频
    write_to_sysfs("/sys/class/kgsl/kgsl-3d0/devfreq/min_freq", gpu_freq - 100000);
    write_to_sysfs("/sys/class/kgsl/kgsl-3d0/devfreq/max_freq", gpu_freq + 100000);
}

关键点：帧率下降时，GPU频率要主动降下来，而不是等负载降低后再被动降频。被动降频有延迟，这段时间GPU就在「高功耗空转」。

7.5 知识体系总览

下面这张图，是我自己总结的CPU/GPU功耗优化框架。你把它打印出来贴在工位上，做优化时对照着看，基本不会跑偏。

7.6 实战避坑清单

最后，我把自己这些年踩过的坑整理成了一份清单。你照着检查，至少能避开80%的功耗问题。

场景	错误做法	正确做法
CPU频率	全程锁最高频	schedutil按需调度，hispeed_load设85%
大小核绑定	所有线程绑大核	轻量任务绑小核，重任务绑大核
GPU负载	所有渲染挤在一个核心	多通道分离，Vulkan异步计算队列
GPU频率	有负载就升频	跟随目标帧率动态调整
帧率下降	等负载降低后被动降频	主动降频，避免高功耗空转

最后一句忠告：功耗优化没有银弹。你调完一个参数，一定要上真机测功耗曲线。我见过太多「理论上省电，实际上翻车」的案例了。

公众号:蓝海资料掘金营，微信deep3321

📚 课程目录

CPU/GPU功耗优化：频率调度策略、大小核绑定、渲染负载均衡、GPU频率与帧率联动

7.1 频率调度策略：别让CPU「瞎忙活」

7.2 大小核绑定：把活分给「对的人」

7.3 渲染负载均衡：别让GPU「旱的旱死，涝的涝死」

7.4 GPU频率与帧率联动：别让GPU「空转」

7.5 知识体系总览

7.6 实战避坑清单