ハードウェアレイトレーシング（RTX・DXR）

なぜハードウェア化が転機だったのか

レイトレーシングの原理（/graphics/ray-tracing-principles/）そのものは古く、写実に強い一方で計算コストが大きいのが宿命でした。1 本の光線ごとに「最も近い交点」を求める処理は、加速構造（/graphics/spatial-structures-bvh/）による枝刈りを前提にしても、木のトラバーサルと三角形交差を膨大に繰り返します。この二つは分岐が多くメモリアクセスが不規則で、SIMT 実行の GPU が最も苦手とする処理です。

NVIDIA の RTX（Turing 世代、2018 年）以降が持ち込んだのは、この BVH トラバーサルと三角形・AABB 交差判定だけを専用ハードウェア（RTコア）に切り出す という発想です。汎用のシェーダコアで木をたどると分岐発散とメモリレイテンシで性能が出ませんが、固定機能の RTコアなら交差判定を高スループットでこなせます。シェーダコアは「交点で何色になるか」という陰影計算に専念でき、両者を並行して回すことでレイトレーシングがリアルタイム域に入りました。

加速構造の二段構成（BLAS / TLAS）

ハードウェアレイトレーシングの中核は、アプリが構築しドライバ／RTコアが読む 加速構造（acceleration structure） です。API は内部フォーマットを隠蔽し、構造は必ず二段に分かれます。

この分離が効くのは、剛体変換が形状を変えないからです。動く物体でも三角形の相対配置は不変なので、重い BLAS は一度だけ構築して再利用 し、フレームごとに更新するのは「どこに置くか」だけを持つ軽い TLAS に限れます。同じ BLAS を異なる変換行列で TLAS に複数回参照させれば、木を 1 本作るだけでインスタンス化（同じメッシュを大量配置）が成立します。

構築は明示的な API 呼び出しで、build（ゼロから作る）と refit（木構造を保ち AABB だけ再計算）を選べます。DXR ではビルド時のフラグで方針を指定します。

加速構造ビルドのフラグ（DXR: D3D12_RAYTRACING_ACCELERATION_STRUCTURE_BUILD_FLAGS）:

  PREFER_FAST_TRACE : トレース最速。SAH 等で品質重視に構築（静的・長寿命向け）
  PREFER_FAST_BUILD : ビルド最速。品質は落ちる（毎フレーム作り直す TLAS 向け）
  ALLOW_UPDATE      : refit を許可（変形メッシュの BLAS 向け）
  ALLOW_COMPACTION  : ビルド後に不要領域を詰めてメモリ削減

変形するメッシュ（スキニングなど）では BLAS を ALLOW_UPDATE 付きで作り、毎フレーム refit で AABB のみ更新します。ただし refit は木の構造を変えないため、大きく変形するとボックスの重なりが増えてトラバーサル効率が徐々に落ち、定期的な再構築が要ります。加速構造の理屈は空間データ構造（/graphics/spatial-structures-bvh/）と共通です。

レイトレーシングパイプラインとシェーダ

固定機能のトラバーサルだけでは絵は出ません。「光線をどこから飛ばすか」「交点で何をするか」はアプリが書くシェーダで決めます。DXR / Vulkan RT は従来のラスタライズパイプラインとは別の レイトレーシングパイプライン を定義し、光線のライフサイクルに沿った複数のシェーダステージを持ちます。

処理の骨格は Ray Generation シェーダが TraceRay（Vulkan では traceRayEXT）を呼ぶところから始まります。呼び出しは非同期の「発射」で、RTコアがトラバーサルを進め、交点の状況に応じて上記シェーダをドライバがディスパッチします。

TraceRay(加速構造, フラグ, レイ, ペイロード) の内部の流れ:

  加速構造を RTコアがトラバーサル
    交点候補ごと → Any-Hit（採用/棄却を判定, 省略可）
    三角形以外  → Intersection（交差を自前計算）
  最近交点が確定 → Closest-Hit を起動
    交点なし     → Miss を起動
  ※ Closest-Hit / Miss から再び TraceRay を呼べる（反射・影・GI の二次光線）

シェーダ間の値の受け渡しは ペイロード（呼び出し側が定義する構造体）で行い、再帰の深さは API とハードウェアの上限に縛られます。どのメッシュのどのマテリアルを使うかは シェーダバインディングテーブル（SBT／DXR ではシェーダテーブル） が対応付けます。これは「この BLAS のこのジオメトリに当たったら、この Closest-Hit シェーダとこのリソースを使う」という索引表で、インスタンスごとに材質を切り替える仕組みです。GPU 上でのシェーダ実行の一般論はプログラマブルシェーダ（/graphics/shader-programming-model/）を参照してください。

ラスタライズとのハイブリッド

現代のリアルタイム描画は「全画面をレイトレーシングで解く」わけではありません。可視面（G バッファ）の生成はラスタライズが桁違いに速いため、そこはラスタライズに任せ、ラスタライズが不得意な効果だけをレイトレーシングで補う ハイブリッド構成が主流です。前段のパイプライン全体像は描画パイプライン（/graphics/forward-deferred-rendering/）と重なります。

典型的なフレームは、まずラスタライズで G バッファ（位置・法線・材質）を埋め、その各ピクセルを起点に少数の光線を飛ばして影・反射・GI を求めます。1 ピクセルあたり数本しか飛ばせないためノイズが乗り、これを 時間的蓄積（複数フレームの平均）と AI デノイザー で滑らかにするのが定石です。原理的な積分の背景はパストレーシング（/graphics/path-tracing-global-illumination/）にあり、リアルタイムはそれを 1 サンプル近くまで削ってデノイズで補っていると捉えると見通しが良くなります。

DXR と Vulkan Ray Tracing

API は二系統がほぼ同等の機能を提供し、概念はそのまま対応します。系譜の背景はグラフィックスAPIの系譜（/graphics/graphics-api-genealogy/）を参照してください。

両 API とも、独立したレイトレーシングパイプラインを組む方式に加え、インライン方式（DXR の RayQuery／Vulkan の Ray Query） を持ちます。これは既存の頂点・フラグメント・コンピュートシェーダの中から直接トラバーサルを回し、Closest-Hit などの別ステージを介さず結果をその場で受け取る方式です。SBT やパイプライン構築が不要で単純ですが、任意深さの再帰や複雑なシェーダ分岐には向かず、影の可視判定のような単発の問い合わせに好適です。用途に応じて「フル RT パイプライン」と「インライン」を選び分けます。

まとめ

• RTコア は BVH トラバーサルと三角形・AABB 交差を専用回路で高速化し、分岐発散に弱いシェーダコアを陰影計算に専念させることでレイトレーシングをリアルタイム域へ引き上げた。
• 加速構造は BLAS（形状の木）／TLAS（インスタンス参照＋変換行列） の二段。剛体は BLAS を再利用し、動くのは軽い TLAS だけ。変形は refit で AABB のみ更新する。
• レイトレーシングパイプラインは Ray Generation・Intersection・Any-Hit・Closest-Hit・Miss から成り、TraceRay を起点に光線のライフサイクルへシェーダをディスパッチする。マテリアル対応は SBT が担う。
• 実務は ラスタライズで可視面、レイトレーシングで影・反射・GI のハイブリッド。少数サンプルのノイズは時間的蓄積とデノイザーで補う。
• API は DXR（TraceRay／Shader Table）と Vulkan RT（traceRayEXT／SBT） が同等で、単発問い合わせ向けの インライン方式（RayQuery） も持つ。