LinuxのeGPU性能が80%以上改善|KWin新実装でCyberpunk 2077が27fpsから50fpsになった仕組みと条件
本記事にはアフィリエイト広告(Amazon・楽天市場等)のリンクが含まれています。
KDEのウィンドウマネージャー兼コンポジターであるKWinが、複数GPUを扱うための新しいプロトコル「linux-dmabuf v6」に対応しました。開発者による検証では、外付けGPU(eGPU)環境で『サイバーパンク 2077』のフレームレートが27fpsから50fpsへ改善しています。GPUの演算性能を引き上げたわけではなく、無駄なデータコピーを取り除いた結果です。
外付けGPUでLinuxのゲームを動かしていて、性能が思ったより出ないと感じたことがある人は少なくないはずです。ノートPCの内蔵GPUと外付けGPUを組み合わせるマルチGPU環境では、Windowsと比べてLinux側の最適化が遅れているという指摘が長く続いてきました。
KDEの開発者でKWinのメンテナーを務めるXaver Hugl氏が、外付けGPU環境の描画経路を見直す新しい実装を公開しました。Framework Laptop 13とRadeon RX 5700 XTを組み合わせた検証では、『サイバーパンク 2077』のフレームレートが27fpsから50fpsへ、率にして約85%向上しています。GPU自体を交換したわけではなく、KWinとlinux-dmabuf v6という新しいプロトコルへの対応によって、それまで発生していた不要なデータコピーを省いた結果です。
本記事では、Linuxのマルチグラフィックス環境がなぜ遅くなりやすかったのかという背景から、linux-dmabuf v6とKWinが何を変えたのか、そして大幅な改善を得るために必要な条件まで、開発者本人による一次情報を基に整理します。今回の約85%という数字がどんな環境でも再現できるわけではない点や、通常のゲーミングノートPCではどの程度の効果が見込めるのかという、公表されている情報の限界にも触れています。
目次
要点Cyberpunk 2077が27fpsから50fpsへ改善
Framework Laptop 13に外付けGPUケースでRadeon RX 5700 XTを接続した環境で、『サイバーパンク 2077』のフレームレートが低画質プリセットで27fpsから50fpsへ改善しました。GPUやモニターは交換せず、KWinとlinux-dmabuf v6という新しいプロトコルへの対応による描画経路の見直しだけで得られた数値です。
検証を行ったのは、KDEの開発者でKWinのメンテナーを務めるXaver Hugl氏です。使用したハードウェアは、パーツ交換に対応したモジュール式ノートPCの「Framework Laptop 13」と、外付けGPUケースに収めたAMD製ミドルレンジGPU「Radeon RX 5700 XT」です。映像出力には、解像度5120×1440・リフレッシュレート120HzのモニターをeGPU側の出力端子へ直接接続しています。
まず、単純なVulkanテストアプリ「vkcube」を全画面表示したところ、従来の環境では55fpsにとどまっていたフレームレートが、新しい実装ではモニターの上限である120fpsまで上昇しました。より実際のゲームに近い検証として『サイバーパンク 2077』を低画質プリセットで動かしたところ、通常のMesa開発版では27fpsだったのに対し、linux-dmabuf v6に対応した環境では50fpsまで伸びています。改善率は約85%です。
| テスト内容 | 従来 | 対応後 |
|---|---|---|
| vkcube(全画面表示) | 55fps | 120fps(モニター上限) |
| サイバーパンク 2077(低画質) | 27fps | 50fps(約85%向上) |
GPUやeGPUケース、モニターを一切交換せず、映像データが通る経路を変更しただけでこの数値が出ている点がポイントです。ただし、この結果はどのLinux環境でも同じように再現されるわけではありません。横に長い高解像度モニターと、帯域が限られるUSB-C接続のeGPUを組み合わせていたことが、大きな改善幅につながった要因の一つです。
出典:Xaver Hugl氏によるブログ記事「Fixing Multi-GPU performance, part 1」
背景LinuxのマルチGPU環境が遅かった理由
ノートPCの中には、CPUに内蔵されたGPUと、ゲーム処理向けの専用GPUを両方搭載している機種があります。ここへ外付けGPUを追加すると、内蔵GPUとeGPUという2つのGPUを同時に扱うマルチGPU環境になります。Linuxのデスクトップ環境の多くは、画面表示の基盤としてWayland(ウェイランド)と呼ばれる仕組みを採用しています。Waylandでは、ゲームなどのアプリケーションが作った映像データを、デスクトップ全体の合成表示を担うコンポジターと呼ばれるソフトウェアへ渡します。このやり取りに使われるプロトコルの一つが「linux-dmabuf」です。
これまでのlinux-dmabuf v5までの仕組みでは、コンポジターがアプリケーションへ通知できる利用可能なGPUは1つだけでした。そのため、ゲームを描画しているGPUと、デスクトップを合成しているGPUが異なる場合、ドライバーは互換性を保つために映像データをシステムメモリへ経由させる必要がありました。たとえばゲームをeGPUで動かし、ノートPC内蔵GPUがデスクトップの合成を担当している構成では、eGPUのVRAMで生成されたフレームがシステムメモリへコピーされ、そこから内蔵GPUへ渡されます。さらにモニターがeGPU側の映像出力端子へつながっていると、内蔵GPUで合成した画面を再びeGPUへ送り返さなければなりません。ゲームの映像データがGPU間を往復することになり、これが性能低下と遅延の原因になっていました。
帯域eGPUでは不要なコピーの影響が大きい
デスクトップPCのPCIeスロットへ直接取り付けるグラフィックボードと比べて、USB4やThunderboltで接続するeGPUは利用できる帯域が限られています。通常のゲーム処理でも、CPUとeGPUの間ではテクスチャーや描画命令などのデータがひっきりなしに転送されており、そこへ完成した映像フレームの往復コピーまで加わると、USB-Cケーブルの帯域が圧迫されます。解像度が高く、リフレッシュレートも高いモニターほど、1秒間に転送しなければならない映像データの量は増加します。
今回の検証で使われた5120×1440・120Hzという環境は、映像を一方向にコピーするだけでも接続帯域を圧迫しかねない条件で、双方向のコピーが発生していたことが性能低下の主な要因だったとみられます。開発者も、『サイバーパンク 2077』の検証結果についてUSB-Cの帯域がボトルネックになっている可能性が高いと説明しています。今回の改善は、USB-CやeGPUケースが持つ最大帯域そのものを広げたものではありません。それまで不要なコピーに消費されていた帯域を、ゲーム本来の転送に回せるようにした結果です。
仕組みlinux-dmabuf v6で複数のGPUを正しく扱える
linux-dmabuf v6では、コンポジターが利用できるGPUを1つだけでなく複数通知できるようになります。アプリケーション側も、渡そうとしているバッファーがどのGPU上に存在するのかをコンポジターへ伝えられるようになりました。これにより、ゲームを描画している専用GPUのバッファーを、システムメモリを経由せずに渡せる可能性が生まれます。
ただし、コピーを単純にすべて止めればよいわけではありません。GPUやディスプレイの接続構成によっては、画面を正しく表示するためにGPU間のコピーが必要な場面も残ります。そのため、ドライバー側が不要なコピーを行わないようにするだけでなく、必要なコピーはコンポジター側で正しく処理し、省略できる場面では確実に省略する仕組みが求められます。オープンソースのGPUドライバー実装であるMesaと、Rust製Waylandコンポジター向けライブラリのSmithayについては、System76のVictoria Brekenfeld氏がプロトコル対応を進めています。
実装KWinがGPU間のコピーを管理する
KDEのウィンドウマネージャー兼コンポジターであるKWin側では、linux-dmabuf v6へ対応するだけでなく、複数のGPUを認識し、それぞれのバッファーがどのGPU上にあるのかを追跡する仕組みが必要でした。eGPUはPCの動作中に接続・取り外しが行われる可能性があるため、GPUのホットプラグへの対応や、GPUがリセットされた場合の処理、組み込み機器を含む特殊なマルチGPU構成への対応も求められます。
さらに、コピーが避けられない場面でも性能低下を抑えるため、KWinには高速なマルチGPUコピーを行うためのVulkan対応が追加されました。この実装によって、KWin内部には基本的なVulkan基盤も整備されています。将来KWinがVulkanレンダラーを採用する場合にも活用できる可能性があります。KWin側の実装は、マージリクエスト7101としてすでにマスターブランチへ統合されています。
実装内容:KDE GitLab|KWinマージリクエスト「implement linux dmabuf v6, and with it do multi GPU copies ourselves」
条件大幅な改善にはダイレクトスキャンアウトが必要
27fpsから50fpsという大きな改善を得るには、ゲームの映像を「ダイレクトスキャンアウト」できることが重要になります。ダイレクトスキャンアウトとは、ゲームが作成した全画面の映像を、コンポジターで再合成せずにディスプレイへそのまま表示する仕組みです。不要な合成処理とコピーを省けるため、GPU負荷とデータ転送量の両方を減らせます。
現在のKWinでは、デスクトップの合成処理は基本的にプライマリGPUで行われます。ノートPCでは、KWin起動時に内蔵ディスプレイへ接続されているGPU、つまり内蔵GPUがプライマリGPUになるのが一般的です。ゲームの映像を内蔵GPU側で再合成すると、eGPUから内蔵GPUへのコピーが再び必要になってしまいます。そのため今回のような大幅な改善を得るには、ゲームのバッファーをeGPU側に接続したモニターへ直接表示できることが前提になります。ウィンドウ表示や画面上の通知、オーバーレイなどによってダイレクトスキャンアウトが無効になった場合、改善幅は小さくなります。
制限HDRやナイトライトを使うと効果が出ない場合がある
検証に使われたRadeon RX 5700 XTでは、現在の実装でHDR・ナイトライト・カラープロファイルのいずれかを使用していると、大幅な性能改善を得られません。これらの機能は表示前に色の変換処理を必要とするためです。
GPUやドライバーが必要なカラーパイプラインへ対応していない場合、ゲームのバッファーをそのままディスプレイへ送ることができません。今回の検証環境では、HDR・ナイトライト・カラープロファイルをすべて無効にすることが、ダイレクトスキャンアウトを成立させるための条件になっていました。開発者はこの制限を緩和するための追加実装も進めており、色変換を含むさらなる改善は続報として公開する予定だと説明しています。
注意XWaylandで動くゲームにはそのまま適用できない
もう一つの大きな制約が、ゲームがWaylandをネイティブで利用している必要がある点です。Linuxで動くゲームの多くは、現在もX11、またはX11アプリケーションをWayland環境で動かす互換レイヤーであるXWaylandを経由しています。しかしX11の仕組みには、linux-dmabuf v6を有効に活用するうえで相性の悪い前提があり、XWayland経由で同じ効果を得られるかどうかは開発者自身も不透明だとしています。現時点では、ゲームがWaylandを直接利用している場合に限り、今回のような大きな性能改善を得られると説明されています。
Linuxネイティブのゲームの場合、SDLを使用しているタイトルであれば、起動時のオプションでSDL_VIDEODRIVER=waylandを指定するとWaylandネイティブへ切り替えられることがあります。Windows向けゲームをLinuxで動かす場合は、Wine Waylandドライバーへ対応したProton(SteamでWindows向けゲームをLinux上で動かすための互換レイヤー)の派生版が必要になる可能性があります。通常のProtonやゲーム側の状態によってはXWayland経由で起動するため、PlasmaやMesaを更新しただけで自動的に性能が上がるとは限りません。
展望Plasma 6.8へ更新すればすぐ50fpsになるわけではない
KWinのeGPU性能改善は、KDEのデスクトップ環境であるPlasmaの次期バージョン6.8向けの機能として案内されています。KDEの公式スケジュールでは、Plasma 6.8のベータ版が2026年9月10日と24日の2回に分けて公開され、安定版は2026年10月14日にリリースされる予定です。
Linuxでは、使用しているディストリビューションによってPlasmaやMesaが配信される時期が異なります。Plasma 6.8が公開されても、各ディストリビューションのリポジトリへ反映されるまでには時間がかかる場合があります。2026年7月31日時点では、KWin側の実装はすでに統合済みですが、Mesa側の実装はまもなく統合される見込みという段階です。NVIDIAもlinux-dmabuf v6へ対応したドライバーを開発しているとされていますが、同時点では未公開のままです。実際に改善を得るには、Plasma 6.8だけでなく、linux-dmabuf v6へ対応したMesaまたはNVIDIAドライバー、Waylandネイティブで動作するゲーム、ダイレクトスキャンアウトが成立する表示環境という、複数の条件がそろう必要があります。
| 項目 | 状態 | 備考 |
|---|---|---|
| KWin側の実装 | 統合済み | マージリクエスト7101として反映 |
| Mesa側の実装 | 統合作業中 | System76のVictoria Brekenfeld氏が担当 |
| NVIDIAドライバー | 未公開 | 実装は存在するが公開時期は未定 |
| Plasma 6.8安定版 | 2026年10月14日 | ベータ版は9月10日・24日に公開予定 |
スケジュール:KDE Community Wiki|Plasma 6 リリーススケジュール
見通し通常のゲーミングノートPCでは改善幅が小さい可能性
27fpsから50fpsという結果は、USB-C接続のeGPUと高解像度モニターを組み合わせた、帯域制限の影響を受けやすい環境で計測されたものです。内蔵GPUとノートPC内蔵の専用GPUを組み合わせた、一般的なゲーミングノートPCについてはまだ実測されていません。
ノートPC内部の専用GPUはeGPUより広い帯域を利用できるとはいえ、余計なメモリ転送を減らせれば、平均フレームレートだけでなく、フレームタイムや消費電力が改善する可能性は残ります。ただし、この5〜10%という数字はあくまで開発者による現時点の見立てであり、今後の検証によって変わる可能性があります。
判断LinuxでeGPUを使う価値は高まるのか
linux-dmabuf v6は、eGPUそのものの帯域制限を解消する技術ではありません。USB4やThunderboltで接続する以上、デスクトップPCのPCIeスロットへ直接取り付けたグラフィックボードと同じ性能を出すことは難しいままです。CPUとGPU間の通信を多く必要とするゲームほど、接続帯域による性能低下も残ります。一方で、従来のLinux環境ではeGPUの接続帯域が、本来不要なフレームコピーにも使われていました。linux-dmabuf v6と新しいKWinの実装は、このソフトウェア側の無駄を大きく減らすものです。
- GPUやモニターを交換せず描画経路の見直しだけで約85%の改善を確認
- マルチGPUを正しく認識できる、プロトコル自体の設計を見直した根本的な対策
- KWin側の実装はすでに統合済みで、Mesa対応も進行中
- 効果が大きいのはWaylandネイティブ動作かつダイレクトスキャンアウトが成立する環境のみ
- HDR・ナイトライト・カラープロファイル使用時は現状恩恵なし
- 通常のゲーミングノートPCでの改善幅は5〜10%程度という未検証の推測値
特に、モニターをeGPUへ直接接続し、Waylandネイティブでゲームを全画面表示する環境では、大きな改善を期待できます。Windowsと比べてLinuxではeGPUの設定やゲーム互換性が課題になりやすい状況が続いていますが、描画経路によるボトルネックの一つは解消へ向かっています。
FAQlinux-dmabuf v6に関するよくある質問
総括描画経路の無駄をなくした、地に足のついた改善
LinuxのeGPU環境で『サイバーパンク 2077』が27fpsから50fpsへ改善したのは、Radeon RX 5700 XTの処理性能が上がったからではありません。linux-dmabuf v6によって複数のGPUを正しく扱えるようになり、KWinがGPU間のバッファーとコピーを管理することで、システムメモリや内蔵GPUを経由する不要なデータ転送を省けるようになった結果です。
ただし約85%という改善率は、Framework Laptop 13、Radeon RX 5700 XT、5120×1440・120Hzモニターを組み合わせた特定環境での数値です。Waylandネイティブ動作、ダイレクトスキャンアウトの成立、HDRやカラープロファイルを使わないことなど、いくつもの条件が重なっています。2026年10月14日予定のPlasma 6.8へ更新するだけで、すべてのゲームが同じように高速化するわけではありません。
それでも、LinuxのマルチGPU環境に長く残っていた非効率な描画経路が見直されたことは、eGPUやゲーミングノートPCを使う人にとって前進です。Mesa対応やNVIDIAドライバーの公開、通常のノートPCでの実測結果など、続報の内容を追っていく価値があるテーマです。



