AMDがLinux向けHDMI 2.1のVRR・ALLMパッチを公開｜Radeonのテレビ接続がついに改善へ【2026年8月】
本記事にはアフィリエイト広告（Amazon・楽天市場等）のリンクが含まれています。
Linuxカーネル開発者のTomasz Pakuła氏が中心となって進めてきたAMDGPUドライバー向けの拡張パッチシリーズの最新版が、2026年7月30日にamd-gfxメーリングリストへ投稿されました。HDMI 2.1のVariable Refresh Rate（VRR）とAuto Low Latency Mode（ALLM）をLinux版Radeonへ追加する内容で、DisplayPortに限られていたRadeonのVRR対応がHDMI接続へも広がる可能性があります。ただし2026年8月2日時点ではレビュー中の段階で、一般的なLinux環境で今すぐ使えるわけではありません。
Linux搭載のゲーミングPCをリビングの4Kテレビへ接続してプレイしていると、フレームレートが変動する場面で画面がカクついたり、ゲームを始めるたびにテレビのリモコンでゲームモードへ切り替えたりする必要があると感じたことがある人は少なくないはずです。RadeonのLinux向けドライバーはDisplayPort経由のVariable Refresh Rate（VRR）には以前から対応していましたが、多くのテレビが搭載するHDMI経由ではこの種の機能を十分に使い切れていませんでした。
2026年7月30日、オープンソース版AMDGPUドライバーへHDMI 2.1のVRRとAuto Low Latency Mode（ALLM）を追加するパッチが、Linuxカーネルのamd-gfxメーリングリストへ投稿されました。ゲームのフレームレートに合わせてディスプレイのリフレッシュレートを変化させるVRRと、ゲーム開始時にテレビを低遅延モードへ自動的に切り替えるALLMを、HDMI接続でも利用できるようにする内容です。
本記事では、VRRとALLMがそれぞれ何を改善する技術なのかという基礎から、今回のパッチが持つcontent-type判定やモジュールパラメータといった技術的な仕組み、事前に公開されていたFRL・DSCパッチとの関係、Linuxカーネルへの統合時期とSteamOSへの波及見通しまで、一次情報を基に整理します。
目次
要点AMDGPUドライバーへHDMI 2.1のVRRとALLMを追加するパッチが投稿された
2026年7月30日、Linuxカーネル開発者のTomasz Pakuła氏が進めてきたAMDGPUドライバー向けの拡張パッチシリーズの最新版が、amd-gfxメーリングリストへ投稿されました。HDMI 2.1のVRRとALLMをRadeonのLinux向けドライバーへ追加する内容で、コンテンツタイプが「Game」に設定された場合、またはHDMI VRRが有効になった場合にALLMを自動的に有効化する仕組みが含まれています。パッチはAMDのディスプレイエンジニアや他のカーネルグラフィックスメンテナーによるレビューを受けている段階で、2026年8月2日時点ではまだLinuxカーネル本流へ統合されていません。
出典：amd-gfxメーリングリスト「drm/amd: VRR fixes, HDMI Gaming Features」
仕組みVRRに対応するとティアリングやカクつきを抑えられる理由
PCゲームのフレームレートは常に一定ではありません。軽い場面では120fps出ていても、敵やエフェクトが増える場面では90fps、さらに重い場面では70fps台まで落ち込むことがあります。一方、一般的なテレビやモニターは60Hzや120Hzといった固定のタイミングで画面を更新します。
GPUが映像を完成させるタイミングと、ディスプレイが画面を書き換えるタイミングがずれると、画面の上下に異なるフレームが混在して表示されるティアリングが発生します。V-Syncを有効にすればティアリングは抑えられますが、GPUが次のフレームを時間内に用意できなかった場合、同じフレームを長く表示することになり、動きが一瞬止まったように見えるスタッターや、余計な入力遅延が生じる場合があります。
VRRは、GPUがフレームを完成させるタイミングに合わせて、ディスプレイ側のリフレッシュレートを変化させる技術です。HDMI Licensing Administratorは、VRRによって遅延、スタッター、フレームティアリングを軽減または解消できると説明しています。
RadeonのLinux向けドライバーは、DisplayPort経由のFreeSync・Adaptive-Sync（VRR）には以前から対応していました。しかし、多くのテレビはDisplayPort端子を搭載しておらずHDMIしか選べないため、HDMI経由のVRRに対応していないことは、テレビへLinuxゲーミングPCを接続する場面での大きな制約になっていました。
留意点VRRを有効にしてもフレームレート自体は上がらない
VRRはゲームの描画性能を高める機能ではありません。VRRを有効にしても、GPUの処理能力やゲームの平均フレームレートが上がるわけではなく、70fpsしか出ていないゲームがVRRによって120fpsになることはありません。変化するのは、GPUが出力するフレームとディスプレイの表示タイミングの同期方法です。フレームレートが安定しない状況でも、画面の更新タイミングを合わせることで、ティアリングやスタッターを目立ちにくくします。今回のAMDGPUパッチが正式に利用可能になっても、Radeonの平均fpsやベンチマークスコアが直接向上するわけではない点には注意が必要です。
機能ALLMはゲーム開始時にテレビのゲームモードを自動的に切り替える
ALLMは「Auto Low Latency Mode」の略で、日本語では自動低遅延モードと呼ばれます。現在のテレビには、映像をきれいに見せるためのノイズ低減、フレーム補間、超解像、輪郭補正といった映像処理機能が数多く搭載されています。映画やテレビ番組を見る場合には効果的ですが、映像を受け取ってから実際に表示するまでの処理時間が増えるため、ゲームでは入力遅延の原因になります。
多くのテレビには映像処理を減らす「ゲームモード」が用意されていますが、従来はリモコンで入力設定や映像モードを手動で切り替える必要がありました。
HDMI Licensing Administratorは、ALLMをゲーム機やPCがディスプレイへ低遅延モードへの切り替えを要求し、その必要がなくなった際には信号を解除して通常モードへ戻す仕組みとして説明しています。ALLMに対応した機器はゲームを開始するとテレビへ低遅延モードを要求する信号を送信し、テレビ側がALLMに対応していれば自動的にゲームモードへ切り替わります。
動画配信サービスなどゲーム以外の用途へ戻ると、テレビは通常の映像モードへ復帰できます。ゲームのたびにテレビの設定を変更する必要がなくなるため、リビングのテレビへLinux PCやSteamOS系デバイスを接続する環境では特に恩恵が大きい機能です。
補足ALLMも処理速度そのものを上げる機能ではない
ALLMが減らすのは、主にテレビ内部で発生する映像処理の遅延です。GPUがゲームを描画する時間や、CPUがゲーム処理を行う時間、コントローラーからPCへ信号が届く時間が短くなるわけではありません。テレビの通常モードで重い映像補正が有効になっていた場合は、ゲームモードへの切り替えによって操作感が大きく改善する可能性があります。
一方、あらかじめテレビをゲームモードへ固定して使っている場合、ALLMを利用しても入力遅延自体はほとんど変わらず、設定を自動化できることが主なメリットになります。ゲームモードでは映像補間や一部の画質補正が無効になる場合があるため、低遅延を優先する代わりに動画視聴時の画質が変わる可能性がある点も踏まえると、ゲーム終了後に自動復帰できるALLMの実用性は高いといえます。
設定content-typeの判定とALLMの制御方法
今回のパッチでは、ALLMはVRRが有効になっている場合、またはHDMIの規格で規定されているコンテンツタイプヒントが「Game」に設定された場合のいずれかで自動的にトリガーされる仕組みになっています。コンテンツタイプヒント自体はAMDGPUドライバーで以前から対応済みの機能で、今回のパッチはこれをALLMの起動条件として活用しています。
あわせて、ALLMの挙動（常に無効・VRRやゲーム時のみ自動的に有効・常時強制的に有効の3パターン）をユーザー側で設定できる仕組みと、Windows環境でのFreeSyncデスクトップ動作を再現し、フルスクリーンのゲーム以外でも常時VRRを有効にしておく「HDMI VRRデスクトップモード」という設定（初期状態で有効）が追加されています。デスクトップ環境で発生していた不要な画面の点滅や表示の乱れを避けるために用意された機能です。
※これらの設定項目は、パッチの初期版ではカーネルモジュールパラメータとして提案されていましたが、開発が進んだ後のバージョンではDRM（Direct Rendering Manager）の標準プロパティとして扱う方式へ変更されています。最終的にどのような操作方法でユーザーに提供されるかは、レビューの進行や正式版での実装によって変わる可能性があります。
背景Linuxで長期間HDMI 2.1対応が制限されていた理由
RadeonのWindows向けドライバーでは、対応GPUと対応テレビを組み合わせることでHDMI 2.1の高帯域出力やVRRを利用できます。一方、Linuxで使用されるAMDGPUドライバーはオープンソースで開発されているため、HDMI 2.1の仕様を公開コードとして実装することが難しい状況が続いていました。
2024年、AMDはHDMI 2.1のオープンソース実装についてHDMI Forumへ承認を求めましたが、却下されています。AMD側は当時、この状況について「HDMI Forumは私たちの提案を却下しました。現時点では、HDMI Forumの要件に違反せずにオープンソースのHDMI 2.1実装を行うことはできません」と説明していました。この影響で、Linux版AMDGPUドライバーでは4K・120HzやHDMI経由の5K・240Hzが利用できないというバグ報告が3年近く未解決のまま残されていました。
ハードウェア上はHDMI 2.1に対応できるRadeonでも、Linuxのオープンソースドライバーでは機能を十分に利用できない状態が続いていたことになります。テレビの多くはDisplayPort端子を搭載していないため、LinuxユーザーがDisplayPort経由の高リフレッシュレートやVRRを利用したくても、リビング向けテレビではHDMIを使わざるを得ないケースが少なくありません。
今回、AMDGPUドライバーへFRL、DSC、VRR、ALLMのパッチが段階的に投稿されたことで、LinuxのオープンソースドライバーでもHDMI 2.1の主要機能が実用化へ近づいています。
出典：GamingOnLinux「The HDMI Forum rejected AMD’s open source HDMI 2.1 implementation」
経緯FRLとDSCから段階的に進んできたHDMI 2.1対応
AMDはHDMI 2.1のすべての機能を一度に追加したわけではありません。まず公開された重要な機能がFRLです。FRLは「Fixed Rate Link」の略で、HDMI 2.1で高い映像帯域を実現するための伝送方式です。従来のTMDSよりも多くのデータを転送でき、高解像度・高リフレッシュレート出力の基盤になります。
続いて対応が進められたのが、映像データを圧縮して限られた伝送帯域の中で高い解像度やリフレッシュレートを実現するDisplay Stream Compression（DSC）です。2026年5月、AMDはFRLとDSCの両方に対応するパッチをLinuxカーネルへ投稿しました。FRLとDSCがそろうことで、対応するGPU・テレビ・ケーブルの組み合わせでは、HDMI 2.1の高帯域を活用しやすくなります。
そのうえで今回、ゲーム時の表示を滑らかにするVRRと、テレビを自動的に低遅延モードへ切り替えるALLMが加わったことで、Linux版AMDGPUのHDMI 2.1対応は主要機能がひととおり出そろう段階に近づきました。
| 時期 | 出来事 | 内容 |
|---|---|---|
| 2024年2月 | HDMI Forumが拒否 | AMDのオープンソースHDMI 2.1実装提案が却下される |
| 2026年5月 | FRL・DSCパッチ | 高帯域伝送（FRL）と映像圧縮（DSC）のパッチをLinuxカーネルへ投稿 |
| 2026年7月30日 | VRR・ALLMパッチ | 可変リフレッシュレートと自動低遅延モードのパッチをamd-gfxへ投稿 |
出典：amd-gfxメーリングリスト「[PATCH RESEND v3 00/14] HDMI FRL and DSC Support for amdgpu」
制約FRLはVRR対応が整うまで初期状態で無効になっている
2026年5月に投稿されたFRLのパッチは、初期状態では無効になる設計でした。理由は、FRLを有効にした状態でHDMI VRRを利用できなければ、従来利用できていた一部のユーザーにとって機能低下になりかねないためです。FRL対応テレビを接続すると、ドライバーは高帯域なFRL接続を優先しますが、その接続経路でVRRが動作しなければ、高解像度や高リフレッシュレートを選べても可変リフレッシュレートを失う場合があります。
AMDはこの状況を避けるため、HDMI VRRへの対応が整うまではFRLをデフォルトで無効にする方針を取っていました。実験的に有効化する場合は、カーネルの起動オプションとしてamdgpu.dc_feature_mask=0x400を指定する仕組みが用意されていますが、一般ユーザーに推奨される設定ではありません。今回HDMI VRRのパッチが投稿されたことで、VRR対応が整い次第、AMDはFRLを初期状態で有効にする計画を明らかにしています。
展望Linux 7.3への統合を目指すが7.4へ持ち越す可能性もある
VRR・ALLMパッチは2026年7月30日に投稿され、amd-gfxメーリングリストでレビューを受けています。パッチシリーズは2026年1月ごろから複数回にわたって版を重ねてきたもので、AMDのディスプレイエンジニアや他のカーネルグラフィックスメンテナーからのフィードバックを踏まえて改良が続けられてきました。
次のLinux開発サイクルであるv7.3のDRM-Next取り込み期限はすでに近づいており、投稿の時点で間に合うかどうかは際どいタイミングです。8月後半に予定されている次のカーネルサイクルに間に合えばLinux 7.3へ含まれる可能性がありますが、レビューや修正に時間がかかった場合はLinux 7.4へ持ち越される可能性があります。
2026年8月2日時点のLinuxは、安定版が7.1.5、開発中のメインラインが7.2-rc5です。したがって、現在使用しているUbuntu、Fedora、Arch Linux、CachyOSなどを更新しても、今回のVRR・ALLM対応がすぐに有効になるわけではありません。
| 項目 | 状態 | 備考 |
|---|---|---|
| Linux安定版 | 7.1.5 | 2026年8月2日時点の最新安定版 |
| Linux開発版 | 7.2-rc5 | 2026年8月2日時点のメインライン |
| VRR・ALLM最短候補 | Linux 7.3以降 | DRM-Nextの取り込み期限に間に合うかは未定 |
| SteamOS安定版のカーネル | Linux 6.16 | 2026年6月に安定版へ昇格・本流より遅れて反映 |
現状SteamOSへの反映時期はまだ発表されていない
SteamOSはLinuxを基盤としており、Radeon向けのオープンソースドライバーを使用しています。そのため、AMDGPUのHDMI 2.1 VRR・ALLM対応は、将来のSteamOS搭載機や、SteamOS系ディストリビューションを導入したリビングPCにも恩恵をもたらす可能性があります。特にテレビへHDMI接続する機器では、DisplayPortよりHDMIを使用する場面が多くなります。
ただし、Linuxカーネルへパッチが統合されたからといって、SteamOSへ同時に反映されるわけではありません。ValveはLinuxカーネル、Mesa、Gamescope、SteamOSのシステム設定を組み合わせ、対象ハードウェアでの検証を経てからアップデートを配信しています。
現行の安定版SteamOSが採用しているカーネルはLinux 6.16で、2026年6月に安定版へ昇格した経緯があり、Linux本流の最新バージョンをそのまま即座に採用するわけではないスタイルであることが分かります。2026年8月2日時点では、SteamOSへの正式な反映時期や、どの機器がHDMI VRR・ALLMへ対応するかは発表されていません。
比較モニターよりテレビ接続で恩恵が大きい理由
注意FreeSync対応とHDMI Forum VRR対応は同じ意味ではない
「FreeSync対応」と「HDMI Forum VRR対応」は完全に同じ意味ではありません。テレビやモニターによってはAMD FreeSyncに対応していても、HDMI Forumが規定するVRRへの対応状況や利用できるリフレッシュレート範囲が製品ごとに異なる場合があります。
今回のパッチでは、ディスプレイから取得するEDIDやHDMIのVSDB（Vendor Specific Data Block）情報を使い、VRRの対応範囲やゲーム機能を認識するための処理が含まれています。実際に利用できるかどうかは、Radeonの世代、テレビの対応機能、ファームウェア、HDMI端子、ケーブル、Linuxカーネル、デスクトップ環境などに左右される可能性があり、テレビの商品ページに「HDMI 2.1」と記載されているだけでは、VRRやALLMへの対応を判断できない場合もあります。
高帯域なHDMI 2.1出力を利用するには、Radeon側のHDMI出力、テレビ側のHDMI入力、Linuxドライバー、カーネル、HDMIケーブルのすべてが対応している必要があります。古いHigh Speed HDMIケーブルでは、高解像度・高リフレッシュレート時に画面の点滅やブラックアウトが発生する可能性があるため、4K・120Hzなど高帯域の出力を利用する場合は、認証ラベルの付いたUltra High Speed HDMIケーブルを選ぶのが安全です。
また、どのRadeon世代で正式に4K・120HzやVRR・ALLMを利用できるかは、パッチが統合された後もGPU世代別・テレビ別の検証が必要です。ノートPCではHDMI端子が内蔵GPU側へ接続されている場合もあり、外付けGPUの構成によっても結果が変わります。開発中のパッチや起動パラメーターを使えば正式リリース前の機能を試せる場合がありますが、画面が映らない、リフレッシュレートを変更できない、HDRやVRRが不安定になるといった問題が起こる可能性があるため、日常的に使用しているゲーミングPCでの導入はおすすめできません。
判断今回のパッチをどう受け止めるべきか
今回のパッチは、Radeonのテレビ接続を今日から劇的に変えるものではありません。amd-gfxメーリングリストへ投稿された段階であり、Linuxカーネル本流への統合時期もLinux 7.3か7.4かで確定していません。
一方で、DisplayPort経由でしか使えなかったVRRをHDMI接続へ広げ、content-type判定によってALLMを自動化する仕組みには、2024年にHDMI Forumから提案を拒否されて以来の技術的な積み重ねが表れています。FRL・DSCという土台が先に整えられ、そこへVRR・ALLMが続いたことで、Linux版AMDGPUドライバーはHDMI 2.1の主要機能をひととおりカバーする段階に近づきました。
- DisplayPort限定だったRadeonのVRR対応がHDMI接続へ拡張される見込み
- content-type判定とモジュールパラメータによる柔軟なALLM制御設計
- FRL・DSC・VRR・ALLMと段階的にHDMI 2.1機能を積み上げてきた開発の継続性
- 2026年8月2日時点ではamd-gfxでレビュー中の段階で、正式版ではない
- Linux 7.3に間に合うかは未定で7.4へ持ち越される可能性もある
- SteamOSへの反映時期は発表されておらず対応GPU世代の検証も今後必要
FAQHDMI 2.1のVRR・ALLM対応についてよくある質問
総括Linux版RadeonのHDMI対応は完成に近づいたが、実際に使えるのはまだ先
AMDGPUドライバーへHDMI 2.1のVRRとALLMを追加するパッチが、2026年7月30日にamd-gfxメーリングリストへ投稿されました。VRRはゲームのフレームレートに合わせてディスプレイのリフレッシュレートを変化させ、ティアリングやスタッターを抑える技術です。ALLMはゲーム開始時にテレビを自動的に低遅延モードへ切り替え、ゲーム終了後は通常モードへ戻す技術です。
どちらもRadeonの処理性能自体を引き上げるものではありませんが、DisplayPortに限られていたVRR対応をHDMI接続へ広げる意味は大きいといえます。
今回のパッチは、2024年にHDMI ForumからAMDのオープンソースHDMI 2.1実装が拒否されて以来、FRL・DSCと段階的に積み重ねられてきた対応の延長線上にあります。ただし2026年8月2日時点ではレビュー中の段階で、Linux 7.3への統合が間に合うか、Linux 7.4へ持ち越されるかは確定していません。SteamOSへの反映時期も発表されておらず、対応するRadeon世代の検証もこれからです。
それでも、DisplayPort端子を持たない4KテレビへLinuxゲーミングPCやSteamOS系デバイスを接続したいユーザーにとって、今回の進展は見過ごせません。正式なパッチ化とLinuxカーネルへの統合時期、そしてSteamOSへの反映状況を、今後も追っていく価値があるテーマです。
あわせて読みたい
※価格は2026年7月時点の目安・変動あり
※価格は2026年8月時点の目安・変動あり
