Linuxカーネル開発者のDavid Vernetが2026年7月28日、AMD製CPUの周波数制御ドライバ「amd-pstate」にコア別のEPP boostを加えるRFCパッチを投稿した。Steam Deck OLEDで「Civilization VI」の内蔵ベンチマークを実行すると、1% Lowは31.8%改善した。一方、平均fpsと最も遅い側を表すp999フレーム時間には変化がない。Steam Deck全体を32%高速化する変更ではなく、短い待ちの後にCPUクロックが戻らず、遅いフレームが生じる挙動を狙った提案である。
パッチはまだ意見募集段階のRFCだ。Linux本流やSteamOSへの採用は決まっていない。しかも作者は投稿後、測定機をLCD版ではなくOLED版だったと訂正している。数字の大きさより、どの遅延をどう削ったか、実装が現在の電力制御と両立するかが問われている。
平均fpsではなく、遅いフレームを狙う
31.8%という数字は、1台のSteam Deck OLEDと1タイトルに限った測定である。Van Gogh APUをamd-pstateのactiveモード、EPP=balance_performanceで動かし、単一スレッドのCPU性能に依存する「Civilization VI」のグラフィックスベンチマークを使った。各設定を6回ずつ交互に走らせ、Welchのt検定で差を評価している。
結果は次の通りだ。
| 設定 | 高負荷コアの周波数中央値 | フレーム時間側の変化 |
|---|---|---|
| 既定 | 2.43GHz | レンダースレッドの実行率が98%でも周波数が伸びない |
| 全コアをEPP=performance | 3.5GHz | 1% Lowが約16%改善、p999が約40%短縮 |
| 高負荷コアのmin_perfをnominalへ上げる | 3.5GHz | p999が13〜21%悪化 |
| コア別EPP boost | 3.5GHz | 1% Lowが31.8%、p99が4.1%改善 |
コア別EPP boostの差には、1% Lowでp=0.014、p99フレーム時間でp=0.015という値が付いている。ただし平均fpsとp999は変わらなかった。総フレーム数を増やしたのではなく、重い側の一部を軽くした結果だ。したがって、効き方は平均fpsよりも、体感上の引っかかりに現れる。
10ミリ秒・50%・300ミリ秒のEPP制御
EPPはEnergy Performance Preferenceの略で、CPUに性能と省電力のどちらを優先させるかを伝えるヒントである。amd-pstateのactiveモードでは、OSが最小・最大性能とEPPを渡し、その範囲で実際の動作点をプラットフォーム側が選ぶ。Steam Deck OLEDのCPUは公式仕様で2.4〜3.5GHz、APU全体は4〜15Wの枠で動く。
提案されたepp_boostは、各コアが実際に動いていた時間を最大10ミリ秒間隔で調べる。稼働率が50%以上なら、そのコアだけEPPをperformanceの0へ切り替える。高負荷のサンプルが300ミリ秒途切れると、ユーザーや電源プロファイルが指定していた値へ戻す。
この実装は最低性能のmin_perfを持ち上げない。最大性能と要求性能にも触れず、高負荷になった時と休止した時だけCPPC要求を書き換える。全コアを常時performanceへ寄せる方法より対象を絞り、CPUとGPUが同じ電力枠を使う携帯機で、背景コアへ電力を広げない狙いがある。
ただし利用できるのは、amd-pstateのactiveモードを使い、MSR経由のCPPCに対応するシステムだけだ。共有メモリー経由のCPPCでは、スケジューラの処理中に同じ方法でレジスタへアクセスできないため対象外になる。パッチ自体もopt-inであり、有効化しなければ動かない。
0.2ミリ秒の休止後、約2.4GHzへ落ちる
RFCへの指摘を受け、Vernetは60秒のトレースを3回追加取得した。全8 CPUのAPERF/MPERFを1ミリ秒間隔で読み、スレッド切り替えとCPU idleの記録を重ねると、レンダースレッドが0.2ミリ秒を超えて停止した直後、高負荷コアの有効クロックは3.5GHzから約2.4GHzへ落ちた。復帰後も少なくとも8ミリ秒は低いままで、数秒続く場合もあった。CPUのidle stateをPOLLとC1だけに制限しても、この挙動は残った。
ゲームのメインスレッドやレンダースレッドは、フレームごとにfutexやGPU fenceを待って短く眠る。Vernetは、この待ちでハードウェアの性能信号が弱まり、復帰直後の仕事を低い周波数で始めるため、フレーム時間の裾が伸びると説明している。epp_boostは、直近で忙しかったコアへperformanceのヒントを残し、この立ち上がりを速める。
もう一つの測定は、最低性能を上げればよいとは限らないことを示した。高負荷コアのmin_perfをnominalへ上げる案も中央値3.5GHzに達したが、p999は13〜21%悪化した。作者は、CPUとGPUがSMU管理の電力枠を共有するため、CPUを短い待ちの間も高い水準へ張り付けるとGPU側の余裕を削る可能性があるとみている。ただしGPU周波数や消費電力による因果の確認はまだ終わっていない。
RFCの壁は、ユーザー設定EPPと別解
レビューでは、効果より先に制御の責任範囲が問題になった。AMDのK Prateek Nayakは、ユーザー空間の調整ツールが明示的に設定したEPPをカーネルが一時的に変えると、既存ツールの想定と食い違うと指摘した。AMDのMario Limoncielloも、activeモードでハードウェアと競り合う実装になっていないかを問い、passiveまたはguidedモードの方が適する可能性を挙げている。
代替案には、passiveモードとschedutilを組み合わせ、重要なスレッドへUCLAMP_MINを設定する方法がある。EPPを直接上書きせず、スケジューラから最低性能要求を伝える方向だが、VernetはSteam Deckでまだ試していない。ただしProtonは、レンダースレッドを識別するためのWindows API互換機能を実装していないとVernetは指摘しており、どのスレッドを優先するかを別の仕組みで判断しなければならない。
Vernetはguided／passiveモード、UCLAMP_MIN、Dynamic EPPとの比較に加え、合成負荷とturbostatによる追試を挙げている。必要なのは、別のゲームとAMD APUでも1% Lowが改善するか、平均fpsを変えないまま消費電力を抑えられるか、ユーザー設定と衝突しない設計へ落とし込めるかの確認だ。ここを通過して初めて、31.8%という限定実験がSteamOSの実装候補になる。
