SteamOS 3.8.28正式版公開｜AMD GPUのスリープ復帰後FPS低下を修正、実測60→12fps【2026年9月】
本記事にはアフィリエイト広告（Amazon・楽天市場等）のリンクが含まれています。
AMD GPUのスリープ復帰後FPS低下を修正
出典：Valve公式Steamニュース「SteamOS 3.8.28」Stable版／Beta版、ValveSoftware/SteamOSIssue Tracker #2811、GamingOnLinux「SteamOS 3.8.28 stable released」、VideoCardz「SteamOS 3.8.28 fixes AMD discrete GPUs performance drops after sleep」にもとづきます。
Steam MachineやAMDのディスクリートGPUを組み合わせた自作SteamOS PCで、スリープから復帰した直後だけゲームが極端に重くなる、という症状に困っていないでしょうか。Valveは2026年9月24日、SteamOS 3.8.28をStableチャンネル向けに正式公開し、この症状に関わる修正を含めました。
今回の修正は、9月22日に先行公開されたSteamOS 3.8.28 Betaの内容がわずか2日でStableへ昇格したものです。Valve自身は原因の詳細を公開していませんが、修正が入る直前にValveのSteamOS Issue Trackerへ投稿された実測報告を確認すると、あるゲームでスリープ前は60fps前後だったフレームレートが、復帰後には約12fpsまで落ち込んでいたことが分かります。
SteamOS 3.8.28で何が変わったのかに加えて、スリープ復帰後の性能低下が実際どのような症状だったのか、GPUメモリ(VRAM)とシステムメモリ(GTT)の挙動、Steam MachineとSteam Deckそれぞれへの影響範囲、症状が出た場合の切り分け手順まで、公式パッチノートと実測報告の一次情報にもとづいて整理します。
目次
修正Valveが公式に修正したのは「AMD dGPUのスリープ復帰後の性能低下」
Valveの公式パッチノートで今回のSteamOS 3.8.28に関する記述は、次の一文に尽きます。
「AMDのディスクリートGPUを搭載したシステムで、スリープ／レジューム後にゲーム性能が低下する場合がある問題を修正した」
どのRadeon世代が対象なのか、どのゲームで発生するのか、何パーセントほど性能が低下するのか、ドライバーのどの処理に問題があったのかといった詳細は公開されていません。この修正は9月22日のSteamOS 3.8.28 Betaで先行して公開されていましたが、わずか2日後にStableへ昇格しています。現在はBetaチャンネルへ切り替えなくても、通常のStable更新を適用するだけで反映されます。
実測RX 9070 XTでは60fps台から約12fpsまで低下した報告
Valveは原因を公開していませんが、修正が入る直前の2026年9月13日、ValveSoftwareのSteamOS Issue TrackerへIssue #2811として、非常によく似た症状の詳しい実測報告が投稿されていました。
報告者の環境はRyzen 7 7800X3D、XFX Radeon RX 9070 XT、ASRock B850I Lightning WiFiを組み合わせたデスクトップPCです。SteamOS 3.9.0だけでなく、当時のStable版だった3.8.26でも再現したとされています。確認されたゲームは『鬼武者 Way of the Sword』『ウィッチャー3』『Counter-Strike 2』の3本です。
SteamOS 3.9.0でのテストでは、『鬼武者 Way of the Sword』がスリープ前には60fps前後で動いていたのに対し、復帰後は約12fpsまで低下しました。数フレームのブレではなく、約80%のフレームレートを失う規模の低下です。
| 指標 | スリープ前 | 復帰直後 |
|---|---|---|
| VRAM常駐量(drm-resident-vram) | 約7.4GiB | 約190MiB |
| GTT常駐量(drm-resident-gtt) | ほぼ0 | 約7.9GiB |
| GPU全体のVRAM使用量 | 約8.6GiB | 約1.0GiB |
| GPU消費電力 | 約230〜266W | 約140〜170W |
※ValveSoftware/SteamOS Issue #2811、『鬼武者 Way of the Sword』実行時の報告値にもとづきます。
GTTとは、GPUがアクセスできるシステムメモリ側の領域です。ディスクリートGPUが搭載する高速な専用VRAMへデータを置くのとは異なり、システムRAM側のデータへアクセスする場合はPCI Expressなどを経由するため、同じデータ量でも読み書きの速度は大きく下がります。ゲームが本来VRAMへ置いていた大量のデータがGTTへ移ったまま戻らなければ、性能へ大きな影響が出ても不思議ではありません。
ただし、ここで注意したいのは、「SteamOS 3.8.28で修正された不具合の原因はVRAMがGTTへ移動していたことだ」とまでは断定できない点です。Valveは3.8.28のパッチノートで原因を説明しておらず、Issue #2811にも今回の修正との公式な関連付けはありません。あくまで、修正の直前に確認されていた、症状が極めて近い実測例として見るのが適切です。
検証Counter-Strike 2ではゲームだけ再起動すると直っていた
同じIssue #2811では、『Counter-Strike 2』でも似た挙動が確認されています。スリープ復帰後はVRAM使用量が約1.8GiB、GTT使用量が約8.5GiBとなり、ゲームが使うメモリの大半がGTT側に移った状態になりました。
ここで報告者は、PCを再起動するのではなくCounter-Strike 2だけを終了して起動し直すという切り分けを行っています。その結果、VRAM使用量は約9.8GiB、GTT使用量は約0.5GiBに戻り、フレームレートも60fpsへ復帰したとされています。
これは症状を切り分けるうえで重要な材料です。「スリープ復帰後にPC全体が恒久的に低速化する」のではなく、スリープ前から動かしたままだったゲームだけが低速化し、復帰後に新しく起動したゲームは正常に動くケースがあったことになります。報告者自身も、復帰後に新規起動したゲームは正常に動作したとしています。
Issue #2811では、フレームレートが大幅に低下した状態でもRX 9070 XTのGPU使用率は100%と表示されていました。一方でGPU消費電力はスリープ前の約230〜266Wから、復帰後は約140〜170Wまで下がっています。SteamOSのパフォーマンスオーバーレイでGPU使用率が100%になっていても、それだけでは正常動作の証明にはならないということです。メモリ配置やGPU内部の処理状態がおかしくなっているケースでは、使用率という1つの数字だけを見ると原因を見誤る可能性があります。
差異SteamOSのバージョンによって症状の内実が違っていた
Issue #2811では、当時のStable版だったSteamOS 3.8.26でもテストが行われています。興味深いことに、SteamOS 3.9.0とまったく同じ症状ではありませんでした。3.8.26ではスリープ復帰後にVRAMへデータは戻ったものの、カメラを動かした際などに強いカクつきが発生したとされています。ゲームのgfx engine timeはスリープ前のおよそ2.8倍に増加し、GPU使用率が100%でも消費電力は約120Wまで下がっていました。加えて、amdgpu関連の割り込みが1秒あたり8万5千件規模に増え、関連するworkqueue(sdma1・gfx_0.0.0・comp_1.1.0)も高負荷になっていたと報告されています。
同じ「スリープ復帰後に性能が落ちる」という結果でも、SteamOSのバージョンによって内部で起きていた現象は違っていた可能性があります。この点からも、単純に「GPUクロックが戻らなかっただけ」と一言で説明するのは危険です。
断定原因をGPUの省電力状態と決めつけるのはまだ早い
スリープ復帰後にだけ性能が下がると聞くと、GPUの電力ステートやPCI Expressの省電力機能を疑いたくなります。しかし、現時点でValveは原因を明らかにしていません。
Issue #2811では、SteamOS 3.9.0・3.8.26いずれの環境でも、スリープに入る際のログにamdgpu 0000:03:00.0: MODE1 resetという記録が残っていたことも報告されています。さらに報告者は、自身が設定していたGPUのアンダーボルトやパワーリミットを無効化し、Steamのバックグラウンド録画を停止し、iGPU(統合GPU)を無効化するなど個別に切り分けを行っていますが、それでも症状は再現したとしています。少なくともこの環境では、単なるユーザー側のGPUチューニング設定が原因だったとは考えにくい結果です。
SteamOS 3.8.28でOS側の修正が入ったことからも、症状に該当する場合はUEFIのASPMやGPU電力設定を手当たり次第変更するより、まずSteamOSをStable 3.8.28へ更新する方が先です。
別件VRAM管理そのものの改善はスリープ問題と別項目
SteamOS 3.8.28では、スリープ復帰の問題とは別に、VRAM管理そのものにも大きな変更が入っています。Valveの公式パッチノートには「VRAMが限られる状況での性能と安定性を大幅に改善するため、VRAM管理を大幅に改善した」と記載されています。
ここは混同しやすい部分です。「スリープ復帰後にVRAMからGTTへデータが移動する報告がある」ことと、「SteamOS 3.8.28でVRAM管理が大幅改善された」ことを並べると、同じ修正だと考えたくなります。しかし、Valveの変更履歴ではVRAM管理の改善と「AMD dGPUでスリープ／レジューム後に性能が低下する問題の修正」は別々の項目として記載されています。したがって、VRAM管理の改善そのものがスリープ問題の原因を解決した、と断定することはできません。
一方で、ValveがSteamOSでVRAM管理をかなり重視していることは確かです。専用VRAM容量が決まっているSteam Machineのような機器では、バックグラウンドプロセスよりゲームへVRAMを優先的に割り当て、必要なデータをローカルVRAMへ残せるかどうかが性能の安定性に直結します。
更新Mesaドライバーもメジャー更新、カーネルは6.18.50へ
SteamOS 3.8.28では、Mesaグラフィックスドライバーも新しいメジャーリリースへ更新されました。Valveは多数のレイトレーシング性能改善に加え、その他の性能・機能改善も含まれるとしています。Linuxカーネルは6.18.50へ更新されています。
SteamOSでAMD GPUを使用する場合、Windowsの単一のドライバーパッケージとは異なり、Linuxカーネル側のAMDGPUとMesa側のRADVなど複数のレイヤーがグラフィックス環境を構成しています。そのためSteamOSの更新は、単なるOSのUI変更ではなくGPU性能やゲームの互換性そのものへ影響する場合があります。
ファームウェアSteam Machine Firmware 108は8月のBetaで導入済みの内容
SteamOS 3.8.28のパッチノートには、Steam Machine Firmware 108によるスリープ関連の修正も記載されています。これを見て「Steam MachineのCPU側のスリープ復帰問題も今回直った」と受け取ると、少し不正確です。
Firmware 108自体は、2026年8月8日公開のSteamOS 3.8.25 Betaで先行導入されていた内容で、当時の記事でも「スリープ直後に勝手に復帰する不具合」「スリープ復帰後にCPU性能が低下し、再起動するまで戻らない不具合」という同じ2点の修正として紹介しています。SteamOSのStable版パッチノートは前回のStable(3.8.16)以降にBetaへ積み上げられた変更をまとめて収録する形式のため、今回の3.8.28パッチノートにもFirmware 108の説明がそのまま再掲されています。今回のStable版で新しく直った項目ではなく、8月のBetaからStableへ正式に降りてきた既存の修正と理解しておくのが正確です。
対象Steam Deckは今回のAMD dGPU修正の直接対象ではない
今回の修正について、Steam Deckユーザーが過度に心配する必要はなさそうです。Valveは対象を明確に「AMDのディスクリートGPUを搭載したシステム」としています。Steam Deckは内蔵GPU(統合GPU)のみを搭載する機器であり、Valve自身もSteam Deckそのもので今回の性能低下問題が発生していたとは説明していません。
したがって、「Steam DeckをスリープするとFPSが下がる不具合をSteamOS 3.8.28で直した」という理解は正確ではありません。今回のAMD dGPU修正は、AMDのRadeonディスクリートGPUを搭載したSteam MachineやSteamOS導入済み自作PCの方が直接関係します。もちろんSteamOS 3.8.28 Stableには、Steam Deck向けの他の修正やMesa更新も含まれているため、Steam Deckでも更新する意味はあります。
予告Preview版ではRDNA1・RDNA2世代の別の修正も進行中
2026年9月14日に公開されたSteamOS 3.9.1 Previewでは、RDNA1(Radeon RX 5000シリーズ相当)またはRDNA2(Radeon RX 6000シリーズ相当)世代のディスクリートGPUを搭載したシステムで発生するsuspend/resume問題が別途修正されています。こちらはSteamOS 3.8.28の「復帰後にゲーム性能が低下する問題」とは別項目として案内されており、同じ不具合とは明記されていません。
Issue #2811で大きな性能低下が報告されたRX 9070 XTはRDNA4世代です。つまり、SteamOSでAMDのディスクリートGPUを使う環境では、単一の世代だけでなく複数世代についてスリープ・レジューム関連の修正が並行して進められていることになります。SteamOSを自作PCへ導入するユーザーが増えるにつれて、Steam Deck専用だった頃には表面化しにくかったGPUやマザーボードの組み合わせ問題も増えていると考えられます。
診断スリープ復帰後にFPSが落ちたときの確認手順
FAQよくある質問
まとめまとめ｜性能を底上げするより「スリープ後も性能を維持する」更新
SteamOS 3.8.28は2026年9月24日にStableとして正式公開され、AMDのディスクリートGPUを搭載したシステムでスリープ復帰後にゲーム性能が低下する場合がある問題を修正しました。Valveは原因を公開していませんが、修正直前にValveのSteamOS Issue Trackerへ投稿されたRX 9070 XT環境の報告では、あるゲームがスリープ前の60fps前後から復帰後に約12fpsまで低下し、VRAMに置かれていたデータの大半がGTT側へ移動したまま戻らない状態が確認されています。ゲームを起動し直すと正常な配置と性能に復帰しており、原因の特定には有力な手がかりです。
同時にVRAM管理の大幅改善やMesaドライバーのメジャー更新も収録されていますが、これらはスリープ復帰の修正とは別項目であり、混同しないよう注意が必要です。またパッチノートに載っているSteam Machine Firmware 108のスリープ関連修正は、8月のBetaで既に導入済みの内容がまとめて再掲されたものです。AMD Radeonを搭載したSteamOSデスクトップPCやSteam Machineでスリープを頻繁に使用するなら、3.8.28は優先度の高いStable更新です。Steam Deck単体では今回のAMD dGPU修正の直接対象にはなりませんが、他の修正やMesa更新の分だけ更新する意味があります。
あわせて読みたい
