AMDGPU、HDMI 2.1 FRLはデフォルト無効で投入へ
長年待たれてきたAMD Linuxドライバ向けHDMI 2.1 FRLサポートは、初期段階では起動オプションを書き加えなければ動かない。VRR未実装のまま有効にすると、既存ユーザーには「機能後退」に映るためだ。
長年待たれてきたAMD Linuxドライバ向けHDMI 2.1 FRLサポートは、初期段階では起動オプションを書き加えなければ動かない。VRR未実装のまま有効にすると、既存ユーザーには「機能後退」に映るためだ。
デフォルト有効を見送ったAMDの判断
オープンソースAMDGPUドライバ向けのHDMI 2.1 FRL（Fixed Rate Link）対応は、すぐに使える形では届かない。
5月20日に投稿された6回目のパッチセットで、AMDは FRLを既定で無効化 する方針に切り替えた。HDMI 2.1で4K 120Hzなどの高い帯域が必要な信号を流すための要となる部分が、ユーザー側の手動操作を経なければ動かない形で配信される。
使いたい人は、Linuxカーネルの起動オプションに amdgpu.dc_feature_mask=0x400 を加えて立ち上げる必要がある。インストーラを入れただけで4K高リフレッシュレートが通る環境は、もう一つ先に持ち越される。
なぜ「動くのに止めておく」のか
機能としては仕上がってきているのに、なぜ無効で出すのか。理由はVRR（可変リフレッシュレート）の実装が間に合っていないことにある。
VRRが整わないままFRLだけが先に通電すると、FRL対応ディスプレイをすでに使っているユーザーの環境では、ゲーム時のティアリングや映像の引っかかりがむしろ目立つ場面が出てくる。これまでうまく動いていた表示が崩れて見えるなら、機能追加というより 機能後退（リグレッション） と受け取られかねない。
リグレッション（regression）とは、新しいコードを入れた結果、これまで問題なく動いていた挙動が壊れる現象を指す。Linuxカーネル開発では、リグレッションを残したまま機能を入れることは強く避けられる。
AMDはこの「動かしておくと既存環境を悪化させかねない」状態を避けるため、起動オプションでオプトインさせる構造を選んだ。VRRの組み込みが終われば既定で有効に戻す予定で、起動オプションを叩く必要があるのは過渡期だけになる。
v6パッチノートの要点 ・FRLをデフォルト無効化（既存ユーザーへの後退回避） ・DSCコードにFP（浮動小数点演算）ガードを追加 ・DSCのバグ修正を含む
Linux v7.2に間に合うかが次の焦点
開発を主導しているAMDのLinuxエンジニア、 ハリー・ウェントランド （Harry Wentland）は、コードを安定化させたジェリー、数年前にこの作業の土台を作って退職前に投稿が間に合わなかったロドリゴ・シケイラ（Rodrigo Siqueira）に謝意を述べている。
DSCはHDMI 2.1で4K 240Hzや8Kといった高解像度・高リフレッシュレートを1本のケーブルに収めるための圧縮技術。FRLが広げた帯域だけでは足りない領域で効いてくる。
Phoronixのマイケル・ララベル（Michael Larabel）は、間もなく開く予定の Linux v7.2サイクル に滑り込めるかが当面の焦点だと指摘している。マージウィンドウに乗ればRadeonユーザーは年内のディストリビューション更新でFRL対応カーネルに触れられる可能性が高くなり、外れれば次のサイクル待ちになる。
HDMI Forumの壁の向こう側
AMDがHDMI 2.1相当の機能をオープンソースドライバに載せられなかった背景には、 HDMI Forum の存在がある。仕様の公開を巡って長く合意点が見つからず、その間にRadeonユーザーはWindowsとLinuxで体験差を強いられてきた。今回のパッチ系列でようやくその差が縮まる足場が固まる。
第6版の段階で既定有効に戻さなかった判断は、地味だが筋が通っている。長年待った機能をユーザーの環境を壊さない形で着地させるためのワンクッションだ。
「使えるが、自分でスイッチを入れる」という状態を一時的に挟むことで、AMDはFRL対応ディスプレイを今日使っている人の体験を守りつつ、VRR完成まで時間を稼ぐ。完成形にはあと一歩足りない、その一歩前の位置に今は立っている。
参照元
