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

XeSSは第3世代に　マルチフレーム生成を実装

　今回、Panther LakeをCore Ultraプロセッサ（シリーズ3）として投入することを発表した際に、Intelは超解像ソリューション「X^e Super Sampling（X^eSS）」に新機能として「X^eSS MFG」を搭載することを予告した。

　察しのよい人は気付いたかもしれないが、MFGは「マルチフレーム生成」を意味する。NVIDIAの「DLSS（Deep Learning Super Sampling） 4」に実装されたものと同種の技術に“対抗”するものとなる。

　XeSSシリーズといえば、第2世代の「X^eSS 2」において、前フレームと現在フレームから中間フレームを生成し補間する「X^eSS-FG」を実装している。こちらは2024年末のX^e2アーキテクチャベースの独立GPU「Intel Arc B Graphics」シリーズと同タイミングに発表されている。

　新たに発表されたX^eSS-MFGは、新世代の「X^eSS 3」に含まれる技術という位置付けで、その動作メカニズムは下図のようになる。見れば分かるが、アルゴリズム的にはX^eSS-FGと変わりがなく、生成される補間用フレームが最大3枚になったものという理解でOKだ。

XeSS-FG／MFGの動作フローをチェック

　ここからは、X^eSS-FG／MFGの動作フローを簡単に確認しよう。

　フレーム生成にあたって、必要な情報は「前フレーム」と「現在フレーム」の2枚のみだ。これはX^eSS-FGもX^eSS-MFGも変わらない。念のため、筆者もIntelの担当者に尋ねてみたが、「複数フレームのバッファリングは行っていない」と明言していた。

　この2枚のフレームから求めるのは、画素単位の「オプティカルフロー」と「モーションベクター」の2つだ。どちらも「画面内におけるピクセル単位の動き情報」のことなのだが、その性質がちょっと違う。

【オプティカルフロー】

　まずオプティカルフローだが、名前に「オプティカル（光学）」が付いていることから想像しやすいと思う。これはピクセル単位の色の動き情報だ。イメージ的には、過去フレームと現在フレームを参照し、MPEG動画圧縮で用いられる「動き補償」相当の情報を求める感じだ。

　MPEG圧縮では，着目しているピクセル（ブロック）がどっちに動いたのかを調べるために、過去フレームから現在フレームに対して空間的な周辺探索を行う。それに対して、リアルタイム性が重要視されるX^eSS-FG／MFGでは、AIを活用してオプティカルフローを算出する。そのAI自体は「過去フレームと現在フレームの色差分の画像」と「オフライン演算で求めた超正確なオプティカルフロー」の相関を学習させたものだ。ランタイムでは、「過去フレームと現在フレームの色差分画像」をAIに入力して、オプティカルフローを推論してもらうという流れとなる。

【モーションベクター】

　次にモーションベクターだが、AIを使わずとも算術的に求められる。

　当たり前のことだが、GPUは描画しているポリゴンの画面上における座標を把握している。そのため、前フレームと現在フレームで描画された全ポリゴンの“移動幅”をピクセル単位で求められる。座標の差分値は、1ピクセル単位の速度に相当する。

　この差分値を求める際、動いているポリゴンが手前の遮蔽（しゃへい）物に隠れてしまったり、逆に手前にある遮蔽物からポリゴンが飛び出してきたりするような、遮蔽物が絡んだイレギュラーも起こりうる。このイレギュラーを判断するために、「Depth」で表される「深度バッファー（Zバッファー）」も精査する。

　モーションベクターは、最近のゲームだとゲームエンジン側がモーションブラーを表現するために利用する「ベロシティーバッファー」として生成していることが多い。ベロシティーバッファーがある場合は、そのままモーションベクターとして流用できる。

---

　これで、ピクセル単位の色の動き情報と、描画されたポリゴンのピクセル単位の動き情報を求められる。両者は補完関係にあり、互いの弱点をカバーできる情報となっている。

　3人称視点のレーシングゲームで、自分の車で前方に爆走している時を考えてみてほしい。路面のポリゴンは奥から手前に通り過ぎていくが、自分の車の“影”は、時速何百kmを出していようと、路面上に“静止したまま”となる。

　ある意味で当たり前なのだが、この時に路面上の影に注目してみてほしい。この影は、あくまでも路面上のピクセルなので、モーションベクターだけで移動量を判断すると、「手前から後ろに通り過ぎている」と見なされてしまう。しかし、オプティカルフローで判断すると、影はずっと同じ位置で描画されているため「静止したまま」として見なされる。この例の場合は、オプティカルフローの判断が正解だ。

　オプティカルフローとモーションベクターのどちらを採用するのか――細かく吟味して「何が動いているのか」「何が動いていないか」を正確に判断するのが、上のダイアグラムで「Blend」として表されるAIだ。

　あとは、求められた最終的な1ピクセル単位の速度情報を元に、過去フレームと現在フレームそれぞれからピクセル色をサンプルして、生成する補間フレーム上のピクセル色を確定していく。各ピクセルの色は、動きの速さに応じて、過去フレームと現在フレームのどちらのフレームのピクセル色の割合が強くなるのかを考慮して決定される。この補間フレーム生成も、AIではなく算術的に求められる。

　生成する補間フレームが最大3枚となるMFGの場合は、各ピクセルの速度情報を3等分した値で合成フレームを生成する。

X^eSS-MFGはGPUに依存しない

　X^eSS-MFGを含むXeSS 3だが、「DirectX 12世代で、シェーダーモデル6.4以上に対応」という要件を満たせば他社製のGPUでも動作する。

　「Vulkan」や「GLSL（OpenGL Shading Language）」といった他の描画系APIではシェーダーモデルという概念がないので，あえて細かく明記すると「DP4a系の8bit／4要素ベクトルの32bit積和算命令に対応しているGPU」が条件となる。

　この要件はXeSS 2以前から変わっていない。XeSS 2／3で実装されているAI処理部分（フレーム生成部分のAIなど)は、推論アクセラレーターを搭載していないGPUでもDP4a系の命令さえ使えれば、推論を走らせることができる。

　とはいえ、マルチフレーム生成は負荷が高い。ゲームで実用レベルとなるのは、最低でも「GeForce RTX 30」シリーズや「Radeon RX 6000」シリーズの中堅モデル以上になると言われている。

　ここで「（X^eSS-FG／MFGを）X^e系GPUで動作させたときのメリットはあるのか？」とIntelのトーマス・ピーターセン氏（アーキテクチャ／グラフィックス／ソフトウェア担当フェロー）に尋ねてみたところ、ピーターセン氏は「ある」と即答した。どのような利点があるのだろうか？

　XMXを搭載しているXe系GPUでは、XeSSシリーズのAI処理は推論アクセラレータのXMXで動作するため、プログラマブルシェーダーユニットへの負荷が軽減される。DP4a命令で推論を走らせた場合は、がっつりプログラマブルシェーダーに負荷が掛かるのとは対照的だ。

　また、XMX版とDP4a版では、XMX版の方が複雑性の高いAIカーネルを回しているため、処理結果の画質はXMX版の方が良いとされる。そして一概には言えないが、DP4aは8bit整数精度（INT8）主体の演算主体で推論を回すのに対して、XMX版はGPU（XMX）の世代に応じて、演算精度をINT8／FP16／BF16／TF32から必要に応じて使い分けられる点も、画質に多少は影響している可能性がある。