Core Ultraプロセッサ（シリーズ3）の「Xe3 GPU」の改良点をさらに深掘り 今後の取り組みもチェック！（2/5 ページ）

[西川善司，ITmedia]

X^e3のXMXはどう変わった？

　推論アクセラレータである「Xe Matrix Extensions（XMX）」については、ピーク性能が向上したという情報はない。下図を見ても分かる通り、性能値自体はX^e2アーキテクチャにおけるXMXのスペックと変わらない。

　ただし、XVEの節で解説したように、GRFの割り当て粒度の向上に伴って、同時実行スレッド数が25％向上しているので、性能自体は改善している。

XMXの公称理論性能値。FP8が未記載なのは、恐らくFP8演算は先述のFP8 Dequantization Supportを活用してFP16用演算ユニットで演算するからだと思われる。ネイティブFP8対応は、次世代アーキテクチャに持ち越しとなりそうだ

　XVEの段でも言及したが、BF8／HF8への対応はXMXでも行われている。しかし、FP8の演算速度（クロック当たりの演算実行回数）については、XMXだけでなくXVEでも意図的に隠している雰囲気がある。筆者としては「FP8の演算速度はFP16／BF16と変わらない」と確信している。

　X^e3 GPUではFP8 Dequantization Supportを通してFP8形式も取り扱えるようになっただけで、演算自体はFP16／BF16用の演算器で行われる――こういうことだろう。

レイトレーシングユニットの改良ポイントは？

　X^e3 GPUのレイトレーシングユニットは「X^eコアあたり1基」という搭載バランスに変わりはない。

　しかし、前回取り上げた通り、12コア版のX^e3 GPUはレンダースライス1基当たりのX^eコアが4基から6基に変わったため（GPU全体では最大6基→12基）、理屈の上ではレイトレーシングの処理パフォーマンスはX^eアーキテクチャ比で1.5倍向上している。

X^e3 GPUのレイトレーシングユニットのブロックダイアグラム。ここで注目したいのが、説明文にある「Dynamic Ray Management」だ

　上にX^e3 GPUの説明図を掲載したが、ここで注目すべきは「Dynamic Ray Management for async ray tracing」という説明だ。日本語にすれば「非同期レイトレーシング向けの動的レイ管理」ということになるのだが、「非同期レイトレーシング」とは一体何なのだろうか？

　簡単に説明すると、非同期レイトレーシングはGPU内の各処理ステージ間で同期を取らず、独立性を持ってレイトレーシング（レイトレ）を実践していく処理系のことだ。

　レイトレのパイプライン（処理フロー）をざっくり書くと、「レイの発行→BVH（Bounding Volume Hierarchy）の探索→ポリゴンとの衝突判定→プログラマブルピクセルシェーダーの実行」という手順で進む。Dynamic Ray Management（動的レイ管理）は、このフローの下流のどこかで“詰まり”が出た場合にレイの新規発行を抑える仕組みだ。

　レイの新規発行のペースを落とすと、BVHキャッシュやL2キャッシュの利用ペースも落ちる。そのため、レイ発行より先のプロセスのパフォーマンス向上（もっというと処理の“くそ詰まり”の改善）を期待できる。

GPUの「固定機能」にもメスを入れて性能向上

　近代的なGPUは、かなりの部分がプログラマブルになっている。しかし、30年前からほとんど形を変えていない「固定機能（Fixed Function）」も存在する。

　X^e3 GPUでは、この固定機能ブロックにも改良が加えられている。Intelは改良点を「New URB Manager」「Up to 2X Anisotropic Filtering」「Up to 2x Stencil Test rate」の3つに大別しているので、それぞれ解説してみよう。

X^e3 GPUでは、大きく3つの「固定機能」が改良されている。いずれも、地味だがパフォーマンスの改善につながるものだ

New URB Manager

　New URB Managerは、その名の通り「新しいURBマネージャー」を意味する……のだが、これが何なのかを知るには「URB」とは何なのかを知る必要がある。

　URBはIntel固有の用語で「Unified Return Buffer」の略となる。これは一種の中継バッファーで、GPU内にある各プログラマブルシェーダー（頂点シェーダー／ハルシェーダー／ドメインシェーダー／ジオメトリシェーダー／ピクセルシェーダー）と、各種固定機能の入出力の受け渡しに使われる。

　過去のIntelの内蔵GPUでは、L3キャッシュの一部をURBに流用していたが、X^eアーキテクチャ以降のGPUではURBに専用バッファを確保している。専用バッファの位置はダイアグラムに記載されていない。しかし、URBはX^eコア同士で共有できなければ意味がないので、常識的に考えるとレンダースライスごとに存在すると考えるのが自然だ。

　いずれにせよ、URBは無尽蔵“ではない”SRAM領域だ。そのため、シェーダーステージが進行するタイミングで「URB Manager」がリクエストに応じて必要な分を割り当てる。X^e3 GPUでは、URB ManagerによるURBの割り当てや更新の粒度を最適化したのだという。

　先述したGRFの粒度変更と近い改善が行われたと見て良いだろう。

Up to 2X Anisotropic Filtering

　Up to 2X Anisotropic Filteringは、「異方性テクスチャーフィルタリング（Anisotropic Filtering）」の処理パフォーマンスを最大2倍に改善したことを意味する。

　異方性テクスチャーフィルタリングは、視線から見たポリゴンの傾き具合にも配慮したテクスチャーフィルター処理を指す。その特性上、テクスチャーへのサンプル数は増え、テクスチャーアドレス計算の負荷がどうしても高くなる。

　「最大2倍に改善した」方法について、Intelは特に言及していない。しかし、明確に機能単位のパフォーマンス向上をアピールしているので、単純に「レンダースライスの2本化」あるいは「X^eコアの増加による副次的恩恵」ではなさそうだ。常識的に考えると、「キャッシュの増量」だけで最大2倍の改善効果を得るのも難しい。

　総合的に考えると、「テクスチャーサンプラーの拡充」や「テクスチャーアドレス計算の並列化」などが行われたと見るのが自然だ。

Up to 2x Stencil Test rate

　Up to 2x Stencil Test rateも、「ステンシルテスト（Stencil Test）」のパフォーマンスが最大2倍という意味だ。

　ステンシルテストは、「ステンシルバッファ（型抜きバッファ）」に描かれた内容（マスクパターン）で描画内容をマスク抜きなどする処理系となる。例えば「描画結果を円形マスクで抜いて、潜望鏡的な演出を付与する」「ゲーム画面で定番のゲージ表現を行う」といった方法で活用される。

　一般に、GPUではステンシルテストと「深度テスト（デプステスト）」をピクセルバックエンド（いわゆるROPユニット）の同一ユニット内で処理する。そのため、ステンシルテストのパフォーマンスが最大2倍なら、深度テストのパフォーマンスも最大2倍となっていると考えるのが自然だ。

　いずれにせよ、こちらも異方性テクスチャフィルタリングと同じく、処理パイプライン（≒サンプル数）を倍化したのだと思われる。