Linux

Valve開発者、LinuxのVRAM管理を根本から修正

情報の灯台

2026年4月10日

ゲームの裏でブラウザが居座り、主役であるはずのゲームがメモリ競争に負けていく。Linuxゲーマーが長年飲み込んできたこの不条理に、Valveの開発者が終止符を打った。

ゲームより先にブラウザが生き残る、という不条理

Linuxでゲームを遊んでいると、プレイ時間が延びるにつれて動作が重くなっていく現象がある。裏で開いたままのブラウザや、Electron製のチャットアプリは何の問題もなく動いている。画面の主役であるはずのゲームが、脇役たちに少しずつ押しのけられていく。

この長年の不条理に終止符を打ったのが、Valveのグラフィックスドライバチームに所属し、RADV Vulkan ドライバを手がけるナタリー・ヴォックだ。彼女は4月9日付の自身のブログで、AMD GPU カーネルドライバのVRAM管理を根本から作り直したと発表した。対象は128GBのVRAMを積んだデータセンター級GPUではない。8GB、あるいはそれ以下のVRAMしか持たない、ごく普通のゲーマーのマシンである。

世界中で語られている。8GB、あるいはそれ以下のVRAMでゲームを遊ぼうとするLinuxゲーマーたちの伝説が。VRAMが枯渇し始めたとき、カーネルドライバの中では文字通りの乱戦が起きている。

Vockはブログの冒頭でそう書いた。誇張ではない。カーネルの内部ではアプリケーションたちがGPU メモリを奪い合っていて、ゲームはその戦いで最も深刻な打撃を受けていた。

「VRAMに入らなかったメモリ」の静かな敗北

問題の核心は、カーネルがVRAMを使い切った瞬間にある。彼女がCyberpunk 2077を多数のアプリと並行して起動したテストでは、ゲームが要求したメモリのかなりの部分が「GTT」と呼ばれる領域、つまりPCIバス経由でアクセスされるシステムRAMに流し込まれていた。

この差は残酷だ。彼女のシステムでVRAMが提供する帯域は毎秒256GB。対するGTTは、PCIバスの限界で毎秒16GBが関の山。しかもレイテンシはずっと悪い。ゲームがVRAMに置きたいと頼んだメモリが、16分の1の速度しか出ない場所に追いやられる。フレームレートが落ちない方が不思議だ。

VRAMとGTTの帯域差

VRAM GPU直結メモリ

256 GB/s

GTT PCIe経由のシステムRAM

16 GB/s

Natalie Vockのシステムでの帯域値。VRAMからGTTへメモリが追いやられると、帯域は約16分の1まで落ち、レイテンシはさらに悪化する。GTT使用時の16GB/sはPCIeバスの事実上の上限値。

カーネルの立場で見ると、これは筋の通った判断ではある。VRAMが足りない状況でどれかのアプリに「メモリが取れませんでした」と返せば、ほぼ確実にクラッシュする。クラッシュさせるくらいなら、新しい要求をGTTに逃がす方がマシだ。そういうロジックで長年動いてきた。

問題は、カーネルドライバから見るとすべてのメモリが同じに見えることだ。ゲームの極めて重要なデータなのか、バックグラウンドで走っているWebアプリの静止画なのか、カーネルには判別できない。目に映るのは、ただのバッファの一覧でしかない。

Vockはブログでそう解説する。つまりカーネルは、悪意があってゲームを冷遇していたわけではない。判断材料を持っていなかっただけだ。情報がなければ、公平に扱うしかない。そして公平さは、この文脈では敗北を意味する。

dmem cgroupという、しごく真っ当な解決策

答えはLinuxの別の場所にあった。cgroup、プロセスをグループに束ねてCPU時間やメモリ使用量の上限を個別に設定できる、古典的な仕組みだ。systemdはすでにデスクトップ上の各アプリを個別のcgroupとして管理している。つまり、ゲームと背景アプリを区別する「住所」は最初から存在していた。

あとは、GPU メモリに対応するcgroupコントローラを書けばいい。Intelのマールテン・ランクホルストが先行して着手していたこの仕組みに、レッドハットのマキシム・リパールとVock自身が加わり、dmem cgroupコントローラが完成した。カーネルはこれにより、「このメモリは守るべきもの、あのメモリは追い出してよいもの」を初めて区別できるようになる。

cgroupには「保護上限」を設定でき、その範囲内にあるメモリは追い出しから守られる。上限を超えた分は、通常通り追い出しの対象になる。フォアグラウンドのゲームには大きな保護枠を、裏で走るチャットアプリには小さな保護枠を。カーネルが長年持てなかった「優先度」という概念が、ようやく手に入ったことになる。

ただし、dmem cgroup自体は以前からカーネルに取り込まれていた。ゲーム用途で本当に機能させるには、Vockが新たに書いた一連のカーネルパッチが必要だった。VRAMが枯渇した瞬間にGTTへ直接割り当てる挙動は、通常のメモリ追い出しとは別の経路で動いており、保護の仕組みがそこまで届いていなかったからだ。彼女のパッチは、その穴を塞いでいる。

Cyberpunk 2077で出た答え

仕組みが整ったところで、Vockは最初と同じテストを繰り返した。大量のアプリを立ち上げ、その上にCyberpunk 2077を起動する。結果は明快だった。

GTTのメモリ使用量は650MBまで落ちた。つまり、ゲームが自分で明示的にシステムRAMに置こうとしたメモリだけだ。VRAMからこぼれ落ちたメモリは、一つもない。

修正前のテストでは、Cyberpunk 2077のGTT使用量は1.6GB近くに膨らんでいた。その差、約1GB。ゲームが本来VRAMで動かしたかったメモリが、まるごとVRAMに戻ったことを意味する。

Cyberpunk 2077のGTT使用量修正前後

修正前従来のAMDGPUドライバ

1.6 GB

修正後 dmem cgroup + Vockのパッチ

650 MB

大量のアプリを起動した状態でCyberpunk 2077を実行したときの、ゲームのGTT（システムRAM）使用量。約1GB分のメモリが、本来の居場所であるVRAMに戻ったことを意味する。修正後の650MBは、ゲームが自ら明示的にシステムRAMに置いた分のみ。

Vock自身は、フレームレートの具体的な数字を出していない。VRAM不足による性能低下はプレイ時間とともに徐々に進行するため、単発のベンチマークでは捉えにくいと彼女は書いている。代わりに描かれているのは、「ゲームの動作が時間とともに重くなっていく」という日常的な苦痛が、単に消える、という約束だ。数字より実感に寄せた結論で、個人的にはこちらの方が説得力を感じる。

使うには何が必要か

現時点で最も手早く試せるのは、CachyOSを使うことだ。CachyOSの7.0rc7-2カーネルにはVockのパッチが取り込まれており、ユーザースペースの補助ツールであるdmemcg-boosterとplasma-foreground-boosterもリポジトリから入手できる。デスクトップはKDE Plasmaが前提となる。

他のArch系ディストリビューションでも、AURから同等のパッケージを導入できる。非Arch系や、自分でパッチを当てたい勇者のためには、Vockが6本のパッチファイルを公開している。KDEを使わない環境については、新しめのgamescopeが同等の機能を利用するようになっているため、gamescope経由でゲームを起動すれば恩恵を受けられる。ただしdmemcg-boosterだけは必要だ。

なお、ユーザースペースのツールは現状すべてsystemdに強く依存している。systemdを使わない構成では、自前で同等の仕組みを書く必要がある。この点は割り切りだろう。

本来であれば、これらはsystemdのdrop-inユニット設定として書けるのが理想だ。dmemcg-boosterは、そうなるまでの橋渡しに過ぎない。

Vock自身、この構成が暫定的なものだと認めている。dmem cgroupにはゲーム以外の用途も控えており、systemdの正式な対応はそれらが出そろってから議論すべき、という判断だ。技術的に正しい判断であって、それまでの間、ユーザーは小さなブースターに世話になる。

「8GBで足りる」という言葉の重さ

Vockはブログの結びで、興味深いことを書いている。現代のゲームでも、おおむね8GBの予算内には収まる傾向があり、8GBのGPUを持っているなら今のゲームには十分やっていけるはずだ、と。

これは、近年のGPU市場で繰り返されてきた「8GBはもう足りない」という評価への、技術側からのささやかな反論にも読める。ハードウェアの容量ではなく、ソフトウェアのメモリ管理が足りていなかっただけではないか、という問いだ。もちろん全てのゲームに当てはまる話ではないし、将来のタイトルを保証するものでもない。ただ、カーネルの振る舞い一つでこれだけ挙動が変わるという事実は、スペック表だけを見て語られがちなこの議論にもう一つの材料を加える。

技術の多くは、派手な新機能ではなく、誰も見ていなかった場所の辻褄合わせで前に進む。Linuxゲーミングの地味な一歩は、しかし8GBカードで戦うゲーマーにとっては派手に感じられるはずだ。

参照元