GPUの「レイトレーシング処理」改良の歴史をひもとく【GeForce RTX 40シリーズ編】：レイトレーシングが変えるゲームグラフィックス（第6回）（3/5 ページ）

[西川善司，ITmedia]

※本記事はアフィリエイトプログラムによる収益を得ています

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倍」としている。

GeForce RTX 3090 Tiと、GeForce RTX 40シリーズの上位モデルの主な仕様。RTコアは、改良だけでなく増量も行われている（図中の「RTX 4080 12GB」は、現行の「GeForce RTX 3070 Ti」を指す）

改良ポイント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コアにテクスチャーを読みだしてもらって精査を実施――このような流れとなる。

2つの三角形に「図a」のようにテクスチャーが割り当てられた場合の、OMの割り当て例が「図b」だ。OMは「仮想的なマイクロポリゴン（Virtual Mesh of Micro-Triangles：小さな三角形）」で、図bでは「確実に透明」を白、確実に不透明を深緑、「不明」を赤にして表している。判定をCUDAコアに外注するのは赤色の部分だけとなるので、かなりの負荷軽減につながる

OMEなしのGPU（GeForce RTX 30シリーズまで）と、OME付きのGPU（GeForce RTX 40シリーズ）におけるプログラマブルシェーダー（CUDAコア）の仕事量の比較。ポリゴン上の同じ3カ所にレイが衝突したという想定で比べると、OMEなしのGPUではCUDAコアに判定処理が3回ってきたが、OME付きのGPUではCUDAコアによる判定処理が1回だけで済んでいる

　OMEが搭載されたことで、各レイはポリゴンにぶつかる度に生じる、テクスチャー判定の外注を激減させることに成功した。NVIDIA社内のテストでは、トラバース処理のパフォーマンスは最大で先代の2倍になったという。

NVIDIAがValveのゲーム「Portal」をレイトレーシング対応にリメイクした「Portal with RTX」のワンシーン。このシーンでは、透明要素を多く含む煙のパーティクル（粒子）が多く描かれている

上のシーンにおいて、射出されたレイが煙のパーティクルとぶつかった際に、CUDAコアにテクスチャーの精査をどのくらい依頼したかをヒートマップで比較した図。OMEを利用した場合が右で、OMEを利用しなかった場合が左なのだが、随分と大きな差が出ている。ちなみにこの場合、OMEを使うことでフレームレートも10％向上したそうだ

　とても便利そうなOMEなのだが、現時点ではMicrosoftの「DirectX Raytracing」からは直接利用できない。また、既存のゲームに対して適用することもできない。

　現在、NVIDIAはMicrosoftと共同で、DirectX RaytracingからOMEを利用するためのAPIの開発を進めている。「待てない！」という場合は、NVIDIAが「OpenGL」「Vulkan」向けに用意している拡張API（エクステンション）を使う必要がある。

　ともあれ、OMEを活用するゲームタイトルの充実には、まだ時間が掛かりそうだ。