Microsoftは2026年10月28日、DirectX Raytracing（DXR）の新機能を「Agility SDK 1.722.0-preview」で公開した。公式サンプルでは、レイトレーシングで光線と物体の交差判定を高速化するためのデータ構造「加速構造（Acceleration Structure：AS）」の容量が、従来の7,519MiBから774MiBへと89.7%減少した。ただし、これは完成した加速構造の容量を比較した結果であり、ゲーム全体のVRAM使用量が同じ割合で減ることを意味するものではない。
実際のVRAM使用量を評価するには、完成した加速構造の容量だけでなく、それを構築する際に必要となる一時的な作業領域も考慮する必要がある。さらに、構築したデータをメモリー上にどのように配置するかによっても、必要な容量や処理時間は変わってくる。今回の89.7%という削減率が実際のゲームにどの程度の効果をもたらすのかを判断するには、これらを区別して検証することが重要だ。
89.7%削減されたのは完成後の加速構造の容量
Microsoftが公開したD3D12 Clustered Geometryの公式サンプル比較では、同じシーンを従来方式と新しいクラスタ方式で処理し、加速構造の容量や処理時間を測定している。従来方式では物体の形状を扱う加速構造を再構築するのに対し、クラスタ方式では形状を小さな単位に分割して管理する。テストにはAMD Radeon RX 9070が使用されており、サンプルでは構築方法やメモリー配置、頂点データの形式などを変更して比較できる。
公式に公表されたメモリー使用量を、完成した加速構造と構築時の作業領域に分けると、以下のようになる。単位はいずれもMiBである。
| 指標 | 従来方式 | クラスタ方式 | 測定対象 |
|---|---|---|---|
| 完成AS合計 | 7,519 | 774 | TLASを含む完成後の加速構造の総容量 |
| 静的AS | 723 | 527 | 静的な形状を扱う加速構造の容量 |
| アニメーションAS | 6,794 | 244 | 動く形状を扱う加速構造の容量 |
| 静的な形状の作業用メモリー | 1.83 | 526 | 静的な形状の構築に必要な一時領域 |
| 動く形状の作業用メモリー | 8.25 | 179 | 動く形状の構築に必要な一時領域 |
※数値はMicrosoftの公式比較結果に基づく。完成ASと作業用メモリーは異なる指標であり、合計値には公式発表の数値を使用している。
完成ASの容量は7,519MiBから774MiBへと減少しており、従来方式を基準とした削減率は約89.7%となる。ただし、この割合はあくまで完成した加速構造の容量に対するものであり、ゲーム全体のVRAM使用量や、グラフィックボードに搭載されたVRAM容量を基準としたものではない。一方、構築時に必要な作業用メモリーは、静的な形状と動く形状のいずれもクラスタ方式で増加している。もっとも、これらの数値を単純に合計して構築中の最大使用量を求めることもできない。各領域を同時に確保するのか、処理が終わった領域を再利用するのかが、公表された表からは分からないためだ。
米技術メディアのHotHardwareも10月31日付の記事で、VRAM使用量を最大約9割削減できる可能性があると紹介している。ただし、記事で取り上げられた89.7%という数値は加速構造の容量削減率であり、独立した検証によってゲーム全体のVRAM削減効果が確認されたわけではない。Microsoft自身も、公式サンプルについて、実際のゲームで同規模の改善が得られるとは考えないよう注意を促している。
小さな加速構造を共有し、必要な部分だけを更新
従来のDXRでは、物体の形状を管理するBLAS（Bottom-Level Acceleration Structure）と、シーン内における物体の配置を管理するTLAS（Top-Level Acceleration Structure）を組み合わせてレイトレーシングを処理している。今回導入された「Clustered Geometry（クラスタ化ジオメトリ）」は、形状を小さな単位に分割し、それぞれの加速構造であるCLAS（Cluster Acceleration Structure）を複数のCluster BLASで共有できるようにする仕組みだ。TLASがBLASを参照するという基本的な階層構造は維持される。
従来のように大きな加速構造をまとめて再構築する代わりに、より小さな単位で管理し、必要に応じて共有できる点が特徴となる。これにより、同じ形状データを重複して保持する負担を減らせる可能性がある。ただし、今回の89.7%という削減率について、CLASの共有など個々の仕組みがそれぞれどの程度寄与したのかは公表されていない。そのため、削減効果の内訳を特定することはできない。
もう一つの新機能が「Partitioned TLAS（PTLAS：分割型TLAS）」だ。これはシーン内の配置情報を複数の領域に分割し、変更されていない部分を保持しながら、必要な領域だけを更新できるようにする仕組みである。シーンの一部が変化するたびに全体を更新する必要性を減らせるため、特に動的なシーンで処理負担の軽減が期待される。
ただし、更新するデータの量が減っても、必要なメモリー容量が同じ割合で減るとは限らない。PTLASを既存のメモリー領域内で更新する場合、確保する領域の大きさは、あらかじめ宣言されたインスタンス数や分割領域数に基づいて決まるためだ。実際に変更されたインスタンス数だけで必要容量が決まるわけではなく、更新処理の効率化とメモリー使用量の削減は分けて評価する必要がある。
メモリー配置方法によって容量と処理時間が変わる
加速構造のメモリー効率を左右するもう一つの要素が、構築したデータの配置方法だ。ここでいう配置とは、構築された加速構造をバッファー内のどのアドレスに格納するかを指す。DirectXの公式仕様書では、「Implicit vs explicit destinations for acceleration structure operations」の節で、配置先アドレスの決定方法による違いが説明されている。
「暗黙配置（Implicit Destination）」では、アプリケーションが出力用のバッファーをまとめて確保し、その内部で各加速構造を配置するアドレスをドライバーが決定する。ただし、事前に算出される必要容量は余裕を持った見積もりとなるため、実際の完成サイズに対して多めのメモリーを確保する場合がある。また、加速構造を隙間なく配置できるとは限らず、完成したデータの容量が小さくても、確保したバッファー全体の容量が同じだけ小さくなるとは限らない。
これに対して「明示配置（Explicit Destination）」では、アプリケーションが各加速構造の配置先アドレスを指定する。GET_SIZES操作で構築結果のサイズを事前に調べ、その情報に基づいてメモリーを割り当てられるため、不要な領域を抑えられる可能性がある。また、暗黙配置で構築した後に実際の完成サイズを取得し、加速構造を移動して隙間なく並べ直す方法も用意されている。
各配置方式の特徴を整理すると、次のようになる。これらはDirectXの仕様に基づく比較であり、先ほどの公式サンプルで測定されたメモリー使用量とは別のものだ。
| 配置方法 | メモリーの確保・配置 | メモリー使用量への影響 | 処理時間への影響 |
|---|---|---|---|
| 暗黙配置 | 出力用バッファー内の配置先をドライバーが決定 | 保守的な見積もりによって余分な領域や隙間が生じる場合がある | 速度面の優劣は実装や条件によって異なる |
| 明示配置 | 各構造のサイズを事前に調べ、アプリケーションが配置先を指定 | 暗黙配置より最大使用量を抑えられる場合がある | サイズ算出と構築で計算が重複し、処理時間が増える場合がある |
| 暗黙配置後の移動 | 完成サイズに合わせて加速構造を再配置 | 構造を最も密に配置できるが、移動用の一時領域が必要になる場合がある | 構築後にデータを移動する処理が加わる |
明示配置では、必要な容量を事前に把握することでメモリーの割り当てを効率化できる一方、サイズの算出と実際の構築で計算が重複し、処理時間が増える可能性がある。暗黙配置後にデータを移動する方法でも、完成した加速構造を隙間なく並べられる反面、移動のための一時バッファーが必要になる場合がある。つまり、最終的なメモリー使用量を最小化できる方法が、構築中の最大使用量や処理時間の面でも最適とは限らない。実装時には、メモリー効率と処理速度の両方を測定する必要がある。
なお、これらの配置方式の違いは、今回の公式サンプルで89.7%の容量削減がどのように達成されたかを説明するものではない。サンプルで採用された配置方法や、配置方式ごとの削減効果は、この比較結果からは特定できない。仕様書が明らかにしているのは、開発者が選択できる配置方法と、それぞれに伴うメモリー容量や処理時間のトレードオフである。
実際のゲームではVRAMの最大使用量と処理速度が重要
今回の新機能が実際のゲームでどれほどVRAM使用量を減らせるかを判断するには、完成後の加速構造の容量に加え、構築中に必要となるメモリーの最大使用量を測定する必要がある。作業用メモリーの個別の数値だけでは、それぞれの領域が同時に使われる時間や、処理中に再利用される範囲までは分からない。さらに、配置方法によっても最大使用量は変化し得るため、同じシーンや負荷条件の下で比較することが重要だ。
処理速度についても、加速構造の構築とレイトレーシングの実行を分けて評価する必要がある。Microsoftの公式サンプルでは、加速構造の準備・構築にかかる時間が788msから3.11msへ、GPUによるレイトレーシング処理時間が72.6msから9.27msへと短縮された。ただし、前者は光線追跡に必要なデータ構造を用意する時間であり、後者は完成した構造を使って光線を追跡する時間を指す。両者は異なる処理であるため、実際のゲームにおける性能向上を判断するには、それぞれの変化を確認する必要がある。
今回の新機能は、現時点ではプレビューとして提供されている。利用にはAgility SDK 1.722.0-previewに対応したランタイムとヘッダー、対応ドライバーに加え、Windowsの開発者モードとShader Model 6.10のプレビュー環境が必要だ。新しいハードウェア機能は要求されないものの、GPU世代ごとの対応や実装の検証は各ベンダーに依存し、実際のゲームで利用するには開発者による組み込みも必要となる。
今回示された89.7%という容量削減率だけで、VRAMが8GBのグラフィックボードでも特定のゲームを快適に動かせるようになるとは判断できない。今後、実際のゲームにおいて配置方式ごとのVRAM最大使用量や加速構造の構築時間、レイトレーシング性能が検証されれば、新機能がどのような条件で効果を発揮するのかが明確になるだろう。開発者にとっては、メモリー容量の節約と処理速度のバランスを踏まえ、各ゲームのシーンに適した実装を選べるかどうかが重要となる。
