Linus Torvalds氏は現地時間2026年10月18日、Linuxカーネル7.3を正式公開した。ゲーム関連では、限られたビデオメモリ（VRAM）を効率的に使うための保護処理が強化され、旧世代RadeonでGPUがハングした際の復旧処理も改善された。VRAM管理に関する変更は、今年4月に開発者が紹介したパッチがLinux本流に取り込まれたものだ。ただし、カーネルを更新するだけで前面のゲームが自動的に優先されるわけではない。改善を利用するには、GPUドライバーやデスクトップ環境との連携も必要になる。

AD

VRAM管理の改善には、カーネル・ドライバー・ユーザー空間の連携が必要

Linux 7.3で強化されたVRAM保護処理は、ブラウザーなどのアプリが先にメモリを確保している状態でゲームを起動する場合に効果が期待される。開発を手がけたNatalie Vock氏は、AMDGPU向けの解説で、ゲームがVRAMへのデータ配置を要求しても、空き容量が足りず、システムRAM上のGTT領域に割り当てられてしまう問題を指摘していた。GPUがこの領域のデータにアクセスする際にはPCIバスを経由するため、専用VRAMと同等の速度では処理できず、描画性能の低下やフレームレートの不安定化につながる可能性がある。

メモリ不足時にデータを退避させる仕組み自体は、以前から存在していた。しかし、カーネルが管理しているのは個々のバッファであり、ユーザーが操作しているゲームとバックグラウンドで動作するアプリのどちらを優先すべきかまでは判断できない。すべてのアプリに優先的なVRAM確保を認めれば、互いのデータを退避させ合うことになり、メモリ間の転送がかえって増えてしまう。

この問題に対処するために使われるのが、プロセスをグループ化してリソース配分を制御するcgroupのデバイスメモリ管理機能「dmem」だ。グループごとに指定した使用量を保護し、メモリが不足した際には、ほかのグループに属する保護対象外のデータを優先的に退避させる。この仕組み自体はすでにLinux本流に組み込まれており、7.3でcgroupによるGPUメモリ管理が新たに導入されたわけではない。

今回の主な改良点は、VRAMの新規割り当て時にも保護設定が適切に反映されるようになったことだ。Linux 7.3の変更履歴に記載されたTTMのコミットbbc744c062f8では、cgroupのメモリ使用量が保護水準（low/min）を下回っているにもかかわらず割り当てに失敗した場合、保護対象外のバッファを退避させて空きを確保するよう変更された。これにより、ほかのアプリが先にVRAMを使い切った結果、保護されるはずのゲームのデータが最初からGTTへ回されてしまう問題の改善が期待できる。ただし、この仕組みを利用するには、カーネルの保護処理に加えて、対応するGPUドライバーと、優先対象を指定するユーザー空間ツールが必要になる。

役割 担当する処理 利用時の確認事項
カーネル 保護設定に基づいてVRAMの割り当てと退避を制御する Linux 7.3、または同等の修正を取り込んだカーネルを使用しているか
GPUドライバー GPUメモリをdmemの管理機構と連携させる 使用中のドライバーがdmemに対応しているか
ユーザー空間 保護設定を管理し、前面のアプリを優先対象として指定する dmemcg-boosterとデスクトップ環境の連携が整っているか

この構成は、Vock氏が公開したユーザー空間ツールの説明とFAQに基づくものだ。紹介されている方法では、dmemcg-boosterがcgroupの保護設定を管理し、KDE Plasma向けのplasma-foreground-boosterが前面で動作するアプリの情報を伝える。KDE以外の環境では、対応する新しいバージョンのgamescopeを利用する方法も案内されているが、その場合もdmemcg-boosterが必要となる。

つまり、どのアプリを優先するかはデスクトップ側が判断し、その情報に基づくメモリ管理をカーネルが担う仕組みだ。ただし、紹介されているツールはsystemdに依存しているため、異なるシステム構成では同じ手順をそのまま適用できるとは限らない。また、GPUドライバーの対応状況や、ディストリビューションが必要なパッケージを提供しているかによっても、利用できる機能は変わってくる。

旧世代Radeonでは、GPUハングからの復旧処理も改善

旧世代Radeon向けには、GFX6、GFX7、GFX8世代のグラフィックス・計算処理に対し、IPブロック単位のソフトリセットを復旧手段に追加する変更が加えられた。GPU全体をリセットするのではなく、問題が発生した機能ブロックを再初期化することで、ほかの処理への影響を抑えながら復旧できる経路を増やす狙いがある。開発者のTimur Kristóf氏はGFX6向けのコミットで、従来のASICリセットではVRAMの内容が消去され、問題を起こしたアプリだけでなく、デスクトップセッション全体に影響が及ぶ場合があったと説明している。GFX7については、KaveriやKabiniに有効な復旧手段がなく、GPUがハングするとPCを手動で再起動する必要があった。一方、HawaiiやBonaireでは、リセット時にVRAMの内容が失われる問題があった。今回の変更は、こうした状況でもGPU全体をリセットせずに復旧できるようにするものだ。

GFX8の試験対象にはRadeon RX 570、RX 560、RX 550が含まれ、Fiji世代のR9 Nanoでも動作が確認されている。ただし、これらは発生しないイベントを意図的に待機し続けることでGPUをハングさせる、Vulkanのhard_reset_cp_waitテストによる検証だ。あらゆるゲームのクラッシュから確実に復旧できることを保証するものではなく、平均フレームレートの向上を示す性能測定でもない。それでも、旧世代のグラフィックスカードを使い続けるユーザーにとって、GPUの異常によってデスクトップ全体が操作不能になる事態を減らせることには、実用上の意味がある。

AD

Steam ControllerやMSI Clawへの対応、CPUの処理配分も更新

ゲーム関連機器では、2026年モデルのSteam Controllerに対する初期ドライバーが追加された。開発を担当したVicki Pfau氏のコミットによると、既存のSteam Deck向けドライバーと同程度の機能に対応しているという。Linuxカーネル本流で新しいコントローラーへの対応が進んだことになるが、ゲーム側の設定やディストリビューションの対応まで、すべてが整ったことを意味するわけではない。

MSI Clawについては、内蔵ゲームパッドの設定を扱うHIDドライバーが追加された。初期段階では、ゲームパッドのモード切り替え、Mキーの動作設定、リセット機能に対応する。これにより、単にコントローラーからの入力を受け取るだけでなく、機器固有の設定もLinux側から管理できるようになる。

CPUのスケジューラーにも変更が加えられた。cgroupの重みに基づいてCPU時間を配分する仕組みに、新たなconcurモードが導入され、既定のモードに設定された。これは、同時に実行可能なタスクの数とCPU数を考慮して重みを計算するもので、VRAM保護とは異なるリソース配分の改善に当たる。CPUの処理配分はゲームの動作にも影響するが、今回の変更から、すべてのタイトルに共通する性能向上率を導き出すことはできない。

実際に改善を利用できるかはディストリビューションの構成次第

VRAM保護の改良がLinux本流に取り込まれたことで、Linux 7.3を採用するディストリビューションでは、ユーザーが対応するカーネルパッチを個別に適用・管理する必要がなくなる。Vock氏も開発者ブログの追記で、7.3への更新後はユーザー空間ツールを導入すればよいと案内している。ただし、実際に機能を利用できるかどうかは、ディストリビューションが採用するカーネルやGPUドライバー、前面アプリの情報を通知する仕組み、cgroupの保護設定などが適切に組み合わされているかによって決まる。

また、バックグラウンドのアプリとの競合を抑えることと、ゲーム自体が物理VRAM容量を超えるメモリを必要とする場合の最適化は、別の課題だ。Vock氏は8月17日公開の続編で、前者に対応するパッチがLinux 7.3向けに取り込まれたと説明するとともに、後者を改善するための開発状況も紹介している。その時点では、後続の変更を試すためのカスタムカーネルとMesaの開発ブランチが案内されており、そこで紹介された改善のすべてが、標準のLinux 7.3に含まれているわけではない。

さらに、専用VRAMを持たず、システムRAMをGPUと共有する統合GPUについても、同様の効果が得られるかは別途検証が必要だ。今回の更新は物理的なVRAM容量を増やすものではなく、限られたメモリをより適切に配分し、GPUの異常から復旧する手段を改善するものとなる。カーネル、GPUドライバー、ユーザー空間ツールの連携がディストリビューション側で整えば、ユーザーが個別にパッチを適用しなくても、VRAM管理の改善を利用できるようになる。