Valveの開発者Pierre-Loup Griffais氏は9月27日、Windows向けx86ゲームをArmデバイスで動かす「Proton Experimental」のArm版で、FEXのコードキャッシュを有効にしたことを明らかにした。
これにより、特に2回目以降の実行で、処理に時間がかかるフレームの改善が期待されるという。Griffais氏は「1% low」のフレーム時間が改善する見込みだとしているが、対象ゲームや具体的な改善幅は示していない。
Steam Frameでx86のWindowsゲームを動かす仕組み自体はすでに公開されていた。今回の変更は、その際に必要となるx86からArm64へのCPU命令変換を繰り返す負荷を減らし、カクつきを抑えるための具体的な改良となる。
ProtonのArm版で何が変わったのか
Griffais氏が明らかにした変更は、FEXのコードキャッシュをProton ExperimentalのArm版で有効にしたというものだ。
特に一度キャッシュが作られた後の再実行では、フレーム時間の悪化が大きい場面、いわゆる「1% low」に相当する部分が改善する可能性があるという。
ただし、これは現時点では開発者による見通しであり、ベンチマーク結果の発表ではない。投稿には変更前後の数値も、測定に使ったゲームや端末も掲載されていない。
平均フレームレートだけでは、こうした違いは分かりにくい。
例えばゲームの大部分が滑らかに動いていても、場面を切り替えた瞬間などに一部のフレームだけ表示まで長くかかれば、プレーヤーには一瞬の引っかかりやカクつきとして感じられる。
「1% low」は、平均値では隠れやすいこうした遅いフレームに注目するための指標だ。
FEXのコードキャッシュが減らそうとしているのは、その原因の一つになり得るCPU命令の再変換である。
ただし、Griffais氏の投稿では「1% low」をどの方法で集計するのか、どの条件で測定したのかは示されていない。そのため、実際にどの程度改善するのかは現時点では判断できない。
また、Arm対応そのものが今回初めて加わったわけでもない。
ValveはProton 11.0-1で、ARM64EC向けビルドにFEX-2605を追加している。つまり、ProtonとFEXを組み合わせてWindows x86ゲームをArm64上で動かす仕組みが先に用意され、今回はProton ExperimentalのArm版でコードキャッシュも有効になったという順番だ。
この変更がProtonの安定版を使うすべての利用者へ配信された、あるいはx86-64プロセッサを搭載するSteam Deckにも同じ効果がある、と受け取ることはできない。
一度変換したコードを再利用する
FEXは、x86向けに作られたCPU命令をArm64プロセッサで実行できる命令へ動的に変換する。
この変換自体にもCPU処理が必要になる。
ゲームが後から同じコードを再び実行するとき、以前生成したArm64向けコードを保存しておき、そのまま再利用できれば、同じ変換処理をもう一度行わずに済む。
Griffais氏が特に再実行時の改善を挙げたのは、この仕組みと一致する。
FEX開発チームが9月に公開した「FEX-2609」では、このディスクキャッシュの仕組みが詳しく説明されている。
機能を有効にすると、JIT（実行時コンパイル）によって生成されたコードを、FOZ形式のデータベースとしてディスクへ保存する。
FEXが後から同じコードを必要とした場合、再びJITで変換する前に、このデータベースに利用できるコードが残っていないかを確認する。
キャッシュを利用するのは2回目以降の起動だけではない。
最初の起動中でも、すでに実行・変換したコードを後からもう一度使う場合には、保存済みの結果を利用できる可能性がある。
ただし、FEX-2609のリリース説明と、Proton Experimentalに実際に組み込まれた設定の詳細は別の資料だ。
FEX開発チームは単体でコードキャッシュを有効にする方法として環境変数などを公開しているが、Griffais氏の投稿では、Proton側でどの設定を使っているのか、どのFEXバージョンを組み込んでいるのかまでは説明していない。
したがって、FEX-2609の資料は仕組みを理解する参考にはなるものの、Proton Experimentalでもまったく同じ保存形式や設定で運用されているとまでは断定できない。
また、初めて実行するコードは当然ながらキャッシュには存在しない。
どの程度のコードを繰り返し実行するゲームなのか、ゲーム自身が実行中に新しいコードを生成するのか、アップデートによって実行ファイルが変わったのかなどによって、キャッシュの効果は変わる。
さらに、このコードキャッシュが対象とするのはCPU側のx86→Arm64命令変換だ。
GPUが利用するシェーダーのコンパイルとは別の処理であり、ゲーム中に発生するあらゆるカクつきを解消する仕組みではない。
Steam FrameではProtonとFEXが役割を分担する
今回の変更がSteam Frameと関係する理由は、Valve自身が公開している互換性の仕組みにある。
Steam FrameはArm64アーキテクチャのSnapdragon 8 Gen 3を搭載する。
既存のWindows向けx86ゲームをSteam Frame単体で動かす場合、ProtonとFEXが異なる役割を担当する。
Protonは、Windows向けに作られたゲームをLinuxベースのSteamOSで動かすため、Windows APIやDirectXなどとLinux側の環境を橋渡しする。
一方のFEXは、x86またはx86-64プロセッサ向けにコンパイルされたCPU命令を、Arm64プロセッサで実行できる命令へ変換する。
Valveはさらに、OpenGLやVulkanなどの呼び出しについてはArm側のネイティブライブラリへ渡すことで、エミュレーションによる負荷を減らすと説明している。
つまり、Windows x86ゲームをSteam Frameで動かす際には、大きく二つの互換処理が必要になる。
一つは、Windows向けのソフトウェア環境をLinux上で動かすための互換処理。もう一つは、Arm64 CPUがそのままでは実行できないx86命令を変換する処理だ。
今回有効になったコードキャッシュは、後者で一度変換したコードを再利用するためのものとなる。
Protonが担当するWindows APIの互換処理や、DirectXからVulkanへの変換そのものが不要になるわけではない。
また、Steam FrameがAndroid向けゲームを動かす際に利用する「Lepton」も別の互換レイヤーであり、今回の変更とは直接関係しない。
Valveの開発者向け文書では、多くのゲーム開発者にとって、Steam Frame専用のArm版を新たに開発するのではなく、既存のWindows x86版をProtonとFEX経由で動かすことが有力な選択肢になるとしている。
同じ文書では、FEXのコードキャッシュについても、ゲーム中のカクつきをできるだけ減らすための仕組みとして説明している。
これまではSteam Frameの互換性設計として説明されていた機能が、今回Proton ExperimentalのArm版で実際に有効になったことになる。
ただし、Steam Frameでの実際の効果を評価するには、ゲームごとにフレーム時間の悪化がどの程度減るのかを測定する必要がある。
改善は期待できるが、実測値はまだない
2026年9月29日時点で分かっているのは、Proton ExperimentalのArm版でFEXのコードキャッシュが有効になったことと、Griffais氏が特に再実行時の「1% low」改善を見込んでいることだ。
対象ゲーム、テスト環境、具体的なフレーム時間の変化、キャッシュ容量、キャッシュを削除・無効化する条件などは公開されていない。
したがって、現時点で「カクつきが解消した」と評価することはできない。
効果を確かめるのであれば、同じArm端末、同じゲーム、同じ場面で、キャッシュがない状態での初回実行と、キャッシュが作られた後の再実行を比較する必要がある。
その際には平均FPSだけでなく、表示に時間がかかったフレームの分布やフレーム時間も確認し、コードキャッシュ以外の条件をできるだけそろえる必要がある。
ゲームによっては初めて実行するコードが多く、キャッシュの恩恵を受けにくい可能性がある。一方、CPU命令変換ではなくGPU側の処理やシェーダーコンパイルが主なカクつきの原因になっているゲームもある。
今回の投稿だけでは、どのゲームで効果が大きいのかまでは分からない。
実装そのものも、まだ発展途上にある。
FEX-2609の公開時点で、FEX開発チームはディスクキャッシュにいくつかの課題が残っていると説明していた。
アプリケーション自身がJITでコードを生成する場合にはキャッシュが際限なく増える可能性がある一方、当時は容量の上限や古いキャッシュを自動的に削除する仕組みがなかった。
また、元のファイル内容が変更された場合に、古いキャッシュが適切に無効化されない可能性も挙げられていた。
ただし、これらはFEX-2609単体について公開された注意点だ。Proton Experimentalでも同じ問題がそのまま発生すると確認されたわけではないし、Valve側でどのようにキャッシュを管理しているのかも今回の投稿からは分からない。
「1% low」のフレーム時間が改善すれば、平均FPSがほとんど変わらなくても、一瞬の引っかかりが減り、実際に遊んだときの滑らかさが改善する可能性がある。
ただし、現段階で確認できるのは、コードキャッシュが有効になったことと、その効果に対する開発者の見通しまでだ。
次に注目したいのは、ゲームごとの初回起動と再実行を比較した実測結果と、キャッシュの容量管理やゲーム更新時の扱いについてのValve側の説明だ。これらが明らかになれば、Steam FrameでWindows x86ゲームを動かす際に、今回の変更がどの程度の効果を持つのかをより具体的に評価できるようになる。
