AMDが2026年3月に公開した技術文書から、一部のZen 6製品が「CPPC Performance Priority」に対応することが分かった。最大クロックを引き上げる機能ではない。CPUが電力や温度の上限にぶつかったとき、ソフトウェアがコアごとに異なる性能下限を示し、重要な処理を担うコアの周波数を先に守らせる仕組みである。
Ryzen向け調整ツール「HYDRA OC」の開発者1usmusから情報提供を受けたVideoCardzは、この仕組みをゲームの1% Low改善につながる技術として報じた。方向性には裏付けがある。ゲームのメインスレッドは、GPUや別スレッドを待つ短い休止を繰り返すため、平均負荷が高くても復帰直後の周波数が間に合わず、遅いフレームを生むことがあるからだ。
ただし、Zen 6で1% Lowが改善したという測定結果はまだない。報道で参照される31.8%という数字は、Steam Deck LCDの旧世代APUを使ったLinux向けRFCパッチの実験値である。AMD公式文書、OS向けパッチ、実験結果を分けて読むと、公開されたのは電力制約時のコア別の絞り込み基準、Class of Service単位のL3外部帯域上限、メモリー操作のサンプリングであり、Zen 6のゲーム性能そのものではないと分かる。
Zen 6で確認されたのは「絞る順番」の制御
CPPCは、OSが抽象的な性能値を使ってプロセッサへ要求を伝え、ファームウェアが電圧や周波数を調整する枠組みである。Zen 6向けのPerformance Priorityは、ここへコア別の「FloorPerf」を加える。
FloorPerfに設定できるのは、そのコアが持つLowestPerfからHighestPerfまでの値だ。電力または温度の制約が生じると、ファームウェアは各コアをFloorPerfに相当する周波数まで先に絞り、それでも足りなければさらに下げようとする。ゲームのメインスレッドが動くコアに高いFloorPerf、背景処理のコアに低い値を与えれば、CPU全体の余裕がなくなった場面で優先順位を作れる。
FloorPerfは最低クロックを保証する値ではない。制約が厳しければ、優先コアもFloorPerfを下回り得る。さらに、ハードウェアが扱える異なるFloorPerfの種類数は「FloorPerfCnt」で示され、0なら無制限だが、非0の上限を超えて値を使うと挙動は未定義になる。
AMDの文書は対応範囲を「一部のZen 6製品」としており、デスクトップRyzenでの採用を約束していない。Linuxでは2026年3月、コアごとのfloor_freqと対応レベル数をユーザー空間へ公開するパッチ群が投稿された。つまり、シリコン側の機構は公開済みでも、製品への搭載とOSがどう使うかは別の段階にある。
31.8%改善はSteam Deck上の限定実験
ゲームとの結びつきを示す材料は、2026年7月28日に投稿されたLinuxの「per-core EPP boost」RFCにある。EPPは、CPUが性能と省電力のどちらを優先するかを示すヒントだ。提案されたパッチは各コアの実行時間を最大10ミリ秒間隔で調べ、稼働率が50%以上なら、そのコアだけEPPをperformanceの0へ切り替える。高負荷のサンプルが300ミリ秒途切れると元の設定へ戻す。
テストにはSteam Deck LCDのVan Gogh APUと「Civilization VI」の内蔵グラフィックスベンチマークが使われた。各設定を6回ずつ交互に実行した結果は、単純に最低性能値を上げる危うさも示している。
| 設定 | 高負荷コアの周波数中央値 | フレーム時間側の結果 |
|---|---|---|
| 既定 | 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改善は0.015だった。一方、平均fpsとp999には変化がなかった。平均性能を押し上げたというより、短い休止から戻るコアの立ち上がりを整え、遅いフレームの一部を減らした結果と読める。
さらに興味深いのは、min_perfを上げた案が悪化した点だ。Steam DeckではCPUとGPUが電力枠を共有する。CPUコアを名目性能以上へ張り付けると、SMUによるCPUとGPUのブースト配分が乱れ、最も遅い側のフレーム時間を悪化させたと開発者は説明している。FloorPerfもコア別の下限を扱うが、同じ実験結果をZen 6へ移せるわけではない。OS、ファームウェア、電力枠の協調が整わなければ、優先順位を付ける操作が逆効果になり得る。
周波数情報、性能下限、帯域制御、観測は別の層
Zen 6のゲーム最適化として一括りにされている技術は、役割も成熟度も異なる。
CPPC HighestFreqは、OSへコアの実際の最高周波数を渡すためのインターフェースだ。従来の抽象的なCPPC性能値から線形補間すると、周波数との対応がコア間でずれる場合がある。2026年5月のLinuxパッチは、HighestFreqが提供される環境では、その値をCPU capacity計算とブースト比の判定に使うよう提案した。投稿時点ではACPI 6.7へ向けた仕様提案であり、正しいコア配置を自動で保証する機能ではない。
Global Bandwidth Enforcement（GLBE）は、一部のZen 6製品で確認されているPQOS拡張である。複数のQoS Domainをまたぐ論理プロセッサ群に対し、Class of Service単位でL3外部帯域の上限を設定できる。背景処理を低い上限のClass of Serviceへ割り当てれば、前景処理との帯域競合を抑える用途は考えられる。しかしGLBE自身は背景タスクを見分けず、RAM容量を配分する機能でもない。OSや管理ソフトがタスクを分類し、各Domainへ同じ上限値を書き込んで初めて働く。
しかもGLBEが測るのはDRAM帯域ではなくL3 External Bandwidthだ。キャッシュコヒーレンシーの通信を含む一方、I/Oなど制御外の通信もあるため、メモリー帯域全体とは一致しない。
IBS Memory Profilerも制御機構ではない。これはメモリー操作へ絞った命令ベースサンプリング機能で、L3ミス、長いロード遅延、ストリーミングストアなどをフィルターして観測できる。ボトルネックの特定には役立つが、検出した処理のL3アクセスを自動で制限するわけではない。メモリー操作を観測するIBSとL3外部帯域へ上限を課すGLBEの間を埋めるソフトウェアが必要になる。
Ryzenで見るべきは最大fpsより制御の連携
Zen 6のPerformance Priorityは、CPU全体を一律に速くする発想から、前景処理へ限られた余裕を残す発想への転換を示す。特に、電力枠をCPUとGPUで共有するAPUや、背景アプリを動かしながら遊ぶ環境では理にかなっている。
製品評価で確認すべき点は三つある。まず、どのデスクトップ／モバイルRyzenがFloorPerfとGLBEを実装するか。次に、WindowsとLinuxがゲームの重要スレッド、短い休止、背景処理をどこまで正しく分類できるか。最後に、CPU負荷の異なる複数ゲームで、平均fps、1% Low、p99とp999のフレーム時間、消費電力を同時に測ることだ。
AMDの公開資料は、一部のZen 6製品向けにコア別性能下限と広域帯域制御をそれぞれ文書化している。両機能が同じデスクトップRyzenへ載るとは公表されていない。そこから「マイクロスタッターを解消する」までには、製品採用、OS実装、ワークロード別の検証が残る。次世代Ryzenの価値を決めるのは機能名の多さではなく、周波数情報、優先順位、帯域制御を一つのフレーム時間改善へつなげられるかどうかである。
