「レイトレーシングが変えるゲームグラフィックス」というテーマでつづってきた不定期連載。前回は「GPUから見たレイトレーシング」をテーマに、NVIDIAのGeForce RTX 30シリーズにおけるレイトレーシング処理の高速化手法を解説した。
今回は、同シリーズの後継モデルで、今も現役の「GeForce RTX 40シリーズ」におけるリアルタイムレイトレーシング処理の“最適化”手法をチェックしていきたい。
●GeForce RTX 40シリーズは、レイトレの“どこ”を改善しようとした？
GeForce RTX 40シリーズの開発において、NVIDIAはレイトレーシング性能を向上させるための改良や拡張に対し、“多角的な視点”で取り組んだとされる。
一体どこがどう多角的なのか……を見ていく前に、説明の都合上「レイトレーシングとは何か？」という基礎を改めて振り返っておきたい（何度も説明していることなので、耳にたこができてしまっている人は、このパートは読み飛ばしても構わない）。
大ざっぱに言えば、レイトレーシングとは「あるピクセルの色を算定するとき、そのピクセルが受け取っているはずの光の情報を得るために光線（＝レイ）を射出して、その軌跡をたどる（＝トレースする）処理」のことを指す。下図は、レイトレーシングにおける典型的な3つのパターンを示している。
この図では、レイトレーシングにおけるレイトレース事例を示している。
図の1-a～1-cは、「ターゲットのピクセルに光が当たっているか否か」を調べるためのロケット（＝レイ）だ。あるピクセルから飛ばしたロケットが光源に到達したら、発射元のピクセルには「光が当たっている」と判断できるので、プログラマブルシェーダー（最近のGeForceなら実務担当は「CUDAコア」）を呼び出して、そのピクセルの陰影具合を演算させるることになる。
図の2-a～2-cは、「ターゲットのピクセルが影か否か」を調べるためのロケットだ。飛ばしたロケットが第三者に衝突したのであれば、「発射元のピクセルは第三者に遮蔽（しゃへい）されている」、つまり「影になっている」と判断できるので、発射元のピクセルは暗い色とすることになる。
そして図の3-a～3-cは、光が当たっていると判断された発射元のピクセルから、視線の反射方向にもロケットを飛ばしているケースだ。もしも発射元のピクセルが、「テカテカとした金属のような鏡面反射特性の強い材質」だとすると、このロケットが視線の反射方向の第三者に衝突しら、「発射元ピクセルにはその第三者が映り込んでいる」と判断できる。
レイトレーシングの処理は、上記のように行われる。
NVIDIAのGeForce RTXシリーズでは、これを「RTコア」と呼ばれるレイトレーシングユニットが担当している。具体的には、ロケット（＝レイ）を打ち出す「レイの生成処理」と、ロケットを進める「トラバース（Traverse：横断）処理」、そして衝突判定を行う「インターセクション（Ray-Triangle Intersection：交差）処理」の3つを
なお、実際のライティングやシェーディングの演算は、レイトレーシングにおいてもプログラマブルシェーダー（先述の通り、GeForceシリーズならCUDAコア）が担当する。
RTコアが行う3つの仕事のうち、特に負荷が高いのがトラバース処理とインターセクションだ。
●大容量「LLC」がレイトレ時代のGPUの“鍵”？
負荷の大きいトラバース処理とインターセクション処理をもう少し具体的に説明すると、描画対象の3Dシーンの構成が記述されている「BVH（Bounding Volume Hierarchy）」と呼ばれる構造体に対して、レイが衝突しているかどうか探査する処理に相当する。実務的には「グラフィックスメモリへのアクセス」と「多少の幾何学計算」が行われることになる。
2つの処理のうち、グラフィックスメモリへのアクセスにおける負荷を軽減するとしたら、どのような改善を施すのがベターなのか――最も直接的な解答は、グラフィックスメモリへのアクセスをキャッシュメモリへのアクセスに置き換えて隠蔽することだ。
事実、GeForce RTX 40シリーズ（Ada Lovelaceアーキテクチャ）では先代の「GeForce RTX 30シリーズ」（Ampereアーキテクチャ）と比べるとL2キャッシュの容量を大幅に増量している。以下に、GeForce RTX 40シリーズの上位モデルにおけるL2キャッシュの容量を示す。
・GeForce RTX 4090：72MB
・GeForce RTX 4080：64MB
・GeForce RTX 4070 Ti（※1）：48MB
（※1）発表当初は「GeForce RTX 4080」のバリエーションモデルとされていた（参考記事その1／その2）
GeForce RTX 40シリーズでは、L2キャッシュは「ラストレベルキャッシュ（LLC）」に相当する。実はGPUにおけるLCCの大容量化は、ここ最近（2020年以降）の技術的トレンドの1つとなっている。
例えばAMD初のリアルタイムレイトレーシング対応GPUとして2020年登場した「Radeon RX 6000シリーズ（RDNA 2アーキテクチャ）」は、まさにその典型例だ。同シリーズの最上位モデル「Radeon RX 6900 XT」には、「Infinty Cache」という名称のL3キャッシュ（LLC）を128MBも搭載していた。
こうした大容量LLCは、一般的なグラフィックス処理系の高速化に貢献するのはもちろん、レイトレーシング処理にも大きなパフォーマンス向上をもたらす。実際、NVIDIA自身もGeForce RTX 40シリーズの発表時に大容量LLCの効果の一例として、このことを挙げていた。
GeForce RTX 40シリーズでは、RTコア自身にも幾つかの改良を施されている。
●GeForce RTX 40シリーズの「RTコア」はどう改良された？
GeForce RTX 40シリーズのRTコアは「第3世代」とされている。GeForce RTX 30シリーズに搭載されていた「第2世代」と比べると、大きく4つの改良ポイントがある。それぞれ、見ていこう。
改良ポイント1：交差判定のスループット改善
1つ目の改良ポイントは、インターセクション処理のパフォーマンス改善だ。GeForce RTX 40シリーズのRTコアでは、インターセクション処理のスループット（実効速度）が先代比で2倍に向上している。
この“2倍”という値は、RTコア1基当たりの改善による値だ。製造プロセスの微細化（8nm→5nm）のメリットを生かした動作クロックの向上、演算器の集合体である「Streaming Multiprocessor（SM）」の増量（≒RTコアの増量）も加味すれば、同等クラスのGPUチップとの比較なら先代の2倍以上の実効性能向上となる。
実際、NVIDIAは「GeForce RTX 3090 Ti（GA102）」に対する「GeForce RTX 4090（AD102）」のRTコアの性能向上を「2.4倍」としている。
改良ポイント2：Opacity Micromap Engineの搭載
GeForce RTX 40シリーズのRTコアでは、トラバース処理の強化も行われている。
投げられたレイがポリゴンに衝突したかどうか判定を行うインターセクション（交差判定）処理において面倒なのは、例え「ポリゴンに衝突した」と判定されたとしても、「そのポリゴンは本当に実体として存在してますか？」と、疑って掛かる必要がある点に尽きる。
どういうことか。例を挙げて説明しよう。
レイが衝突したポリゴンに、「葉っぱ」のテクスチャーが貼られていたとする。ポリゴンは「三角形」であり、葉っぱのテクスチャーは「自由な形状で描かれた図柄のようなもの」だ。葉っぱのテクスチャーにおいて、葉っぱの“実体部分”には緑色の「テクセル（テクスチャーを構成するピクセル）で塗られている。しかし、それ以外の部分は透明として「実態なし」と扱うのが一般的だ。
仮にレイがポリゴンに衝突したとして、その衝突先が「葉っぱの実体部分」なら、そのレイは「衝突した！」と見なしても問題ないが、葉っぱテクスチャの透明部分にぶつかった場合は、実体がないのだから“素通り”してもらわなければ、おかしなことになる。
しかし、RTコアでは「レイとポリゴンの衝突」の判定まではできる。しかし、「ポリゴンにどんなテクスチャが貼ってあるのか？」という識別処理までは行えない。
「ならどうするの？」というところだが、この処理はテクスチャーユニットを子分に従えているプログラマブルシェーダー（CUDAコア）に頼むしかない……のだが、肝心のプログラマブルシェーダーは通常、多数がラスタライズ法の描画のために動員されていて忙しい。レイとポリゴンの衝突を検出する度に、RTコアが「このポリゴンが透明なのかどうか調べて！」とCUDAコアにお願いしても、CUDAコアはすぐに動けないことが多々あるのだ。
そこでNVIDIAは、CUDAコアにテクスチャの判定を“外注”する頻度を可能な限り減らすための仕組みを考えた。「Opacity Micromap Engine（OME）」だ。
OMEは、レイのぶつかったポリゴンが「確実に透明」「確実に不透明」「不明（透明なのかどうか分からない）」という判定を、RTコアが行う仕組みとなる。概念的には「ポリゴンに付帯させるテクスチャーのようなタグ」と考えると分かりやすい。NVIDIAはこれを「Opacity Micromap（OM）」と呼んでいる。
OMはテクスチャーに近い存在ではあるが、データ量は1要素につき2bitしかない。わずか2bitのデータで、ポリゴンの属性を表現している。
レイがポリゴンにヒットした際、RTコアはポリゴンに付与されたOMを参照し、その後レイをどうするのかを決める。「確実に透明」ならレイを素通りさせ、「確実に不透明」なら衝突と判定してから次の処遇を決める。「不明」の場合は、これまで通りにCUDAコアにテクスチャーを読みだしてもらって精査を実施――このような流れとなる。
OMEが搭載されたことで、各レイはポリゴンにぶつかる度に生じる、テクスチャー判定の外注を激減させることに成功した。NVIDIA社内のテストでは、トラバース処理のパフォーマンスは最大で先代の2倍になったという。
とても便利そうなOMEなのだが、現時点ではMicrosoftの「DirectX Raytracing」からは直接利用できない。また、既存のゲームに対して適用することもできない。
現在、NVIDIAはMicrosoftと共同で、DirectX RaytracingからOMEを利用するためのAPIの開発を進めている。「待てない！」という場合は、NVIDIAが「OpenGL」「Vulkan」向けに用意している拡張API（エクステンション）を使う必要がある。
ともあれ、OMEを活用するゲームタイトルの充実には、まだ時間が掛かりそうだ。
改良ポイント3：Displaced Micro-Mesh Engineの搭載
突然だが、ここで問題。ある3Dシーンのポリゴン数が100倍になった場合、レイトレーシングの処理にかかる負荷はどのくらい増加するだろうか？
単純に考えれば「100倍！」と答えたくなる所だが、実際はそこまで増えないという。NVIDIAによれば、「レイのトラバース処理とインターセクション処理なら、せいぜい2倍程度しか増えない」という。
100倍の数のポリゴンを、わずか2倍の負担増で処理できてしまう――これは、リアルタイムレイトレーシング技術ではBVHを使って3Dシーンを階層として管理しているからだ。
BVHを構成する基本要素は、当該の3Dモデル全体を覆える最小体積の直方体（Box）だ。Boxは3D座標軸に平行／垂直な向きにそろえられた「Axis Aligned Bounding Box（AABB」構造になっており、こうした構造体は「Acceleration Structure（AS）」と呼ばれる。
レイはトラバース（推進）したら、BVHを参照した上で、衝突の有無をAABB単位で判定する。BVHはAABBによる階層構造になっていて、実際の衝突判定は最下層のAABBに含まれるポリゴンに対して行われる。
ポリゴンが100倍となった3Dシーンでは、BVH探索における下層への探索数がより多段化する。しかし、レイのインターセクション処理のほとんどは、上層の方にある粗いAABBであり、「衝突していない」と判定されて素通りされてしまう。逆に、深い階層までBVHの探索が及ぶのは、「衝突している」と判定されるレイだけとなる。
ゆえに、ポリゴンが100倍になったとしても、レイのトラバース処理時間とインターセクション処理時間まで100倍になることはないのだ。
一方で、NVIDIAはこうも主張している。
3Dシーンの複雑性（≒ポリゴン数）が増加した場合、レイトレーシングの処理系において、最もリニアに負荷が増大してしまうのは「BVHの生成に要する時間」と、「BVHが消費するグラフィックスメモリの容量」だ。
この課題に対処するために、NVIDIAはGeForce RTX 40シリーズのRTコアに「BVH探索の高速化」「BVH容量のコンパクト化」を実現し、ひいては「多ポリゴンの3Dシーンにおけるレイの交差判定の高効率化」を実現するための機構を統合した。「Displaced Micro-Mesh Engine（DMME）」だ。
結論から言うと、DMMEが実現する「≪Displaced Micro-Mesh（DMM：変移マイクロメッシュ）」の着想や発想の起点は、先述のOMとよく似ている。
DMMを活用する際は、3Dシーンを構成する3Dオブジェクトを構成するポリゴンを「低ポリゴン3Dモデル」と、ディテール表現に相当するDMMに“あらかじめ”分離しておく必要がある。
「そもそもDMMって何だよ？」というところだが、イメージ的にはDirectX 11で追加された「テッセレーションステージ」という仕組みにおいて利用できるようになった、「ディスプレースメントマッピング（Displacement Mapping）」で取り扱われる「ディスプレースメントマップ（Displacement Map）」というテクスチャーの概念とほぼ同じだ。
ディスプレースメントマップとは、3Dモデル上のディテール表現を「盛っている」か「掘ってる」かの分布図、言い換えれば「デコボコの変移量」としてテクスチャーマップにしたものだ。
ディスプレースメントマッピングでは、まずテッセレーションステージにおいて、低ポリゴンの3Dモデルを多数のポリゴンに分解する（この処理を「テッセレーション」という）。その後、分解されたポリゴンに対して、ディスプレースメントマップの起伏の変化量に応じて3Dモデルを盛ったり掘ったりして、ディテールを加えていく。
GeForce RTX 40シリーズのDMMEが取り扱うDMMは、ディティールの表現に使われるもので、事実上テクスチャーのようなものだ。しかし実態としては微細な三角形を使って起伏を表現している。前段で「OMは仮想的なマイクロポリゴン」だと説明をしたが、OMの起伏情報バージョンがDMMだと考えればいい。
BVH自体は、低ポリゴンの3Dモデルベースで生成されたり更新されたりするので、その生成は劇的な速度で行え、さらにはグラフィックスメモリの占有容量もかなり抑えられる――そういうからくりだ。
それでは、このDMMEをを絡めた、レイのインターセクション処理はどういう流れで行われるのだろうか。順を追って解説する。
基本的にレイの探索は、低ポリゴン3DモデルからなるBVHに対して行われる。もしもレイがBVH上層の粗いAABBにヒットしていると判定され、最終的に低ポリゴン3Dモデルを構成する1つのポリゴンまで行き着いたとする。
すると、ここでDMMEが登場する。DMMは、レイが衝突したポリゴンの位置に対応するDMM上の起伏情報を読み出し、衝突した箇所のディテール情報を“補正”する。言い換えると、レイのぶつかった場所を「低ポリゴン3Dモデル上の1ポリゴン」から「多ポリゴン3Dモデル上の1ポリゴン」に修正するわけだ。
NVIDIAがDMMEを使わない場合と使う場合で3Dモデルのレンダリングパフォーマンスを比較したところ、BVHの生成／更新速度は8～15倍に高速化された一方で、BVHのデータサイズは6～20倍も小さくできたそうだ。
ちなみに、OMEと同様に、現時点ではDMMEもDirectX Raytracingから利用できない。既存ゲームに対して自動で機能するものではなく、使うには、個別に対応が必要となる。
改良ポイント4：Shader Execution Reorderingの搭載
ここまで3つの改良ポイントは、レイのトラバースやインターセクション処理を高効率化するための取り組みだった。4つ目のポイントは、そことは少し異なる観点からの改良だ。
レイトレーシング処理では、ピクセルから放たれたレイがポリゴンなどに衝突して交差判定が確定すると、その箇所に対して「ライティング」や「シェーディング」の演算を行う必要がある。レイが光源に到達した場合は、発射元のピクセルでも同様の処理が行われる。
ライティングやシェーディングに関する演算はRTコアではなく、プログラマブルシェーダーとしての機能を担うCUDAコアで行われる……のだが、問題はレイトレーシング法と、従来的な「ラスタライズ法」では、CUDAコアの使われ方が全く異なるという点にある。
ラスタライズ法では、ポリゴンがラスタライザーによって、一塊の複数ピクセルに分解される。そして、分解された塊たち“ドバっと”プログラマブルシェーダーに押し込まれる。ラスタライザーによって分解／生成された「一塊の複数ピクセル」は、元々は1枚のポリゴンから誕生したものだから、ほぼ同一の材質のことが多い。
ゆえに、CUDAコアが実行することになるライティングやシェーディングのプログラムは同一のもので、ほぼ同じテクスチャーを参照することになる。となれば、大増量されたL2キャッシュの利用効率もすこぶるよい。
しかし、レイトレーシング法の場合、隣接する“近しい”ピクセル群から発射されたレイたちも、それぞれの発射角度が異なれば、異なる3Dモデルのポリゴンに衝突する可能性もある。放たれたレイたちが衝突先のポリゴンで“反射”する場合も、それぞれ全く異なる場所にある3Dモデルのポリゴンに当たることも多くなるだろう。
すると、各レイがライティングやシェーディングのためにCUDAコアに外注するシェーダープログラムはバラバラなものになる。当然、L2キャッシュの利用効率も悪くなる。場合によっては、別の仕事で忙しいCUDAコアが受注に応じられない可能性も否定できない。
CUDAコアを含めて、近代GPUのプログラマブルシェーダー類は、SIMD（Single Instruction Multiple Data：1命令で複数データを取り扱うモデル）から発展した実行モデル「SIMT（Single Instruction Multiple Threads：1命令で複数スレッドを取り扱うモデル）」を採用している。ゆえに、一番パフォーマンスを高められるのは「同一のシェーダープログラムを、ひとまとめにされた複数スレッド（ピクセル）に対して実行したとき」となる。このモデルは、ラスタライズ法での活用を想定して作られたものなので、どうしてもレイトレーシング法のレンダリングメカニズムとは相性がよくない。
レイトレーシング法でも、レンダリングのパフォーマンスを向上できないか――そこでNVIDIAが仕込んだ新しい概念が「Shader Execution Reordering（SER）」だ。
SERは、衝突したとみなされたレイがプログラマブルシェーダーに仕事を発注する際に、「同一のシェーダープログラムで実行できそうな発注」を整理して、可能な限りまとめてから発注する役割を持つ。いわば「交通整理人」のような役割といえる。
これにより、「同じシェーダープログラムが別のCUDAコアで動く」という非効率な状況を抑えることができる。逆にいえば、同じCUDAコアで局所性の高いスレッド（例えば同じ材質の処理）を複数扱えるようになるので、L3キャッシュの利用効率の向上も期待できる。
NVIDIAは、SERについて「レイトレーシングパイプラインに、新しいステージを追加したもの」と説明している。確かにその通りだ。CPUの命令実行モデルの変革と同様に、従来の「逐次実行」のスタイルから、「順不同（Out-of-Order）実行」スタイルにシフトしたともいえる。
ただし、このSERも既存のレイトレーシング対応ゲームで自動活用できる類いのものではない。ゲーム側が制御APIを通じてSERに対応させなければ、SERの恩恵を受けられないのだ。
このことは、当然といえば当然でもある。ゲームのグラフィックスエンジン（グラフィックサブシステム）は、「どの3Dモデルのどのポリゴンには、どんな材質設定がなされていて、どのテクスチャを使うのか」といったことは把握している。ゆえに、衝突が検知された各レイが、これからプログラマブルシェーダーへ発注することになる処理内容にも見当が付く。
どのゲームにも自動対応する（≒アプリとしての特別対応を不要とする）よりも、グラフィックスエンジンで効果的なSERメカニズムを実践する（≒アプリで特別な対応を施してもらう）方が、仕組みを最大限に生かせるのだ。
ちなみに、NVIDIAは開発者向けにGPUパフォーマンスの解析ツール「NSight Graphics」を用意している。SERの利用に当たっては、このツールを使って解析してから実装することが推奨されている。
SERについては、先の改善と同様に現時点ではDirectX Raytracingを介して利用することができない。NVIDIAは他のグラフイックス関連企業と連携して、標準対応に向けた協議を進めているという。
その実際の効果だが、NVIDIA調べで「Cyberpunk 2077」の最上位設定「Overdrive Tracing」においてSERを有効化すると最大44％のパフォーマンス向上効果があるとのことだ。
●レイトレを高速化する機能が“てんこ盛り” しかし“個別対応”がネック
このように、GeForce RTX 40シリーズのレイトレーシング機能は、我々が想像していた以上にパワーアップしている。
しかし、ここまでの解説を見てきて「あれ？」と思った人もいるだろう。そう、GeForce RTX 40シリーズならではのレイトレーシング機能を使うには、ゲーム（アプリ）側で個別対応が必要なのだ。
現状では、NVIDIAから提供されているSDKを活用するか、NVIDIAが提供する「Unreal Engine 5」のスペシャルバージョンを使うことで、これらの機能を活用したゲームを開発できる……のだが、開発者にここまでの“特別対応”をするためのリソースがあるかというと、そこまででもないように思える。
PCゲーミング向けGPUの世界では、確かにGeForce RTXシリーズはリーダー的な存在だ。しかし、実際に今回紹介した新機能を“効果的に”実装しているゲームは、NVIDIAが開発協力することでアップデートされたCyberpunk 2077以外にほとんど存在しない。
ただし、GeForce RTX 40シリーズに搭載された新機能は、DirectX Raytracingの新バージョンで標準利用できるようになる可能性が高い。AMDのRadeonシリーズでも対応を果たせば、より多くのゲームタイトルで積極的に使われるようになるだろう。
次回は、AMDの「Radeon RX 7000シリーズ」におけるレイトレーシング機能の改善ポイントをチェックしていきたい。