Bazzite 44は何が変わった？VRAM不足時にゲームを優先する新機能を解説｜FPSは上がらず8GB以下のGPUに効果的
本記事にはアフィリエイト広告（Amazon・楽天市場等）のリンクが含まれています。
VRAM不足時にゲームを優先する新機能「dmem cgroup」を解説
独立系Linuxディストリビューション「Bazzite」が、2026年8月20日から21日にかけてバージョン44のハンドヘルド・リビングPC向けイメージを本格展開しました。目玉のひとつが、VRAMが不足した場面でフォアグラウンドのゲームを優先し、バックグラウンドアプリを先にシステムメモリへ退避させる「dmem cgroup」ベースの新しいメモリ管理です。ただしこの機能はGPUの平均フレームレートを引き上げるものではありません。VRAM不足によるクラッシュやカクつきを抑えるための仕組みです。
出典：Natalie Vock氏のブログ「Fixing AMDGPU’s VRAM management for low-end GPUs」「VRAM Management Part 2: Beyond the Limits of Physical VRAM」、Universal Blue Discourseフォーラム「Bazzite 44 Update」、GamingOnLinux「Bazzite Linux 44 for handhelds finally launches with some massive upgrades」、VideoCardz「Bazzite 44 released with HDMI 2.1 FRL, multi-GPU controls and new VRAM management」にもとづきます。内容は2026年8月22日時点のものです。
8GBや12GBのグラフィックスボードでゲームをプレイしていて、ブラウザやDiscordを開いたままにしていたら急に映像がガクガクになった、あるいはゲームが突然クラッシュして落ちた——こうした経験をしたLinuxゲーマーは少なくないはずです。原因の多くはGPUの性能不足ではなく、限られたVRAM(グラフィックスメモリ)を複数のアプリが奪い合っていることにあります。
独立系のLinuxディストリビューション「Bazzite」は、2026年8月20日から21日にかけてバージョン44のハンドヘルド・リビングPC向けイメージを本格展開しました。今回のアップデートの柱のひとつが、VRAM不足が起きた際にフォアグラウンドで遊んでいるゲームを優先し、バックグラウンドのアプリを先にシステムメモリへ退避させる「dmem cgroup」ベースの新しいメモリ管理です。あわせて、VRAMの物理容量を超える要求があっても即座にクラッシュさせず、性能を落としながら処理を続ける「VRAM overcommit」の仕組みも取り込まれています。
この記事では、単に「新機能が追加された」で終わらせず、この機能が実際に何をしているのか、どのGPU・どんな環境で恩恵が大きいのか、そして「VRAM不足でゲームを優先する」という説明から誤解しやすい「FPSが上がる」「8GBのGPUが16GB相当になる」といった思い込みがなぜ成り立たないのかまで、開発者本人の技術ブログをもとに整理します。
Bazzite 44に搭載された新しいVRAM管理は、GPUの処理性能そのものを引き上げる機能ではありません。VRAMが不足した場面で、ゲームよりも先にバックグラウンドアプリのメモリを退避させることで、クラッシュの発生やフレームタイムの乱れを抑えるための仕組みです。恩恵が大きいのは8GB以下のVRAMを搭載したGPUや、Steam Deckのような携帯型ゲーミングPCで、すでに十分なVRAMを積んだ環境では体感できる変化は小さくなります。またこの機能はAMD製GPU(amdgpu)向けの実装が中心で、NVIDIAのプロプライエタリドライバーには適用されません。
目次
要点まず4つのポイントを確認
詳しい説明に入る前に、この記事で扱う4つのポイントを整理しておきます。
仕組み「dmem cgroup」はフォアグラウンドのゲームを優先してVRAMを守る
今回のVRAM管理の起点になっているのは、Valveの契約エンジニアとしてオープンソースのAMD向けVulkanドライバー「RADV」を手がけるNatalie Vock氏が、2026年4月に自身のブログで公開した対策です。典型的なLinuxデスクトップ環境では、ゲーム以外にもタブを大量に開いたブラウザや、内部でブラウザエンジンを使う各種アプリが常時VRAMを消費しています。そこへゲームを起動すると、カーネル側のドライバーは「どのメモリがゲームにとって重要か」を判断できず、ゲームのメモリまで巻き込んでシステムメモリ側(GTT)へ追い出してしまうことがありました。Vock氏の検証では、Cyberpunk 2077を高設定で起動した際、本来ゲームが意図的にGTTへ確保する約650MBを超えて、ゲームの他のメモリまでGTTへ追い出されてしまう様子が確認されています。
この問題を解決する鍵になったのが「dmem cgroup」というLinuxカーネルの仕組みです。systemdはデスクトップ上の各アプリをそれぞれ個別のcgroup(リソース管理の単位)として扱っており、dmem cgroupコントローラーを使うと、特定のcgroupが使うVRAMを「保護する」よう指定できます。保護されたメモリはカーネルが優先的に退避を避けようとし、保護されていないメモリから先に追い出される仕組みです。このコントローラー自体は、IntelのMaarten Lankhorst氏が原型を書き、Red HatのMaxime Ripard氏とVock氏が加わって共同開発したもので、Linuxカーネルの汎用インフラとしてすでに上流に取り込まれています。
実際にどのアプリを「フォアグラウンド」として優先するかは、ユーザー空間側のソフトウェアが判断します。KDE Plasma環境では、フォーカスされているウィンドウを検知してCPU優先度を上げる既存の「ForegroundBooster」機能をVock氏がフォークし、VRAM優先度にも対応させました。GNOME環境では同等の役割を果たす「uresourced-dmemcg」という別実装が使われ、Bazziteのハンドヘルド機のようにSteamのGamescope(コンポジター)を前面で動かす構成では、新しいバージョンのGamescope自体がこの仕組みに対応しています。systemdはまだdmem cgroupの設定を正式にサポートしていないため、これらの裏側では「dmemcg-booster」という補助サービスが、systemdが作ったcgroup階層へ後からdmemコントローラーを有効化するという、やや強引な橋渡しを行っています。
この対策を適用した状態で同じ検証をやり直すと、GTTの使用量はゲームが意図的に確保する約650MBまで下がり、ゲームのメモリは一切追い出されなくなったとVock氏は報告しています。フォアグラウンド優先のdmem cgroup対応パッチは、Linuxカーネル7.3へ統合される見通しがすでに立っています。
限界突破VRAM overcommitはPCIe帯域という物理的な壁と戦う仕組み
ここまでの対策は、あくまで「他のアプリがゲームのVRAMを横取りする」問題への対処です。では、ゲーム自体が物理的なVRAM容量を超えるメモリを要求してきた場合はどうなるのでしょうか。この問いに答えるのが、Vock氏が2026年8月17日に公開した続編のブログ記事「VRAM overcommit」です。
GPUがVRAMからあふれたデータをシステムRAM側から読み込む場合、その通信はPCI Express経由になります。PCIe 4.0 x16接続の実効帯域はおよそ32GiB/秒で、1ミリ秒あたりに換算すると約32.2MiBです。30fpsを維持するために許される1フレームあたりの時間は33.3ミリ秒なので、この時間内にシステムRAMから読み出せるデータ量は最大でも約1,075.5MiB、およそ1GiB強にとどまります。つまり、1フレームの間に追い出されたメモリから1GiBを超えるデータを読み込む必要が生じた時点で、どれだけソフトウェア側を工夫しても30fpsを維持することは物理的に不可能になります。これはBazziteやドライバーの実装がどれだけ改善されても変わらない、PCIeの帯域そのものが持つ上限です。
加えて、VRAM不足は性能低下だけでなくクラッシュの原因にもなっていました。原因はLinuxカーネルの共有メモリ管理層(TTM)にあったロック処理で、VRAMの奪い合いが激しい状況で発生するデッドロック回避のコードが、本来やり直すべき処理を単純に失敗させて終了してしまう作りになっていたのです。Vock氏は、この処理をより堅牢な排他制御の仕組み(drm_exec)へ置き換えるパッチ群を、2024年に一度提案されたまま止まっていた過去の作業を土台に完成させ、VRAM不足時にアプリが突然クラッシュする問題を減らしました。
実機での検証では、8GiBのVRAMを積んだ環境で『Indiana Jones: The Great Circle』の設定を上げ、ゲームが約9GiB(1GiBがシステムRAMへオーバーコミット)を要求する状態にしたところ、平均フレームタイムは19.6ミリ秒(秒間およそ51コマに相当)で「十分に快適にプレイできる」水準だったと報告されています。さらに設定を上げて約10GiB(2GiBのオーバーコミット)を要求させると、フレームタイムのばらつきが大きくなり、33.3ミリ秒を超える(30fpsを割り込む)瞬間が頻繁に発生するようになったものの、平均は29.8ミリ秒(秒間およそ34コマ)にとどまったとのことです。
アプリ側の協力も効果を高めています。Vulkanのメモリ優先度拡張機能(VK_EXT_pageable_device_local_memory)を使うと、アプリはどのメモリが退避されても影響が小さいかをドライバーへヒントとして伝えられます。ProtonでDirectX 12のゲームをVulkanへ変換する「vkd3d-proton」は、この拡張機能をすでに活用しており、Direct3D 12のメモリ常駐API(MakeResident・Evict・SetResidencyPriority)をVulkan側の優先度へ自動的に変換しています。つまり、対応済みのDirect3D 12タイトルであれば、Proton経由でプレイするだけで恩恵を受けられる仕組みです。一方、この拡張機能を使っていないネイティブVulkanタイトルでは、今のところ同様の恩恵は得られません。Vock氏は、優先度に沿った退避によって最良のケースでは性能が3割ほど改善する例も観測したとしていますが、これは退避されるメモリの内容に左右される値で、一般的な目安として扱わないよう注記しています。
重要なのは、このVRAM overcommit部分は2026年8月時点でまだLinuxカーネル本流へ統合されておらず、Vock氏自身が「正式なメンテナンスは行わない」と断ったうえで、検証用のカーネルブランチとMesaブランチを個別に公開している段階だという点です。Bazzite 44はこの成果を独自にビルドへ取り込んでおり、一般的なディストリビューションより先に試せる一方、まだ開発途上の機能である前提で使う必要があります。
注意8GBのGPUが16GB相当になるわけではない
ここまでの内容から誤解してはいけないのは、この機能がVRAMの物理容量そのものを増やすわけではないという点です。8GBのGPUはあくまで8GBのGPUのままで、システムRAM側へあふれたデータはPCIe経由でのアクセスになるため、前述のとおり本物のVRAMより大幅に遅く、1フレームあたりに読み出せる量にも物理的な上限があります。
今回の改善が解決するのは、あくまで「他のアプリがゲームのVRAMを不当に奪う」という問題です。ゲーム自体が搭載VRAMを大幅に超えるメモリを本気で必要とする場合、クラッシュはしにくくなってもフレームレートの低下そのものは避けられません。Vock氏が2026年4月の検証時点で確認した範囲では、多くの現行ゲームはおおむね8GB程度かそれ以下のVRAM予算に収まっていたとされていますが、これはあくまでその時点のゲームを対象にした観察であり、今後より多くのVRAMを要求するタイトルが増えれば状況は変わり得ます。
恩恵どんな環境で効果を実感しやすいか
対応状況AMDGPU以外のGPUではどうなるか
Vock氏の検証と実装は、Valve自身が扱うAMD製GPU(amdgpuドライバー)を中心に進められており、実績が積み上がっているのもAMD環境です。一方でdmem cgroupコントローラー自体は、前述のとおりIntelのエンジニアが原型を書いた汎用のLinuxカーネル機能で、Intelの現行カーネルドライバー「Xe」もすでにこのコントローラーに対応しています。ただしVock氏自身、2026年4月の時点で「理論上はIntel GPUでも恩恵があるはずだが、実際に誰かが検証したかどうかは分からない」と述べており、AMDのように実際のゲームで効果が確認されているわけではありません。
NVIDIAについては、プロプライエタリなカーネルモジュールがdmem cgroupへ対応していないため、今回の仕組みはそのままでは機能しません。なお、NVIDIA GPU向けの完全にオープンソースなドライバーである「nouveau」については、Vock氏自身がdmem cgroup対応パッチをLinuxカーネルのメーリングリストへ送付していますが、nouveauの実ゲーム性能はNVIDIA公式ドライバーに比べてまだ大きく見劣りするため、実用上の選択肢として広く使える段階ではありません。
あわせて追加AMD Radeon向けHDMI 2.1(FRL・ALLM・VRR)もBazzite 44から
Bazzite 44の変更点はVRAM管理だけではありません。同じアップデートで、AMD Radeon向けにHDMI 2.1のFRL(高帯域伝送)・ALLM(自動低遅延モード)・VRR(可変リフレッシュレート)を扱う新しいスタックも追加されました。こちらは初期設定では無効になっており、Bazzite Portalの「Tweak Systems」から有効にするか、ターミナルでujust configure-amd-hdmi21を実行する必要があります。
この機能がLinuxカーネル側でどのように積み上げられてきたか、なぜ長年実現しなかったのか、有効化した際の既知の不具合や回避策までは、テレビ接続にまつわる技術的な背景を専門に扱った別記事で詳しく解説しています。
その他Bazzite 44のそのほかの変更点
今回のアップデートでは、VRAM管理やHDMI 2.1以外にも、システム全体にわたる変更が多数含まれています。
- カーネル・グラフィックスドライバー：Open Gaming Collective(OGC)カーネルが7.2.0へ、MesaがVersion 26.2.1へ更新されました。
- デスクトップ環境：KDE Plasmaが6.6へ、GNOMEが50へそれぞれ移行しています。
- GPU切り替え：ノートPCや複数GPU環境向けの切り替えツールが、従来のswitcheroo・supergfxctlから新ツール「Cardwire」へ移行しました。ASUSノートPCのMUXスイッチ切り替えにも対応しています。
- NVIDIA関連：イメージ更新後にFlatpakアプリのランタイムを自動更新する仕組みが加わりました。580 LTSドライバーを使うレガシー向けイメージもOGCのLTSカーネルへ移行し、Maxwell・Pascal・Voltaなど旧世代GPUのサポートを継続しています。
- キャプチャーカード：Elgato製4Kキャプチャーカード向けのドライバーサポートが追加されました。
- そのほか：ビルドの署名やSBOM(部品構成表)によるサプライチェーンの安全性強化、ASUS Linux向けパッチへの追従などが行われています。
判断更新すべきか、何を期待すべきか
Bazzite 44のVRAM管理は、ベンチマークの数字を押し上げる類のアップデートではありません。評価すべきは、VRAM不足という誰もが一度は経験する場面で、クラッシュやフレームタイムの乱れという「体感の悪さ」を減らしている点です。8GB以下のGPUや携帯型ゲーミングPCを使っているなら、更新する価値は明確にあります。
- VRAM不足によるクラッシュを防ぎ、フレームタイムを安定させる実質的な改善
- 8GB以下のGPUや携帯型ゲーミングPCで特に体感しやすい
- AMD Radeon向けHDMI 2.1(FRL・ALLM・VRR)も同じアップデートでオプトイン提供
- 平均フレームレートやベンチマークスコア自体は上がらない
- 8GBのGPUが16GB相当になるわけではなく、PCIe帯域という物理的な上限が残る
- NVIDIAのプロプライエタリドライバーには適用されない
- VALORANTなどカーネルレベルのアンチチートを要求するタイトルはProton経由でも動作せず、Windowsを完全に置き換えられるとは限らない
FAQよくある質問
ujust configure-amd-hdmi21を実行する必要があります。詳しい技術的背景は関連記事で解説しています。まとめBazzite 44のVRAM管理は「安定化」であって「増量」ではない
Bazzite 44に搭載された新しいVRAM管理は、VRAM不足時にフォアグラウンドのゲームを優先する「dmem cgroup」と、物理容量を超えた要求があっても即座にクラッシュさせず処理を継続する「VRAM overcommit」の組み合わせです。開発したのはValveの契約エンジニアであるNatalie Vock氏で、フォアグラウンド優先の仕組みはLinuxカーネル7.3への統合が決まっている一方、VRAM overcommitの本体はまだ開発が続いている段階です。
この機能が改善するのは、VRAM不足によるクラッシュやフレームタイムの乱れという体感の悪さであって、GPUの平均フレームレートやベンチマークスコアではありません。PCIe帯域という物理的な上限がある以上、8GBのGPUが16GB相当になるわけでもありません。恩恵を受けやすいのは8GB以下のGPUや、VRAMに余裕のない携帯型ゲーミングPCを使っている人で、すでに大容量VRAMを積んでいる環境では体感の変化は小さくなります。またNVIDIAのプロプライエタリドライバーには適用されず、カーネルレベルのアンチチートを要求するゲームはProton経由でも動作しないことがあるため、Windows環境を完全に置き換えられるとは限りません。自分の環境がどちらに当てはまるかを踏まえたうえで、更新するかどうかを判断してください。
あわせて読みたい
※価格は2026年8月時点の目安・変動あり
※価格は2026年8月時点の目安・変動あり
