Linux 7.3でGPUスケジューラ「Fair」再採用へ？RX 9070 XTの10FPS低下・フリーズ問題を2パッチで修正
本記事にはアフィリエイト広告（Amazon・楽天市場等）のリンクが含まれています。
RX 9070 XTの10FPS低下・フリーズ問題を2パッチで修正
出典：Phoronix、Igalia公式ブログ。内容は2026年8月15日時点で確認したものです。
ゲームだけがGPUを使っているように見えても、実際にはデスクトップのコンポジターやブラウザの動画再生、バックグラウンドアプリなど、複数の処理が同時にGPUへ仕事を送っています。この「誰の仕事を先に処理するか」を決めるのがLinuxカーネルのGPUスケジューラです。
Linux 7.2では、このスケジューラの標準方式を新しい「Fair」へ切り替える計画が進んでいましたが、リリース直前にRadeon RX 9070 XTで重大な性能回帰が発覚し、従来の「FIFO」へ撤回されました。そして2026年8月14日、この問題を修正する小さなパッチが投稿されています。
この記事では、FIFOとFairの違い、RX 9070 XTで何が起きたのか、Steam Deckを含む幅広いLinuxゲーミング環境への影響、そしてLinux 7.3で再びFairが採用される見込みまで整理します。
目次
要点Fair標準化は一度撤回、2026年8月14日に修正パッチが投稿
Radeon RX 9070 XTでGPU使用率が継続的に100％近くなると、Proton経由のゲームが約10FPSまで低下したり、KDE PlasmaのWaylandセッション全体がロックアップしたりする問題が報告されました。開発元のIgaliaは20パッチからなるrevertでFIFOへ戻し、Linux 7.2を安定させています。その後2026年8月14日、問題を修正するとみられる2パッチ（変更量100行未満）が投稿され、報告者のテストでは解消したとみられています。次の候補はLinux 7.3ですが、2026年8月15日時点で採用は確定していません。
背景DRM GPU Schedulerとは何か
今回の話題の中心にあるDRM GPU Schedulerは、Linuxカーネル内でGPUへ送る処理を管理する共通コンポーネントです。ユーザー空間から送られてきたGPUジョブをソフトウェアキューへ入れ、ハードウェア側の実行キューへ送る仕組みで、依存関係の処理やタイムアウト検出も担当します。特定のGPUメーカー専用の仕組みではなく、DRMドライバーが共通で利用できる基盤部分です。
忙しいグラフィカルデスクトップでは、数十ものスケジューリング対象が存在し、それぞれが毎秒何十回もGPUジョブを送信することがあります。ゲーム本体だけでなく、デスクトップコンポジター、ブラウザの動画再生、オーバーレイ、バックグラウンドアプリなども同時にGPUへ仕事を送っており、GPUに空きができたときに「次にどの仕事を実行するか」を決めるのがGPUスケジューラの役割です。
FIFO「先に来たジョブ」を優先する従来方式の弱点
従来のDRM GPU Schedulerで標準だったのがFIFO（First In, First Out）です。基本的には、ジョブが送信された時刻を基準に次に実行するスケジューリング対象を選ぶ方式で、単純な負荷では問題になりにくい一方、複数のGPUクライアントが同時に動く場合には弱点があります。
たとえば重いゲームが大量のGPUジョブを送り続けている一方で、デスクトップコンポジターが画面を1フレーム更新するための短い処理を送りたい場合、FIFOでは先に大量の仕事を積んでいるクライアントの影響を受け、短くインタラクティブな処理が適切なタイミングでGPU時間を確保できないことがあります。ジョブ投入のタイミングが選択基準になるため、CPU側のスケジューリングと意図せず結びついてしまう問題もあります。さらに優先度の高い処理が継続すると、低優先度の処理へまったくGPU時間が回ってこない「priority starvation」も課題でした。
FairCPUのCFSに着想を得た新方式
そこで開発されたのがFair DRM Schedulerです。ジョブが届いた順番ではなく、各処理がこれまでどの程度GPU時間を使用したかを基準に次の処理を決めます。設計はLinuxのCPUスケジューラで使われてきたCompletely Fair Scheduler（CFS）の考え方から着想を得ています。
Fairでは「virtual GPU time」という値を使います。実際のGPU使用時間を優先度に基づく係数でスケーリングした値で、これによりスケジューリングの判断をジョブの投入時刻から切り離せます。GPU時間をあまり使用していないスケジューリング対象ほど次に実行されやすくなり、特定のアプリだけがGPUを独占し続ける状況を抑えられます。優先度も計算に反映されるため、低優先度の処理はGPU時間を少なく割り当てられるものの、完全に処理されなくなることは避けられる設計です。ここでいう「Fair」は、複数のゲームのFPSを完全に同じにする機能ではなく、ゲーム・デスクトップ・動画・バックグラウンド処理などが競合したときに、一方が極端にGPU時間を独占しにくくすることが目的です。
検証Steam Deck OLEDでの実機テストで改善を確認
Fair Schedulerの開発では、Steam Deck OLEDも実機テストに使われています。Igaliaは、Unigine Heaven（ゲーム想定）と2つのVulkanデモ（重いGPU処理想定）を同時に動かすテストを実施しました。FIFOでは、通常優先度の2つのクライアント間でもGPU時間の割り当てが不均等になり、低優先度で動かしたクライアントにはGPU時間がほとんど与えられませんでした。Fairへ切り替えると、通常優先度クライアント間のGPU時間配分がより均等になり、低優先度の処理にも小さいながらGPU時間が割り当てられる結果が確認されています。ただし、これは「Fairにすると平均FPSが上がる」という意味ではありません。狙いは平均フレームレートの向上ではなく、複数のGPU処理が同時に存在するときの公平性・応答性の改善です。
問題発覚RX 9070 XTで約10FPSまで低下、Waylandセッションもロックアップ
Linux 7.2ではFairをDRM Schedulerの標準方式へ切り替える計画が進み、正式リリース直前まで来ていました。ところがRadeon RX 9070 XTを使用する環境から、深刻な性能回帰が報告されます。GPU負荷が継続して100％近くになると症状が発生し、Proton経由で『Project Silverfish』というゲームを実行した例では、フレームレートが約10FPSまで低下するか、完全にフリーズしました。
問題はゲームだけに留まりませんでした。KDE PlasmaのWaylandセッション全体がロックアップし、コンポジターの終了や再起動が必要になるケースも報告されています。興味深いのは、GPU負荷を下げると症状がすぐに収まったことです。ゲーム内メニューを開くなどしてGPU使用率を下げると、発生していたスタッターが即座に止まったとされており、通常の「ドライバーが遅い」という問題ではなく、GPUを飽和させた状態とFair Schedulerの組み合わせで表面化するスケジューリング回帰でした。
対応20パッチでFIFOへ撤回、8月14日に修正パッチが投稿
カーネルの変更によって既存環境の性能や安定性が大幅に悪化する場合、Linuxの開発プロセスではregressionとして扱われ、通常はそのまま出荷しません。Linux 7.2の正式リリースが迫っていたことから、開発を主導するIgaliaのTvrtko Ursulin氏は、Fairをデフォルトにする変更を一度撤回することを選びました。関連変更を含め合計20パッチからなるrevertが準備され、Linux 7.2ではFIFOを標準へ戻す対応が進められています。Fairという仕組み自体を廃止する判断ではなく、まず安定した状態でLinux 7.2をリリースし、その後に問題を調査するという方針です。
そして撤回から数日後の2026年8月14日、Ursulin氏から問題を修正するとみられる新しいパッチが投稿されました。2つのパッチで構成され、変更量は合計100行未満です。RX 9070 XTで問題を報告したユーザーによるテストも行われ、現在は回帰が解消されたとみられています。Ursulin氏は、この修正を踏まえて将来のカーネルでFairを再び標準へ昇格させる作業を進められることに期待を示しており、最終的にはFIFOやRound Robinを削除し、Fairを中心としたより単純なDRM Schedulerへ整理する構想もあるとしています。
現状整理Linux 7.3での採用は確定していない
- RX 9070 XTの回帰は2パッチ・100行未満の修正で解消したとみられる
- Linux 7.2は正式版でFIFOへ戻された状態でリリースされる見込み
- 開発者はLinux 7.3以降でのFair再採用に前向きな姿勢を示している
- Linux 7.3のマージウィンドウに再採用の変更が間に合うかどうか
- レビューや追加テストで新しい問題が見つからないか
- RX 9070 XT以外のAMD GPU・幅広い環境で問題なく動作するか
2026年8月15日時点でLinux Kernel Archivesに掲載されている最新メインラインはLinux 7.2-rc7で、正式版Linux 7.2自体もまだ公開されていません。通常はLinux 7.2正式版のリリース後にLinux 7.3のマージウィンドウが始まります。開発者の発言も「upcoming kernel release」という表現にとどまっており、Linux 7.3への採用を保証するものではありません。「Linux 7.3でFairが標準になる」ではなく、「RX 9070 XTの回帰を修正するパッチが出たことで、Linux 7.3でFairを再採用できる可能性が戻ってきた」と捉えるのが正確です。
補足FairはRX 9070 XT専用の機能ではない
「RX 9070 XTのFair Scheduler問題」というニュースだけを見ると、AMD Radeon専用の話に見えるかもしれません。しかしDRM GPU Schedulerは特定のGPU専用に設計された仕組みではなく、GPUドライバーが共通で利用できるコンポーネントです。Fair Schedulerの開発目的も、特定GPUのFPSを上げることではなく、複数のGPUクライアントが同時に動作する環境でGPU時間をより公平に分配することにあります。今回たまたま深刻な問題を発見した環境がRX 9070 XTだったという位置づけで、修正の意味はRX 9070 XTだけに限定されません。DRM Schedulerを利用するLinux GPUドライバー全体で、Fairを安全に標準化できるかどうかに関わる問題です。
FAQよくある質問
まとめまとめ｜RX 9070 XT高速化ではなく、公平なGPU時間配分への再挑戦
Linux 7.2で標準化される予定だった新しいDRM GPU Scheduler「Fair」は、Radeon RX 9070 XTで重大な性能回帰（約10FPSへの低下・フリーズ）が見つかり、正式リリース直前にFIFOへ撤回されました。しかし2026年8月14日、問題を修正するとみられる2パッチ（100行未満）が投稿され、開発者は将来のカーネルでFairを再び標準化する方向を示しています。
今回のポイントは「RX 9070 XTを高速化するパッチ」ではなく、ゲームとデスクトップなど複数のGPU処理をより公平に動かすFair Schedulerが、重大な回帰を乗り越えて標準化へ再挑戦できる状態に戻ったことです。次の候補はLinux 7.3ですが、2026年8月15日時点で採用は確定していません。Steam Deckを含む幅広いAMD GPU環境で問題なく動作するかどうかが、今後の注目点になります。
あわせて読みたい
※価格は2026年8月時点の目安・変動あり
※価格は2026年8月時点の目安・変動あり
