AMD BC-250 FSR 4 Mod、アップスケーリング時間を半減 真価はゲームプレイで問われる
コミュニティが開発したFidelityFX DLLとともに公開されたベンチマークによると、AMD BC-250でのFSR 4処理は大幅に高速化した。1440pでは、報告されたアップスケーリングの処理コストが11.51ミリ秒から5.92ミリ秒へ低下した。この削減により、FSR 4は高コストな実験的機能から、この特殊なRDNAベースのボードでより現実的な選択肢へと近づいた。
この結果が重要なのは、BC-250がそもそも一般的なゲーミングPC向けに設計された製品ではないためだ。AMDはASRockのマイニングシステム向けにこのセミカスタムプロセッサを製造しており、そのシリコンはPlayStation 5のプロセッサと近い系統に属する。その後、Linux愛好家たちはカスタムファームウェア、ドライバー、冷却機構、導入ツールを通じて、廃棄されたボードをコンパクトなゲーミングマシンへ転用した。
今回のリリースは、中心的な課題を基本的な互換性から実用的な性能へと移すものだ。従来の最適化作業は、改変されたMesaグラフィックススタックに依存していた。最新実装では、その変更をポータブルなFidelityFXライブラリに収めており、ユーザーはOptiScalerやProtonなどのツールと併用して導入できる。
ただし、報告された数値はゲーム全体の性能ではなく、アップスケーラーそのものを測定したものだ。開発者は合成的なRC9測定結果を公開している一方、新たなゲームプレイテストは依然として限られている。この成果は検証に値するものだが、その価値は安定性、画質、そして実際のゲームでの結果に左右される。
AMD BC-250 FSR 4の処理時間、3つの解像度で低下
RC9リリースでは、1080p、1440p、4KにおけるFSR 4.1.1の測定コストが概ね半減している。
最も重要な結果は、1706 x 960のQuality入力を用いた2560 x 1440出力で得られた。従来のFSR 4.1.1シェーダーでは、アップスケーリングディスパッチ全体に11.51ミリ秒を要したとされる。バージョン4.0.0-rc9では、同じ測定ワークロードを5.92ミリ秒で完了した。
これは約49％の削減に相当する。また、レンダリングパイプラインの残りの処理に約5.6ミリ秒を戻すことになる。毎フレームに16.67ミリ秒しか使えない60fpsを目標とするゲームでは、この差は大きい。
記録された他の解像度でも同様の傾向が見られる。1920 x 1080では処理時間が7.13ミリ秒から3.93ミリ秒へ低下し、3840 x 2160では25.72ミリ秒から12.08ミリ秒へ減少した。
これはそれぞれ約45％、53％の削減に当たる。したがって、この改善は単一の出力サイズに限定されているようには見えない。出力解像度が高くなり、アップスケーラーが処理するピクセル数が増えるほど、絶対的な削減時間も大きくなる。
開発者のRC9リリースでは、最適化コードをamd_fidelityfx_upscaler_dx12.dllとして配布している。このライブラリは、対応する統合経路内でFidelityFXアップスケーリングプロバイダーとして機能する。従来のカスタムMesaビルドを必要とせず、該当するアップスケーラーコンポーネントを置き換える。
公開されたテスト概要によると、これらの数値は分離されたFSRディスパッチのコストを表す。フレーム時間全体や平均ゲーム性能の測定ではない。CPU処理、ゲームレンダリング、シェーダーコンパイル、変換レイヤー、ディスプレイ同期は測定対象外となっている。
この違いにより、短縮されたミリ秒をそのまま獲得フレーム数へ換算することはできない。CPUに制約されるゲームでは、改善がほとんど見られない可能性がある。一方、GPU負荷が非常に高いゲームは、特に従来のアップスケーリング処理がフレーム予算の大部分を消費していた場合、より大きな恩恵を受ける可能性がある。
それでも、この数値は特定の障害を解決している。RC9以前にもBC-250上でFSR 4を技術的に実行することは可能だったが、アップスケーラーが高リフレッシュレート時のフレーム予算の大半を消費しかねなかった。その負担をほぼ半減させたことで、より広範なテストを行う意義が生まれた。
したがって、このリリースは問いそのものを変える。コミュニティはもはや、FSR 4がこのボードで実行可能かどうかだけを問う必要はない。最適化された経路が、導入する価値があるほどプレイ体験全体を改善するかを問えるようになった。
ポータブルなFidelityFX DLLがカスタムMesa経路を置き換える
最も大きな進歩は移植性にある。最適化が特殊なグラフィックスドライバーではなく、アップスケーラーとともに提供されるようになったためだ。
従来のBC-250向け最適化は、Linuxシステムで広く使われるオープンソースのグラフィックススタックであるMesaを対象としていた。FSR 4が使用するINT8演算について、RADV Vulkanドライバーの処理を変更していた。INT8とは8ビット整数演算を指し、機械学習モデルでは処理コストとメモリコストを抑えるために用いられる。
この作業は、BC-250のGFX1013グラフィックスプロセッサが抱える特殊な制約に対処したものだ。このボードは必要なワークロードを実行できるものの、符号付きパック整数の内積経路の性能が低い。内積は複数の乗算と加算を組み合わせる処理であり、ニューラル画像処理モデルでは一般的な演算となっている。
先行プロジェクトでは、この高コストな経路をBC-250に適した処理列に置き換えた。リポジトリでは、問題のあるネイティブ経路に依存せず、代替の整数命令を使用する実験的なMesaビルドを説明している。この変更は特定のデバイス識別子と検証済みのシェーダーセットを対象としていた。
この手法は性能向上の可能性を示したが、導入はドライバースタック内で行う必要があった。ユーザーは専用のMesaビルドを用意し、正しいVulkan設定でゲームを起動しなければならなかった。Mesa、Proton、またはLinuxディストリビューションの変更時には、ドライバー改変の保守コストも生じる。
ポータブル実装では、この最適化をFidelityFX DLLへ移している。これにより、アップスケーラーはシステム全体に及ぶドライバー差分ではなく、交換可能なコンポーネントになる。ユーザーは対応するゲームまたはアダプター設定にライブラリを配置でき、Mesaを再ビルドせずに削除できる。
プロジェクトの導入ガイドによると、RC9では旧来の互換性ツールや特別なドライバー導入は不要だという。テスト済みの範囲は、通常のProtonを通じてLinuxを実行するBC-250ハードウェアにとどまる。Protonは、Linux上でWindowsゲームを動作させるためのValveの互換性レイヤーだ。
OptiScalerは、ゲームとFidelityFXライブラリの間のアダプターとして機能できる。利用可能なアップスケーリング経路を横取りし、選択したバックエンドを提供する。最終的なアップスケーリングを注入されたFidelityFXプロバイダーが実行していても、ゲーム内メニューにはDLSS、FSR、またはXeSSと表示される場合がある。
この構成は柔軟性をもたらす一方で、設定変数も増やす。ゲームには、モーションベクトルなど高解像度画像の再構築に必要なフレームデータを含む、互換性のある時間的入力が必要となる。DLL単体では、そもそもその情報を生成しないタイトルに情報を追加することはできない。
ユーザーはRC9が有効なプロバイダーであることも確認する必要がある。プロジェクトでは、内蔵ウォーターマークを有効にし、FSR-INT8、4.1.1R9、ローカルソースのラベルを確認することを推奨している。チェックサムは導入済みファイルを確認し、レンダリングされたウォーターマークはどのプロバイダーが画像を処理したかを示す。
これは、複数のアップスケーラーコンポーネントがProtonプレフィックスやmodを導入したゲームディレクトリ内に共存し得るため重要だ。自動ドライバー更新、既存のOptiScalerファイル、ゲームパッチによって、別のライブラリが気付かないうちに復元される場合がある。メニューが動作しているだけでは、最適化モデルがシーンをレンダリングしている証明にはならない。
したがって、移植性は普遍的な互換性を意味しない。これは最適化が、導入、検証、置き換え、ロールバックを容易にするパッケージへ移行したことを意味する。非対応ハードウェアを中心とするコミュニティプロジェクトにとって、これは運用面で大きな改善だ。
BC-250がこの成果を単なるmodding上の珍事にとどめない理由
高速化されたアップスケーラーは、特殊なマイニング製品から有用なゲーミングハードウェアを再生する、より大きな取り組みを後押しする。
BC-250は、6コア12スレッドのZen 2 CPUと統合型GFX1013グラフィックスプロセッサを組み合わせている。標準ボードでは24基のコンピュートユニットが公開され、16 GBのGDDR6統合メモリを搭載する。一般的なデスクトップとは異なり、このシステムは独立したDDRメモリモジュールに依存しない。
コミュニティのハードウェア文書では、このボードを非標準のフォームファクターを持つカスタムマイニング設計と説明している。映像エンコードおよびデコード用ハードウェアは利用できず、通常のPCケースやクーラーも改造なしには適合しない。ストレージ接続も一般的なマザーボードより制約が大きい。
このプロセッサは、SonyのPlayStation 5に関連する幅広いセミカスタムシリコンファミリーに属する。ただし、BC-250をデスクトップ版PS5と呼ぶのは、その関係を誇張することになる。有効化されているCPUコア、グラフィックス構成、ファームウェア、I/O、動作環境はいずれもコンソールとは異なる。
このボードは、暗号資産マイニング需要が弱まった後に愛好家市場へ流入した。その後、modderたちはファームウェアパッチ、Linuxドライバー対応、ファン制御、筐体、ゲーミング向けディストリビューションを開発した。それぞれの改善により、通常の消費者向けサポート経路を持たないハードウェアから一つずつ制約が取り除かれた。
先行プロジェクトは、標準構成でもLinux経由で負荷の高いPCゲームを実行できることを示した。コミュニティメンバーは後に、対応プロセッサで無効化されていたCPUコアの復元や、より多くの物理グラフィックスコンピュートユニットの公開を試みた。これらの改造はチップ依存であり、すべてのボードで機能するわけではない。
FSR 4は、この再生の取り組みに新たな層を加える。AMDの現行FSR SDKは、空間データと時間的データを機械学習モデルと組み合わせ、高解像度フレームを再構築する。新しいグラフィックスプラットフォームを公式対応実装で対象とする一方、BC-250対応はコミュニティのエンジニアリングによるものだ。
ここには明確な緊張関係がある。FSR 4は旧世代のアップスケーラーより優れた再構成画質をもたらす可能性があるが、そのモデルには相応の処理コストが伴う。制約のあるボードでは、低い入力解像度でレンダリングして得た性能向上を、アップスケーラーが打ち消す可能性がある。
1440pでは、従来の11.51ミリ秒というコストは60fps時のフレーム予算の約69％を消費していた。この計算はFSRディスパッチのみを対象とする。ゲームはなお、ジオメトリ、ライティング、エフェクト、CPUシミュレーション、ドライバー処理、最終表示に時間を必要とする。
RC9では、この割合が約36％まで低下する。新しい数値も依然として高コストだが、実際のゲーム処理に使える余地は大幅に増える。4Kでは、25.72ミリ秒から12.08ミリ秒への削減により、アップスケーラー処理は60fps時のフレーム予算全体を下回る。
これはBC-250で4K・60fpsのゲームプレイが現実的になることを意味しない。残りのワークロードにも処理時間が必要であり、ボードのグラフィックス性能には依然として限界がある。それでも、アップスケーラーを単に起動可能にするだけでなく最適化することが重要な理由を示している。
AMD BC-250 FSR 4プロジェクトは、オープンなLinuxコンポーネントの価値も示している。開発者はシェーダーの挙動を調査し、高コストな命令経路を特定し、代替手法を検証して、その結果をパッケージ化できた。このプロセスは、完全にクローズドなドライバーとアプリケーションの連鎖ではより困難になるだろう。
とはいえ、このプロジェクトは一部でリバースエンジニアリングとサードパーティ統合に依存している。AMDはRC9を公式のBC-250リリースとして提示していない。ユーザーはこのDLLを、対応済みRadeonドライバー機能ではなく、ニッチなデバイス向けの実験的ソフトウェアとして扱う必要がある。
真の課題は、実用的な性能を伴わない互換性だ
RC9は、FSR 4を動作させることと、ゲームフレーム全体の中で有用なものにすることの隔たりに挑んでいる。
互換性を示すデモは、しばしば印象的なスクリーンショットを生み出す。機能が読み込まれ、ウォーターマークが表示され、ハードウェアがベンダーから正式にサポートされたことのない画像をレンダリングする。これは技術的なアクセス可能性を示すものだが、レイテンシ、安定性、持続的なゲームプレイについてはほとんど語らない。
BC-250はすでに互換性の基準を越えている。コミュニティによる先行研究では、FSR 4.1.1がこのボードのLinuxグラフィックススタックを介して実行できることが示された。問題は、機械学習シェーダー、特に符号付きパックド整数演算が消費する時間だった。
1440pでは、11.51ミリ秒のアップスケーリングパスが、あらゆる性能目標に深刻な負荷をかける。30 fpsのフレームには33.33ミリ秒が与えられるため、このオーバーヘッドは吸収しやすい。60 fpsの目標ではその半分となり、120 fpsではわずか8.33ミリ秒しかない。
RC9の5.92ミリ秒という結果は、それ単体であれば120 fpsのフレーム予算内に収まる。もちろん、ほかのすべての処理を含めればゲーム全体が収まるわけではない。それでも、最適化されたディスパッチは、ゲームがほかの処理をレンダリングする前の段階で、その予算全体を超えなくなった。
これがこのプロジェクトを支える根本的な逆転である。FSRは通常、ゲームがレンダリングするピクセル数を減らすことで性能を向上させる。最適化されていないBC-250のパスでは、再構築プロセスが節約した時間の大半を消費しかねなかった。この機能の解決策自体が、別のボトルネックになるリスクを抱えていた。
最適化されたDLLは、その矛盾を緩和する。コストをなくすわけではないが、理論上のサポートと実用的な性能との隔たりを縮める。これにより、開発者とユーザーはFSR 4をFSR 3、XeSS、あるいはより低いネイティブ解像度と比較する余地を得られる。
こうした比較には慎重な条件統制が必要だ。各アップスケーラーは異なる再構築ロジックを用い、異なる品質モードを提供する場合がある。ある実装におけるQuality設定が、別の実装と入力解像度、シャープネス、視覚的な挙動まで一致するとは限らない。
画質も、ディスパッチ時間だけ以上に重要である。高速なシェーダーであっても、不安定さ、ゴースティング、ちらつき、ディスオクルージョンのエラー、インターフェース要素の破損を引き起こすなら価値は乏しい。こうした問題は静止画のスクリーンショットより、動きの中で現れやすい。
同じ問題は平均フレームレートにも当てはまる。ベンチマークは平均値の上昇を示しても、フレーム配信が不均一な場合がある。ゲームの体感が改善したかどうかは、フレームタイムのパーセンタイルと目に見えるスタッターによって決まることが多い。
したがってRC9は、より単純な選択肢とも競わなければならない。ユーザーは低コストな旧式のFSR実装を選ぶか、ネイティブ設定を下げるか、より低いフレームレートを受け入れることができる。最適化されたFSR 4パスが優位になるのは、画質向上が残るオーバーヘッドと導入の複雑さを正当化できる場合に限られる。
このプロジェクトは、すべての代替策に勝つ必要はない。特定のデバイス上で、要求の厳しい少数のゲームを改善できるなら、コミュニティツールには価値がある。しかし、ベンチマークを解釈する際には、このより限定的な基準を明確に保つべきだ。
だからこそ、ポータブルDLLは見出しとなる数値と同じくらい重要である。導入が容易になれば、実際の比較を行うコストが下がる。より多くのユーザーが同じバイナリをテストし、再現可能な結果を報告し、このトレードオフが有効なタイトルを特定できる。
ベンチマークがまだ立証していないこと
公開されたデータはアップスケーリングのディスパッチ高速化を示しているが、ゲーム全体で同等の画質や予測可能な性能向上をまだ立証してはいない。
最初の不確実性はテスト範囲にある。プロジェクトの文書によれば、記録された7本のゲーム検証は以前のRC7ビルドを使用していた。RC9には合成テストによる検証とCyberpunk 2077の導入済み構成があるが、ガイドはすべてのタイトルにわたる新たなRC9ゲームプレイ検証を主張していない。
この隔たりはベンチマークを無効にするものではない。合成テストはアップスケーラーを切り分け、変更前後の比較を容易にする。単に、ゲームベンチマークよりも狭い問いに答えるものだ。
完全な評価には、再現可能なシーンでの平均フレームレート、1パーセント低値、フレームタイムプロットが必要となる。また、同一の入力解像度と出力解像度を比較すべきだ。こうした統制がなければ、CPUの変動や無関係なレンダリング変更がDLLの効果を見えにくくする可能性がある。
2つ目の不確実性は視覚的な同等性に関するものだ。ベンチマークは、最適化されたパスがワークロードをより高速に処理することを示している。しかし、すべての出力ピクセルがAMDの元のパスと一致すること、またはゲームプレイ中の時間的挙動が変わらないことを独立して立証しているわけではない。
機械学習アップスケーラーは、シーン固有の形で破綻することがある。細かなジオメトリはちらつき、透明エフェクトは崩れ、パーティクルは軌跡を残し、新たに見えた表面には再構築エラーが現れる可能性がある。高速なカメラ移動では、静止キャプチャが隠してしまう問題が露出しやすい。
3つ目の問題はゲーム互換性である。OptiScalerはいくつかのインジェクションパスを提供するが、各ゲームは異なるAPIと時間的データを公開している。アンチチートシステム、ランチャー、アップデート、レンダラーの変更により、本来は正しい導入でも動作しなくなることがある。
ネイティブのFidelityFX統合にも差異がある。ある文書化されたゲームでは特定の名前に変更したローダーライブラリが必要で、別のゲームではOptiScalerバックエンドを使用する。プロジェクトは、あるタイトル向けのファイル置換を無関係なゲームに適用しないよう明確に警告している。
4つ目の不確実性はプラットフォーム範囲だ。RC9はLinuxとProton上のBC-250ハードウェアを対象としている。ガイドはネイティブWindowsやほかのGPUのサポートを約束していない。ポータブルDLLは移動しやすいが、ファイルの可搬性が最適化された挙動の可搬性を証明するわけではない。
実装は署名されていないサードパーティー製ソフトウェアでもある。ユーザーは指定されたリリースから入手し、チェックサムを検証し、置き換えるファイルのバックアップを保持すべきだ。ゲームアップデートによってライブラリが上書きされたり、ロールバックを要する互換性問題が生じたりする可能性がある。
より広範なRDNA 2への影響は、特に不確実なままである。BC-250は特定の命令挙動を持つ特殊なGFX1013プロセッサを使用している。このデバイスに有効な回避策から、Radeon RX 6000カード、Steam Deckハードウェア、コンソール用プロセッサにおける性能を自動的に予測することはできない。
報告されたベンチマークも、小規模なモッディング・エコシステムを通じて伝えられたものだ。異なるボード、クロック、ファームウェアバージョン、熱条件にわたり、独立した再現検証によって数値を確認する必要がある。
持続的なシェーダーワークロードは短時間のテストとは異なる挙動を示す可能性があるため、熱にも注意を払うべきだ。冷却が不十分なボードでは、長時間のプレイ後にクロック速度が低下することがある。その結果、短い合成テストで観測された性能上の恩恵が縮小、または見えなくなる可能性がある。
ボード個体差も別の複雑さを加える。一部のBC-250プロセッサはコアやコンピュートユニットのアンロックに耐えられる一方、ほかは標準構成でのみ安定する。ベンチマークでは、有効化されたハードウェア、クロック、電力制限、ファームウェア、Mesaバージョン、Protonビルドを明確に特定しなければならない。
これらの制約はいずれも、報告された短縮を消し去るものではない。現在の証拠が何を裏付けるかを定義するものだ。RC9は対象システムにおいてFSRディスパッチを大幅に高速化しているように見える一方、ゲーム全体での価値は依然として検証可能な主張にとどまる。
この慎重な解釈は、結果を普遍的なFSR 4サポートとして扱うよりもプロジェクトに資する。明確な境界は、ユーザーによる再現を助け、開発者がなおエンジニアリングを要する問題を特定する助けとなる。
RC9がBC-250ゲーミングを変えるかを示す3つのシグナル
次の段階では、合成テストの効率を、再現可能なゲームプレイ、視覚的安定性、保守可能な配布へと結び付けなければならない。
最初のシグナルは、統制されたRC9ゲームベンチマークスイートである。プロジェクトが両方の導入経路をすでに文書化しているため、Cyberpunk 2077とControlは妥当な出発点となる。テストでは、元のシェーダー、RC9、旧世代のアップスケーラーを同一設定下で比較すべきだ。
最も有用なレポートには、平均性能とフレームタイムのパーセンタイルが含まれる。分離したFSRコストとともに、完全なフレームタイムを記録すべきである。RC9がGPUボトルネックのシーンで一貫した向上を生むなら、現在のメカニズムに基づく結論は大幅に強化される。
ゲーム全体の性能がほとんど変わらない場合でも、ベンチマークは開発者に何かを教える。それは、レンダリングパイプラインの別の部分が支配的であることを示すだろう。この最適化は、特定のゲームを実質的に改善しなくても、技術的には有効であり続けられる。
2つ目のシグナルは、独立した画質検証である。ユーザーは動き、細かなジオメトリ、パーティクル、反射、インターフェース要素、ディスオクルージョンされた表面をキャプチャすべきだ。比較には、無関係なスクリーンショットではなく、同一のカメラ経路と入力解像度が必要となる。
元の出力との安定した一致が確認されれば、RC9がはるかに低いコストでほぼ同等の再構築を提供するという主張は強まる。タイミング上の優位が残っていても、ゴースティングやちらつきが繰り返し発生すれば、実用面での根拠は弱まる。
3つ目のシグナルは、保守されたLinuxパッケージと導入ツールを通じた採用である。DLLはすでにカスタムMesaビルドへの依存を減らしている。BC-250ディストリビューション、Protonワークフロー、チェックサム固定パッケージへの継続的な統合により、テストの再現性はさらに高まる。
あるLinuxプロジェクトはすでに、このフォークを実験的なOptiScalerオプションとして公開しつつ、署名されていないビルドは推奨ではないと警告している。この位置付けは適切だ。再現可能なパッケージ化は、実験的ソフトウェアを公式サポートに変えることなく、より安全にできる。
ゲーム、Proton、ドライバーのアップデート後の保守状況は、可搬性が実使用に耐えるかを明らかにする。頻繁に壊れる置換ライブラリには隠れたコストがある。明確なロールバック手順を備えた安定したパッケージであれば、この最適化を実用的なインフラへ変えられる。
AMDの対応は当面それほど重要ではないが、公式サポートは引き続き注視する価値がある。同社はFSR開発とサポート対象のRadeonパスを管理している。コミュニティの発見は需要を示す可能性があるものの、AMDがこのマイニング由来プロセッサをサポートする保証にはならない。
BC-250所有者にとって、次の合理的なステップは慎重な実験である。リリースファイルを検証し、元のライブラリを保存し、レンダリングされたウォーターマークを確認し、再現可能なシーンをベンチマークする。残るオーバーヘッドに価値があるかを判断する前に、視覚的な挙動を比較すべきだ。
グラフィックス開発者にとって、このプロジェクトはソフトウェア上の前提についてより広い教訓を与える。新しい整数ハードウェアを前提に設計されたモデルは、必要な命令を実行できる場合でも、特殊なプロセッサでは十分に機能しないことがある。標的を絞ったシェーダー作業により、汎用パスが活用していない性能を回復できる。
したがって、AMD BC-250 FSR 4の結果が有望なのは明確な理由による。特殊なドライバー実験をポータブルパッケージに変え、測定されたワークロードをほぼ半減させたからだ。普遍的なサポートや、保証されたフレームレート向上を立証したわけではない。
決定的な証拠は、別の孤立した数値ではなく、通常のゲームからもたらされるべきだ。RC9は、要求の厳しいシーンで安定した再構築ディテールを維持しながら、フレームペーシングを改善するのか。この問いに対する再現可能な答えが、このDLLがBC-250ゲーミングの恒久的な一部となるのか、それとも印象的な技術デモにとどまるのかを決める。
