Microsoft、DirectX 12のレイトレーシングを大幅刷新：BVH構築時間が約254分の1に短縮

リアルタイムレイトレーシングをゲームエンジンに組み込む際、大きな課題となるのが、光線の交差判定に使う階層構造の構築コストだ。キャラクターの変形やオブジェクトの移動に合わせて、境界体積階層（BVH）と呼ばれるデータ構造を更新しなければならない。従来の手法では、形状の変化によって大規模な再構築が必要になる場合があり、GPUの計算時間やメモリ帯域を圧迫していた。特に、動的なオブジェクトが多いシーンや広大なオープンワールドでは、この処理が性能上のボトルネックになりやすい。

Microsoftは2026年10月28日、DirectX 12向けの開発キット「Agility SDK 1.722-preview」を公開した。今回導入されたのは、ジオメトリを小さな単位に分割して再利用する「Clustered Geometry」、シーン全体のアクセラレーション構造を部分的に更新する「Partitioned TLAS（PTLAS）」、そしてGPU上のデータに基づいて構築処理を実行する間接ビルドAPIだ。Microsoftはこれらの機能を、2018年にDirectX Raytracing（DXR）を導入して以来、最も重要な進展と位置づけている。

新機能は、レイトレーシング対応GPUに新たな専用回路や命令セットを要求するものではない。既存のハードウェア機能を活用しながら、データ構造の分割や再利用、GPU主導の処理によって構築コストを削減する設計となっている。ただし、実際の利用には対応ドライバなどが必要であり、既存のレイトレーシング対応GPUすべてで直ちに動作するわけではない。また、Microsoftが公開した大幅な性能改善は特定のテスト環境で得られた結果であり、あらゆるゲームが同じ割合で高速化されることを意味しない。

BVH全体の再構築を減らす、2段階のアプローチ

従来のレイトレーシングでは、形状データを2階層のBVHで管理してきた。個々のメッシュ形状を管理するボトムレベルのアクセラレーション構造（BLAS）と、それらをシーン内に配置した複数のインスタンスをまとめるトップレベルのアクセラレーション構造（TLAS）だ。キャラクターの頂点変形や詳細度（LOD）の切り替え、ストリーミングによる新しい形状の読み込みが発生すると、関連するBLASを三角形ポリゴンから再構築するか、既存の階層構造を更新する「リフィット」処理が必要になる。しかし、メッシュの接続関係を表すトポロジーが変化する場合、リフィットだけでは対応できず、構造全体の再構築が大きな負担となっていた。

今回のプレビューでは、オブジェクト内部のジオメトリとシーン全体の配置という2つの階層で、この問題に対処する。具体的には、以下の3つの技術を組み合わせて構築処理を効率化する。

1. Clustered Geometry： オブジェクト内部のジオメトリを最大256頂点・256三角形からなる小さなクラスタに分割し、クラスタ単位でBVHを構築・再利用する。
2. Partitioned TLAS（PTLAS）： シーン全体のTLASを空間的なパーティションに分割し、変更のない領域の構造を維持しながら、必要な部分だけを更新する。
3. Indirect RTAS Operation API： GPUメモリ上に用意した引数を使ってアクセラレーション構造の構築処理を実行し、コンピュートシェーダーとの連携や複数処理の一括実行を可能にする。

間接ビルドAPIによって、CPUが毎フレーム個別の構築コマンドを細かく発行する負担を軽減できる。アプリケーションはまず、GetRTASOperationPrebuildInfo() を呼び出し、構築時に必要な一時作業領域（スクラッチバッファ）や出力領域のメモリサイズを確認する。その後、GPUメモリ上に配置した引数配列を ExecuteIndirectRTASOperations() から参照し、複数の構築処理をまとめて実行する。

ただし、このAPIには重要な制約がある。1回の ExecuteIndirectRTASOperations() 呼び出しに含まれる複数の処理は、GPU内部で実行順序が保証されず、並列に処理される可能性がある。そのため、クラスタの生成、クラスタを参照するBLASの構築、PTLASへの登録というように、前の処理結果を次の処理が利用する場合は、呼び出しを分けて適切なGPUリソースバリアを挟まなければならない。Clustered GeometryとPTLASはそれぞれ独立して利用することも、組み合わせることも可能だが、既存のコードをわずかに変更するだけで導入できるものではない。効果を十分に引き出すには、ゲームエンジンのレイトレーシングパイプラインを見直す必要がある。

{
  "type": "bar",
  "title": "RX 9070環境におけるBLAS構築とレイトレーシング時間",
  "unit": "ms",
  "categories": ["従来型BLAS再構築", "Clustered Geometry"],
  "series": [
    { "name": "AS準備・構築時間", "values": [788.0, 3.11] },
    { "name": "レイトレーシング処理時間", "values": [72.6, 9.27] }
  ],
  "caption": "Microsoft公式サンプル（D3D12RaytracingClusteredGeometry）での計測値",
  "source": "Microsoft DevBlogs (2026-10-28)"
}

Microsoftの公式サンプルでは、アクセラレーション構造の構築時間が大幅に短縮され、フレームレートも大きく改善している。ただし、これはClustered Geometryに適した特定の条件で得られた結果であり、実際のゲームで同じ効果が得られるとは限らない。また、この性能を引き出すには、クラスタの生成・更新・破棄に関する規則や、シェーダーでのジオメトリ識別方法を正しく扱う必要がある。

最大256頂点・256三角形のクラスタを再利用する仕組み

Clustered Geometryの基本単位となるのが、「Cluster Level Acceleration Structure（CLAS）」だ。1つのCLASは、インデックス付きメッシュとして最大256個の三角形と256個の頂点を保持する。アプリケーションはまず個々のCLASを構築し、それらの参照をまとめて「Cluster BLAS」を作成する。さらに、そのCluster BLASをTLASやPTLASのインスタンスとしてシーン内に配置する。

この仕組みの大きな利点は、CLASを複数のCluster BLASで共有できることだ。たとえば、ゲーム内で新しい地形やオブジェクトを読み込む際や、LODを段階的に切り替える際に、既存のクラスタを再利用して新しいBLASを構築できる。近年のゲームエンジンでは、メッシュを小さな三角形グループに分割する「メッシュレット」が利用されており、こうしたデータ構造を採用している場合、既存の分割結果をCLASの入力として活用しやすい。

ただし、クラスタの共有には厳格なメモリ管理が求められる。Cluster BLASはCLASのデータ本体を内部に保持するのではなく、メモリ上の参照先を指す構造になっている。そのため、参照先のCLASで頂点座標が書き換えられたり、メモリ上のアドレスが変更されたりすると、それを参照しているCluster BLASは無効になる。この場合、参照関係を修正するためにCluster BLASを再構築し、必要に応じて上位のアクセラレーション構造も更新しなければならない。

また、同じCluster BLASに属するCLASは、すべて共通のオブジェクトローカル座標系に配置される。個々のCLASを構築する段階で、クラスタごとに独立した変換行列を適用する仕組みはない。したがって、複数のCLASを1つのBLASにまとめる際には、それぞれの頂点座標が共通の座標系に従っている必要がある。

アニメーションやプロシージャル生成によってメッシュが変形する場合も、従来とは異なる方法で更新する。Clustered Geometryには、既存の階層構造を維持したまま頂点位置だけを更新するリフィット処理が用意されていない。その代わりに導入されたのが「Cluster Template」だ。これは、クラスタのトポロジーや頂点の接続関係など、頂点位置に依存しない構築処理の結果を事前に保持する仕組みである。

Cluster Template自体を光線の交差判定に直接使用することはできないが、コンピュートシェーダーなどで生成した最新の頂点座標を与えることで、CLASを効率よく構築できる。たとえば、キャラクターのアニメーションでメッシュが大きく変形しても、トポロジーが変わらなければ、毎フレームその構造を最初から解析する必要はない。事前に計算した情報を再利用することで、最新の頂点位置に対応したCLASを少ない計算量で生成できる。

シェーダーがジオメトリの属性を取得する方法にも変更がある。従来のレイトレーシングパイプラインでは、BLAS全体で一意のプリミティブインデックスを利用できたが、Clustered Geometryにおける PrimitiveIndex() は、所属するCLAS内のローカルな三角形番号（0〜255）を返す。そのため、ヒットシェーダーで三角形ごとの法線やマテリアル情報を取得する際には、アプリケーションが割り当てた32ビットの ClusterID() と PrimitiveIndex() を組み合わせて識別する必要がある。既存のプリミティブインデックスを前提とするシェーダーでは、この点を修正しなければならない。

Shader Model 6.10では、TriangleObjectPositions() などの組み込み関数への対応も重要になる。対応する設定を有効にしておけば、アクセラレーション構造から三角形の頂点座標をオブジェクト空間で直接取得できる。これにより、別途用意した頂点バッファをVRAMから読み出す処理を省略でき、法線計算などのシェーダー処理を効率化できる。

頂点座標の保存形式も拡張された。通常の浮動小数点形式や正規化整数形式に加え、仮数部の下位ビットを切り捨てる量子化や、「COMPRESSED1」と呼ばれる固定小数点圧縮を利用できる。COMPRESSED1では、クラスタごとに共通のアンカー座標と2のべき乗のスケールを設定し、各頂点の位置をそこからの相対オフセットとしてパックされた整数値で保持する。こうした圧縮によって、ジオメトリデータに必要なメモリ容量を削減できる。

ただし、クラスタの作り方によっては、逆にレイトレーシング性能が低下する可能性もある。DirectXの仕様書では、クラスタを構成する三角形同士が空間的に近い位置に集まるように分割することを推奨している。離れた場所にある三角形を同じクラスタにまとめてしまうと、光線の交差判定時に不要なバウンディングボックスまで調べる必要が生じる。つまり、クラスタ化によって構築時間を短縮できても、その分割方法が適切でなければ、BVHの走査（トラバーサル）にかかる時間が増えてしまう。

PTLASはシーン全体を分割し、変化した領域だけを更新する

シーン全体のアクセラレーション構造を効率化するのが「Partitioned TLAS（PTLAS）」だ。従来のTLASを拡張した仕組みで、通常のBLASと新しいCluster BLASの両方を扱える。最大の特徴は、シーンを複数の空間領域（パーティション）に分割し、変更が発生した部分だけを更新できることにある。

広大なオープンワールドでは、建物や地形など、多くのオブジェクトが長時間にわたって同じ位置にとどまる。従来のTLASでは、シーン内の一部に変更が生じた場合でも、更新処理の対象が広範囲に及ぶことがあった。PTLASでは、変化のないパーティションの階層構造を再利用し、更新が必要な領域だけを再構築する。この仕組みにより、広大なシーンを維持しながら、動的なオブジェクトの更新に伴う負荷を抑えられる。

一方、頻繁に移動するオブジェクト向けには、「Global Partition」という特別な仕組みが用意されている。ここに登録されたインスタンスは、構築時やトラバーサル時に、それぞれが独立したパーティションであるかのように扱われる。これにより、一部のオブジェクトが激しく移動しても、その周囲にある多数の静的オブジェクトを含むパーティション全体を毎フレーム再構築せずに済む。動きが止まったオブジェクトは、通常の空間パーティションに戻すこともできる。

PTLASでは、更新する内容に応じて3種類のオペレーションを使い分ける。

重要なのは、UPDATE_INSTANCE ではオブジェクトの位置を変更できないことだ。トランスフォームを更新する場合は、WRITE_INSTANCE を使用する必要がある。変更のあったインスタンスだけをコンピュートシェーダーで抽出し、そのリストに基づいて更新処理を実行すれば、変化していないインスタンスへの不要な書き込みを避けられる。変更箇所が少ないシーンほど、こうした差分更新の効果が期待できる。

ただし、PTLASの性能はパーティションの分割方法に大きく左右される。複数のパーティションが空間的に大きく重複していると、光線が通過する際に複数のバウンディングボックスを調べる必要があり、トラバーサルの計算量が増える。また、Global Partitionを過度に使用すると、再構築の負担を抑えられる一方で、トップレベルでの交差判定対象が増加する。したがって、構築時間の削減だけを優先するのではなく、光線の走査効率も考慮してパーティションを設計する必要がある。

メモリ管理にも制約がある。PTLASを既存のメモリ領域内で更新するインプレース更新では、事前に宣言したインスタンス容量とパーティション容量に対応するバッファを確保し続けなければならない。実際に変更するインスタンスが少なくても、予約済みのメモリ領域をその分だけ縮小できるわけではない。このため、差分更新で計算量を減らすことと、メモリ使用量を最小化することは、必ずしも両立しない。

導入に必要な環境とGPUメーカー各社の対応状況

今回のAgility SDKプレビューは、DirectX 12に対応するすべてのPCですぐに利用できるわけではない。検証するには、指定されたランタイムやコンパイラに加え、各GPUメーカーが用意した対応ドライバが必要となる。開発環境では、次の条件を満たす必要がある。

• Agility SDK： 1.722.0-previewのヘッダーとランタイムを使用する。
• DirectX Shader Compiler（DXC）： Shader Model 6.10に対応したプレビュー版「Patch 2 v1.10.2605.37」を使用する。
• Windowsの設定： 開発者モードを有効にし、デバイスを生成する前に D3D12ExperimentalShaderModels と D3D12RaytracingPreview の実験的機能を有効化する。
• レイトレーシングパイプライン： Cluster BLASを使用する場合は、D3D12_RAYTRACING_PIPELINE_FLAG_ALLOW_CLUSTERED_GEOMETRY を明示的に指定する。インラインレイトレーシングでは、対応するRayQueryフラグを使用する。

Microsoftは、新機能の利用にレイトレーシング以外の新しいハードウェア機能は必要ないと説明している。ただし、これは過去のすべてのレイトレーシング対応GPUで、同じ機能を直ちに利用できるという意味ではない。実際の対応範囲は、各メーカーによるドライバの開発・検証状況や、対象GPUで十分な性能が得られるかどうかによって決まる。

2026年10月末時点で公表されている各メーカーの対応状況は、次の通りだ。

• NVIDIA： 「Game Ready Driver 621.01」により、GeForce RTXシリーズの全世代でClustered GeometryとPTLASのプレビューに対応する。
• AMD： Radeon RX 9000シリーズ向けに、Agility SDKプレビュー対応ドライバ「RN-RAD-MS-AGILITY-SDK-26-20-12-01」を公開した。
• Intel： ディスクリートGPUの「Intel Arc B-Series Graphics」と、統合GPUを備える「Core Ultraプロセッサー（200VシリーズおよびSeries 3）」向けに、対応ドライバ「931698」を公開した。
• Qualcomm： Snapdragon X2プラットフォームでの対応を開発中で、ドライバの提供開始目標を2027年第1〜第2四半期としている。

アプリケーション側でも、実行環境が新機能に対応しているか確認する必要がある。具体的には、ID3D12Device16 インターフェースを通じて CheckFeatureSupport1 を呼び出し、ClustersAndPTLASSupported フラグが有効であることを確認する。対応していない環境では、従来のBLASとTLASを使う処理に切り替えるフォールバックが必要だ。新しいAPIを採用する場合も、幅広いGPUでゲームを動作させるには、既存のレイトレーシングパイプラインを維持しなければならない。

構築時間は約254分の1に短縮、ただし一時メモリは大幅増

Microsoftが公開したサンプル「D3D12RaytracingClusteredGeometry」では、Clustered Geometryによる大幅な性能改善が報告されている。検証にはAMDのRadeon RX 9070を使用し、静的なジオメトリと変形する球体メッシュを大量に配置したテストシーンで測定を行った。これは技術検証用に作成された簡易的なシーンであり、一般的な商用ゲームの負荷を再現したものではない。

この環境で従来型のBLASを毎フレーム三角形データから再構築した場合、フレームレートはわずか1.2 FPSだった。一方、Clustered Geometryを使用すると79 FPSに達し、約66倍に向上した。特に大きく改善したのがアクセラレーション構造の準備・構築時間で、従来の788ミリ秒から3.11ミリ秒へと、約254分の1に短縮されている。さらに、静的メッシュとアニメーションメッシュを合わせたアクセラレーション構造の保持メモリ容量も、7,519 MiBから774 MiBへと約89.7%減少した。

ただし、Microsoftはこの結果を商用ゲームで期待できる性能向上幅として解釈しないよう注意を促している。今回のテストは、Clustered Geometryが特に効果を発揮しやすく、従来型のBLAS再構築には非常に大きな負荷がかかる条件で実施された。実際のゲームでは、メッシュの構成やアニメーション、シェーダー処理、その他の描画負荷によってボトルネックが変わるため、同じ改善率が得られるとは限らない。

また、構築時間や保持メモリ容量が大幅に減少した一方で、構築時に必要な一時作業領域であるスクラッチメモリは増加している。Microsoftのサンプルで示された主要な測定結果をまとめると、次のようになる。

出典：Microsoft DevBlogs（2026年10月28日）、D3D12RaytracingClusteredGeometry公式サンプル

注目すべきなのは、静的メッシュの構築用スクラッチバッファが1.83 MiBから526 MiBへと約287倍に増加した点だ。アニメーション用のスクラッチバッファも8.25 MiBから179 MiBへと約21.7倍になっている。完成したアクセラレーション構造の保持メモリ容量は大幅に減るものの、構築処理を実行する際には、従来よりも大きな一時領域が必要になる。GPUメモリの使用量が厳しく制限されるゲームエンジンでは、こうしたスクラッチバッファの確保方法が新たな課題になり得る。

シーン全体を管理するPTLASについても、構築時間の短縮とトラバーサル性能の間にトレードオフがある。Microsoftの「D3D12RaytracingPartitionedTLAS」サンプルでは、4,702個のドミノが倒れるシーンを使って性能を測定した。その結果、従来のTLASを全体再構築した場合に2.88ミリ秒かかっていた更新処理が、PTLASでは0.79ミリ秒に短縮された。一方、更新後のレイトレーシング処理にかかる時間は、従来のTLASよりもわずかに長くなったという。

これは、パーティション分割によって階層構造が必ずしも交差判定に最適な形にならず、光線が調べるべき領域が増える場合があるためだ。PTLASは更新対象を絞ることで構築負荷を減らせるものの、トラバーサル自体を常に高速化する技術ではない。実際のフレーム時間を短縮するには、構築処理で削減できた時間が、走査処理で増加した時間を上回る必要がある。

関連技術を採用した先行事例としては、『Gears of War: E-Day』が挙げられる。同作ではクラスタ化したジオメトリをレイトレーシングに利用しているが、採用しているのはNVIDIAが独自に提供する「RTX Mega Geometry」APIだ。今回発表されたDirectXの標準APIを採用した実績ではないため、両者は区別する必要がある。

また、NVIDIAは25平方キロメートルの森林シーンに6,000万本の植物を配置した「dx12_forest_ray_tracing」デモも公開している。ただし、こちらも開発中の技術を示すデモであり、市販ゲームの実際のプレイ環境で測定された性能データではない。これらの事例はクラスタ化によるレイトレーシングの可能性を示すものだが、DirectXの新APIが実際のゲームでどの程度の改善をもたらすかを判断するには、さらなる検証が必要となる。

今回のDirectX 12の拡張は、動的なジオメトリや大規模なシーンで負担となっていたBVHの再構築を、クラスタの再利用とGPU主導の差分更新によって効率化するものだ。特定のサンプルで示された構築時間の大幅な短縮は有望だが、実用化に向けてはスクラッチメモリの管理、空間パーティションの設計、トラバーサル性能の最適化が欠かせない。今後、各GPUメーカーの対応ドライバが整備され、実際のゲームエンジンでの検証が進むことで、この技術がどこまでフレームレートや描画品質の改善につながるかが明らかになるだろう。