AMDのDGFSがゲームアセットを最大22%圧縮。対応・非対応GPUを1つの資産で 賄う新形式

ゲームアセットの肥大化は、次世代エンジン開発の足かせになりつつある。レイトレーシングや高密度メッシュで表現力は上がるが、配布容量とストリーミング帯域も同じだけ膨らむ。AMDがAMD DGF SDK 1.2に追加した新機能DGFS（DGF SuperCompression）は、この圧迫を最大22%の容量削減で和らげる狙いだ。圧縮対象は同社のDGF（Dense Geometry Format）ブロック群で、DGF対応GPUにも非対応GPUにも単一の保存形式から戻せる。1つの配布資産で複数世代のGPUを狙えるため、ビルド・検証・配信パッケージの管理にもそのまま大きな効果をもたらしてくれるのだ。

128バイトブロックが保存形式には重くなる理由

DGF（Dense Geometry Format）は、高密度メッシュをハードウェアが効率よく参照するためのジオメトリ圧縮形式だ。各三角形に必要な情報は、単一の128Bアライン済みメモリ読み出しで一度に取り出せる。この性質はレイトレーシング時のトラバーサルでは強みになる。半面、ファイルとして保存する局面では、頂点位置や圧縮パラメータをブロックをまたいで重複保存する負荷が生じる。DGFS（DGF SuperCompression）は、そのDGFデータをさらに小さく保管するためのソフトウェア圧縮層だ。

現行のレイトレーシングAPIは、アプリケーションが中立的な入力形式を渡し、ドライバがハードウェア固有のアクセラレーション構造へ変換する「ブラックボックス」型で組まれている。AMDはこの方式に3つのボトルネックを挙げる。最悪ケースの圧縮率に合わせて確保せざるを得ない事前ビルド用メモリ、入力三角形順を再現するための情報保持、実行時の変換コストだ。DGFはこの3点を見直し、変換前のジオメトリを標準フォーマットとして圧縮する。テクスチャ圧縮でDXT、ETC、ASTCが担った役割を、ジオメトリ側で果たす発想だ。

DGFブロックはGPUに直接読ませるための形式であり、DGFSストリームはそのままハードウェアが消費する形式ではない。DGFSはディスクや配布パッケージ上で小さく保持され、実行時にはDGFブロックまたは通常の頂点・インデックスバッファへデコードされる。AMD自身はこの関係を、Basis UniversalがDXTなどのテクスチャ形式に対して果たす役割になぞらえる。DGFSはDGFの置き換えではなく、DGFを配布しやすくする上位の保存層という位置付けだ。

DGFSが削るデータと残すデータ

DGFSのバイトストリームは、最大256個のユニーク頂点と三角形から成るクラスターを可変長で符号化する。AMDはレンダリングエンジンがメッシュレットと呼ばれる小さな三角形クラスターを単位に、カリング、アニメーション、LOD（Level of Detail）、ジオメトリストリーミングを組み立てつつある点を重視している。DGFSもこの流れに合わせ、クラスター単位で圧縮とデコードを独立させる。局所的に処理できるため、ストリーミング中の段階的な読み込みにも合わせやすい。

DGFSのエンコーダーは、まずDGFブロック内の頂点をデコードし、クラスター全体で共通の符号化空間を作る。ブロック境界にある頂点は複数ブロックに重複して格納されやすいため、DGFSでは同じ位置を1つにまとめる。ユニークな頂点位置はデルタ化され、ジグザグ符号化とバイトインターリーブを経て、構造体配列ではなく配列群に近い形で並べられる。こうした前処理により、GDeflateのような汎用圧縮を重ねたときの圧縮率が上がる。

DGFSがDGFブロックを正確に復元するには、各ブロック内の頂点スロットがクラスター内のどの頂点を指すかを保存する必要がある。AMDはユニーク頂点を配列の前方に初出順で置き、共有頂点を後方に置く並べ方を採用している。各ブロック頂点には「ユニーク側か共有側か」を示す1ビットを持たせ、ユニーク頂点の番号はカウンターで進め、共有頂点の番号だけを直接保存する。共有頂点を配列の後ろから参照することで、頂点テーブルに書くインデックス値を小さくできる仕組みだ。

最大22.22%減という数字の読み方

AMDの測定では、未圧縮のDGFSストリームは元のDGFブロック群よりおおむね30%小さい。DragonモデルではDGFの29.25MBがDGFSで20.15MBになり、削減率は31.09%だった。Statuetteモデルでは40.99MBが29.31MBになり、削減率は28.48%と示されている。これはDGFS自体の構造が、DGFブロック間の重複を取り除く効果を持つためだ。

GDeflateを適用した後のディスク上サイズでは、AMDはDGFSがDGFよりおおむね20%小さいと説明している。公表表ではDragonが20.15MBから15.67MBへ縮み、削減率は22.22%だった。Crabは7.19MBから5.73MBで20.29%、Buddhaは3.35MBから2.63MBで21.34%となる。AMDが「最大22%」と表現する根拠は、このGDeflate適用後の比較にある。

DGFSの効果は、メモリ常駐サイズよりもゲーム資産の配布サイズやストレージ上の占有量で大きく効く。ゲームシナリオではDGFSデータをそのままメモリへ常駐させ続けるわけではなく、ロード時にDGFブロックや通常メッシュへ戻す前提だ。だからこそ重要になるのは、ディスク上の圧縮サイズだ。巨大なメッシュを頻繁にストリーミングするタイトルなら、ダウンロード容量と読み出し帯域の双方に効く。

DGF対応機と非対応機を同じ資産で扱う

DGFSストリームは、DGFブロック配列にも、従来型のインデックス付きメッシュにもデコードできる。DGF対応デバイスではDGFブロックへ戻し、非DGFデバイスでは頂点バッファとインデックスバッファ、あるいはメッシュレットとして扱う。この性質により、アプリケーションは1つの共通資産形式でDGFデバイスと非DGFデバイスを同時に狙える。保存形式は1つで、実行時の出力先だけを分けるという構図だ。

DGFとCLAS（Cluster-Level Acceleration Structures）はAMDの整理では競合する同種技術ではなく、直交し補完し合う関係にある。BLAS（Bottom-Level Acceleration Structure）は頂点・インデックス配列からもDGFブロック配列からも構築でき、CLASも同じ考え方をより小さな単位へ適用する。事前圧縮されたジオメトリは、BLASとCLASの双方に同じメリットを持ち込める。DGFは「CLASへの対抗策」ではなく、圧縮済みジオメトリを複数のアクセラレーション構造で使い回すための共通基盤だと捉えるのが妥当だろう。

デコード性能の測定環境はRyzen 9 7950X、64GB DDR5-6000 RAM、Radeon RX 9070 XT、Windows 11 2025 Updateで、単一CPUコアの結果が公開された。1000万三角形のStatuetteモデルは、メッシュレットへのデコードが0.15秒、DGFブロックへのデコードが0.22秒。722万三角形のDragonでは、それぞれ0.09秒と0.15秒だった。1コアで1秒未満ならストリーミングのインライン処理にも十分間に合う水準であり、GPUデコーダーへの拡張にも技術的な障害はない。

SDK 1.2で開発者が見るべき導入ポイント

AMD DGF SDK 1.2には、DGFSが新機能として追加された。エンジン開発者が最初に確認すべき点は、既存のメッシュレット生成、LOD、ストリーミング単位がDGFSのクラスター単位とどの程度そろうかである。DGFSは各クラスターを独立に圧縮・デコードするため、資産パイプライン側の分割粒度と合えば扱いやすい。逆に、クラスター境界が既存ツールチェーンと大きくずれる場合は、ビルド時の変換工程を見直す必要が出る。

DGFブロックの正確な復元が必要なパスでは、DGFSからDGFブロックへデコードする流れを取る。DGFを直接扱わないGPUや、従来の描画パスを残す環境では、同じDGFS資産から通常の頂点・インデックス表現へ戻せばよい。AMDは現時点で、特定のGPU世代にDGFSの利用を絞り込む記述を公開していない。性能測定こそRadeon RX 9070 XTの環境で行われたが、これは数値取得のための構成であり、対応GPUの線引きを示すものではない。導入を検討する側は、測定構成と正式な対応リストを分けて確認するのが安全だ。

最大22%のファイル削減という数字に目が行きがちだが、本当の効きどころはおそらくその先にある。DGF向けと非DGF向けで資産を2系統に分けずに済めば、ビルド時間も検証対象も配布パッケージも一本化できる。DGFがGPUのための密な実行形式、DGFSが配布と互換性のための圧縮形式という役割分担として整理すれば、導入判断の軸はかなり単純化する。高密度ジオメトリを前提にした次世代エンジンにとって、ストレージ・ストリーミング・ハードウェア対応をひとつのフォーマットで束ねられるかどうかは、想像以上に大きな分岐になりそうだ。