AMD、AMDGPUにHDMI 2.1 FRLパッチを投入
2024年に「不可能」と宣告されたAMDGPUでのHDMI 2.1対応に、AMD自身がついに公式パッチを投入した。完全対応ではないが、長年の膠着を破る最初の一歩だ。
2024年に「不可能」と宣告されたAMDGPUでのHDMI 2.1対応に、AMD自身がついに公式パッチを投入した。完全対応ではないが、長年の膠着を破る最初の一歩だ。
2年前に「不可能」だった話の続き
2024年2月、AMDのLinuxエンジニア、アレックス・ドイチャー（Alex Deucher）はあるバグチケットに重い返信を書き込んだ。HDMIフォーラム（HDMI Forum）がオープンソース実装を却下した、というものだ。AMDは数か月をかけて法務チームと機能を洗い直し、内部ではコードまで動いていた。最後はHDMIフォーラムの承認待ちで、その承認が出なかった。
HDMIフォーラムは残念ながら我々の提案を却下した。現時点でオープンソースのHDMI 2.1実装は、HDMIフォーラムの要件に反することなしには不可能だ。
技術的に解けない問題ではなかった。組織と契約の問題だった。HDMIフォーラムはHDMI 2.1の仕様書を非公開にしており、オープンソースで実装するとその仕様が事実上世間に出てしまう。そこを止められた以上、AMDは身動きが取れなかった。Linuxユーザーは4K@120Hzも5K@240HzもHDMI経由では使えないまま、DisplayPortに逃げるか、テレビとつなぐのを諦めるかを選ばされてきた。
それから2年。状況は静かに動いていた。
2026年5月1日、AMD公式が動いた
Linuxグラフィックス開発者として長年AMDGPUのDC（Display Core）を担当してきたハリー・ウェントランド（Harry Wentland）は本日、amd-gfxメーリングリストに21本のパッチシリーズを投げた。タイトルは「HDMI FRL Support for amdgpu」。AMDGPUドライバーにHDMIのFRL（Fixed Rate Link、固定レートリンク）対応を追加する内容だ。
このパッチシリーズはamdgpuディスプレイドライバーにHDMI FRLサポートを追加する。DSCはまだテスト中で、後ほど別途送る。
ウェントランドのカバーレターはそう始まる。179ファイル、2万1627行追加、179行削除。実装の中心はDC（Display Core）コードで、DCN 3.0からDCN 4.2まで主要な世代をまたいでFRLレジスタを追加している。各GPUアーキテクチャ世代ごとにレジスタ定義が異なるため、ファイル数が多くなる構造だ。
注目すべきは、このパッチが方針転換を示唆する点にある。2024年に却下された実装が、2026年に出てきた。間に何が起きたかは、コミット履歴には書かれていない。
「FRL」と「HDMI 2.1」は同じではない
ここで一度、用語を整理しておきたい。今回のパッチは「HDMI 2.1完全対応」ではない。FRLだけが対象だ。
FRLはHDMI 2.1で導入された伝送方式の名前で、それまでのTMDS方式に代わるものだ。レーンあたり最大12Gbps、4レーンで48Gbpsの帯域を出せる。これがあるから4K@120Hzや8K@60Hzのような帯域食いの解像度が成立する。
ただしHDMI 2.1の機能はFRLだけではない。VRR（Variable Refresh Rate、可変リフレッシュレート）、ALLM（Auto Low Latency Mode）、eARC、Dynamic HDR。これらすべてを合わせて「HDMI 2.1」と呼ばれている。今回のパッチについてもウェントランドは、明確にFRLだけであってVRRなどを含む完全なHDMI 2.1対応ではない、とカバーレターで強調している。
つまり、4K@120Hz自体は通せる目処が立った。しかしゲーミング向けのVRRはまだ別の話として残っている。AMDのオープンソース実装は、機能ごとに少しずつ解禁されていく形になりそうだ。
独立開発者の圧力が効いたのか
2024年の却下から2026年のパッチ投入までの2年間、コミュニティ側も止まっていなかった。
2026年2月、ある独立開発者が完全に外部からHDMI FRLをAMDGPUに実装したパッチをGitHubで公開した。Windowsドライバーの挙動とAMD-Xilinxの公開コードを観察し、Radeon GPUのレジスタ状態の差分を解析するという、いわばクリーンルームに近いアプローチだ。Radeon RX 9070 XT（DCN 4.0.1）でFRLトレーニング、映像、音声、HDR、ホットプラグまで動く状態のコードが、Redditで「テスター募集中」として公表された。
このコードは正式にはAMDGPUにマージされるルートがない。AMDが自分で書いた実装ではないし、HDMIフォーラムの承認も通っていない。それでも「やればできる」という事実が公の場に出たことの意味は大きかった。
同じ時期、オープンソースのNVIDIAドライバーNouveauもHDMI FRL対応を達成している。Nouveauの場合はNVIDIA側のクローズドファームウェアが仕様の機微な部分を吸収する構造のため、AMDより道筋がつけやすかった。
外圧と独立実装、そしてLinuxゲーミングの拡大。Steam Deckの普及で「LinuxでもHDMIテレビにつなぎたい」という需要は無視できなくなっていた。HDMIフォーラムが完全に折れたかは公表されていないが、AMDが法務的に進めていいと判断するに足る環境変化があったことは確かだ。
カーネルマージはLinux 7.2を狙う
ウェントランドのパッチはまだレビュー中で、サブシステムのメンテナーがマージするには検証期間が必要になる。Phoronixのマイケル・ララベル（Michael Larabel）は、夏のLinux v7.2マージウィンドウに間に合うことを期待していると書いている。Linux 7.1は4月26日にRC1が出たばかりで、6月中旬に正式リリース予定。その次の7.2が今回の現実的なターゲットだ。
このシリーズの最初のパッチはHDMI 2.1とは直接関係ないが、HDMI 2.1関連のコードがあちこちに散らばってしまうため、ここで一緒に整理した。次のDCパッチシリーズで取り込まれることになる。
カバーレター末尾のこの一文が示すのは、AMDGPU側ではこのFRLパッチを単発の特別な取り組みではなく、通常の開発フローに組み込んで送り出していることだ。法務的に特別扱いだった機能が、ようやく日常のメンテナンス対象になる。
ロドリゴ・シケイラ（Rodrigo Siqueira、現在Igalia所属、元AMD）が数年前にこの作業の土台を作っていたことも、カバーレターで言及されている。「残念ながら彼がAMDにいた間に送り出すことができなかった」という一文に、技術的な準備は整いつつ送り出せない期間が続いていた事情が滲む。
それでもDisplayPortが優位な理由は残る
ここで楽観しすぎないように書いておく。今回のパッチで変わるのはHDMI出力しかないモニターやテレビにつなぐ場面であり、PC用ディスプレイの主流であるDisplayPortの優位性はそのまま残る。
DisplayPortを策定するVESAはオープンソースに対して協力的で、Linuxドライバーで仕様の全機能を使える。HDMIで何が起きていたかを知っているLinuxユーザーの多くは、すでにDisplayPort搭載モニターを選んできた。今回のFRL対応で意味が大きくなるのは、HDMIしか持たないテレビをPC用ディスプレイとして使う層だ。たとえばリビングのOLEDテレビでゲームをしたいユーザーや、Steam Deckや小型ゲーミングPCをテレビに直結したい人にとっては、ここがずっと痛い欠落だった。
加えて、Phoronixの記事には続報が付いている。Phoronixが取り上げた直後、AMDのLinux開発者が「完全なHDMI 2.1実装も来る可能性がある」とコメントしたという。FRLは入口で、VRRやALLMといったゲーミング機能も射程に入っているのなら、構図は大きく変わる。
長く膠着していた領域でこういう動きが出てくると、止まっていた歳月の手応えがあらためて見える。何年も前に立てられたバグチケットが、ようやく「Resolved」に近づきつつある。そこに至るまでに、却下があり、独立実装の圧力があり、Nouveauの先行があり、AMDの内部での法務調整があった。
ひとつのパッチシリーズが、2年分の沈黙に風穴を開けようとしている。
参照元
他参照
