第4章 GPU频率调节机制

4、GPU频率调节机制：P-state与频率档位、频率调节器类型、ondemand与conservative策略

好，咱们接着聊GPU频率调节。说实话，这块内容我当年刚接触时也觉得有点绕。什么P-state、频率档位、调节器……一堆术语堆在一起。但等你真正调过几次性能，踩过几个坑，就会发现——其实核心逻辑并不复杂。

先说说P-state。P-state，全称是Performance State，翻译过来就是“性能状态”。你可以把它理解成GPU预先设定好的几组工作模式。每个P-state对应一组电压和频率的组合。

举个例子。我手头有一块移动端GPU，它支持P0、P1、P2三个状态：

P-state	核心频率 (MHz)	核心电压 (V)	典型功耗 (W)
P0	1200	1.05	15
P1	900	0.95	10
P2	600	0.85	6

你看，P0是最高性能，P2是最省电。每个档位之间，频率和电压是绑定的。为什么这么设计？说白了，频率跑多高，电压就得给多少。电压低了，高频跑不稳；电压高了，功耗又压不住。

我在项目中遇到过一件事。有次调试一款笔记本GPU，发现它死活上不了P0。查了半天，原来是散热模组没贴好，温度一高，驱动直接锁死在P1。嗯，硬件上的坑，最后还得靠软件策略来兜底。

关键点：P-state不是连续的频率调节，而是离散的档位切换。每个档位都经过出厂验证，保证稳定性和功耗在可控范围内。

有了P-state这个“硬件基础”，接下来就是“谁来决定什么时候切档位”。这个角色，就是频率调节器（Governor）。

Linux内核里，GPU频率调节器有好几种。我挑几个常见的说说：

你想想看，如果GPU一直跑在最高频，功耗和发热都扛不住。如果一直跑在最低频，用户体验又不行。所以ondemand和conservative这类动态调节器，才是实际产品中的主力。

ondemand策略，说白了就是“看人下菜碟”。它每隔一小段时间（比如10毫秒）检查一次GPU的负载。如果负载超过某个阈值（比如80%），就立刻把频率升上去。如果负载降下来了，再慢慢降回来。

它的核心逻辑，用伪代码表示大概是这样的：

if (当前负载 > 升频阈值) {
    直接跳到最高可用频率;
} else if (当前负载 < 降频阈值) {
    每隔一个采样周期降一档;
}

我个人的习惯是，在游戏场景下，ondemand的升频阈值设得低一点，比如60%。这样稍微有点负载变化，频率就能快速响应。但在一些后台渲染任务里，阈值可以设到90%，避免频繁调频带来的功耗抖动。

小技巧：ondemand的采样周期不能设得太短。太短了，频率来回跳，反而增加功耗。我一般设10ms到20ms之间，效果比较平衡。

conservative策略，和ondemand是“亲兄弟”，但性格完全不同。它调频的方式更温和、更保守。

具体来说，conservative不会像ondemand那样“一有负载就跳最高频”。它会一档一档地往上升。比如负载高了，它先升一档，等下一个周期再看，如果负载还高，再升一档。降频也是类似，一档一档往下走。

这样做的好处是什么？功耗波动小，温度更平稳。坏处呢？响应慢，遇到突发高负载，可能会卡一下。

我曾经在一个嵌入式项目里用过conservative。那个设备对功耗特别敏感，稍微波动大一点，电池续航就崩。换成conservative之后，虽然帧率低了点，但续航稳定多了。嗯，有得必有失。

注意：conservative策略不适合对延迟要求极高的场景，比如VR或者实时渲染。那种场景下，ondemand甚至performance才是正解。

我把ondemand和conservative放在一起对比一下，方便你理解：

你可能会问，能不能把两者的优点结合起来？当然可以。现在很多厂商的驱动里，都做了混合策略。比如平时用conservative省电，检测到用户触摸屏幕时，临时切到ondemand。说白了，没有银弹，只有最适合当前场景的方案。

好了，这一节的内容就到这儿。P-state是硬件基础，调节器是软件策略。两者配合好了，GPU才能在性能和功耗之间找到那个“甜点”。下一节，我会聊聊更细粒度的调频技术，比如DVFS和AVS。到时候再接着聊。