前回のCPU編に続いて、今回はGPUについて。COMPUTEXにおけるレポートでも書いたように、「Immortalis-G720」は同社としては初の第5世代アーキテクチャに基づくGPUとなる。

ちなみにこのImmortalis-G720はただの5th Gen GPUであり、先のレポートにも書いたようにもう北欧神話に基づくコード名が付けられていない(Photo01)。

  • Valhallは4年あまり主力GPUとして活躍した

    Photo01:Utgardは1世代、Midgardは4世代、Bifrostは3世代、Valhallは4世代が内部的に存在しており、一番短命だったBifrostは3年余りでValhallに刷新されてしまったが、Valhallは4年あまり主力GPUとして活躍した

「何で？」という話は聞いたのだが「もうそういう事はやめた」という返事しか返ってこなかった。邪推すれば、そもそものMali GPUはノルウェーの「Falanx Microsystems A/S」という企業が開発したものであり、このFalanx Microsystems A/SをArmは2006年に買収。Falanx Microsystems A/SはArm Norwayとなり、以後Mali GPUの開発に携わってきていた。なので北欧神話に基づくコード名が付くのは割と不思議ではない訳だが、これが付かなくなったということはつまりArm Norway以外のチームが5th Gen GPUの開発を行ったということなのかもしれない。もっともArm Norwayの求人情報を見ると、まだSenior GPU Driver Applications Engineerとかを募集しているあたり、GPUに全く携わってない訳でもなさそうではあるが。

さてそんな5th Genの設計目標がこちらである(Photo02)。

  • 最初の目的を、割と意外な方法で実装したのがちょっと面白い

    Photo02:この最初の目的を、割と意外な方法で実装したのがちょっと面白い

ただこれを実現するために、全く新しいアーキテクチャを持ってきたという訳では無い。過去の例で言えば、第3世代のBifrostではQuadと呼ばれる新しい処理単位を導入したが、これは色々問題があったようで次のValhallでは第2世代のMidgardにやや近い、通常のThreadモデルに実装が切り替わっている。今回の5th Genではこういう大きな変更はなく、処理方法の基本そのものはValhallと大きな違いは無い。実際にはValhallをベースに、全ての箇所に見直しや改良を施した、という説明である。ただ、その見直しや改良が、5th GenをValhallとは全く違うアーキテクチャにしてしまった訳だ。

具体的な設計目標がこちら(Photo03)。

  • HDR Renderingが果たしてスマートフォン向けGPUで本当に求められるのか？　というのはちょっと疑問

    Photo03:ただHDR Renderingが果たしてスマートフォン向けGPUで本当に求められるのか？　というのはちょっと疑問である。むしろSuper Resolutionの実装が先な気がしなくもない

HDR Renderingは恐らく顧客(つまりImmortalis-G720のIPを購入するスマートフォン向けSoCベンダー)からのニーズに基づくのでは？　と思うのだが、その前後のメモリアクセス廻りの変更はValhallのプロファイルを確認しての結果であろう。つまり、これ以上に性能を上げたり消費電力を減らしたりするには、メモリアクセスがボトルネックになっているという話だ。

だからといってPC向けのGPUの様に、GDDR6Xを384bit幅で接続するなんて荒業はスマートフォン向けSoCには利用できない。その一方でより高精細な映像、あるいはRay Tracingを利用するとなると、より大きなメモリ帯域を必要とする。要するにメモリアクセスを何とかしないといけない、というのが最大の課題になっていた訳で、これに対する回答がDVS(Deferred Vertex Shading)(Photo04)である。

  • 平均30％程度のメモリ削減が可能とされる

    Photo04:どの位メモリ帯域が減るか、というのは当然アプリケーションによって変わるが、平均30％程度のメモリ削減が可能とされる

DVSの実装は後で説明するとして、DVSを採用する事により必要となるメモリ帯域そのものを減らす事が可能になった。

この結果、

  • 同じ性能なら利用するメモリ帯域が減った分省電力化
  • 同じ消費電力なら、より高いメモリ帯域が利用できる分高性能化

が可能になった。もちろんShaderの方も細かく改良がなされており、結果として少ない消費電力でより高い性能を実現可能となり、かつ今後の性能向上に向けたヘッドルームも確保できたとする(Photo05)。

  • 実際にするかどうかはアプリの開発者次第なのだろう

    Photo05:平均性能を引き上げ、メモリ帯域を減らしたことで、今後はBloomとかDoFなどさらに描画を向上させるための技法が使えるようになる、としている。まぁそれを実際にするかどうかはアプリの開発者次第なのだろうけど

システムレベルでの数字で言えばこんな感じ(Photo06)になっている。

  • System Level Efficiencyは単にシステム全体での必要になるメモリ帯域を40％減らした、という話

    Photo06:System Level Efficiencyは単にシステム全体での必要になるメモリ帯域を40％減らした、という話。性能に関しては平均15％向上となっているが、これはImmortalis-G715と同一プロセス・同一動作周波数の話であり、実際にはプロセスの微細化があるからもう少し性能は向上するだろう

また細かなところでは、VRS(Variable Rate Shading)の改良やMSAA 2x、VulkanにおけるDynamic Bufferのサポートなどが追加されているが、これはマイナーバージョンアップの範疇だろう。

  • MSAA 2xはこれまでもサポートはされていた

    Photo07:MSAA 2xはこれまでもサポートはされていたが、それをドライバレベルでの実装であり、Immortalis-G720ではこれを専用ハードウェアで実装したという話である

さて、ではImmortalis-G720の最大のコアであるDVSについて説明したい。Photo08がImmortalis-G720の内部構造であるのだが、このレベルで言えばまだValhallとの差は大きくない。

  • Valhall世代と大きく異なるのは、Fragment Frontendからの出力がFragmentとVertexの2つに分かれた事だろう

    Photo08:Valhall世代と大きく異なるのは、Fragment Frontendからの出力がFragmentとVertexの2つに分かれた事だろうか

ところが実際の処理の流れがだいぶ違う。その処理の流れがPhoto09である。

  • Photo09:Polygon単位でFVSを使うかDVSを使うかを選択する形になる

    Photo09:Polygon単位でFVSを使うかDVSを使うかを選択する形になる

Armの説明によれば、全ての描画処理でDVSが利用できるわけではなく、一部のものは描画処理をスタートしたらすぐに実行すべきものもある。こうしたものはFVS(Forward Vertex Shader)のパスになる訳だが、FVSで処理したものが即座にあとのステージで使われる訳では無く、一度メモリに書き込まれ、だいぶ後になってから改めてメモリから読み出される場合が少なくない。そこで本当にすぐ必要な処理はFVSで実施するが、それ以外のものはすぐ次のステージの処理が行われるようになる直前で実施する様にすれば、無駄にメモリに書いてまた読み出す処理が省けるので、メモリアクセスがその分減る、という仕組みである。

理屈はそんな訳で簡単なのだが、これ実装しようとすると後ステージがボトルネックになりかねない。なんでもかんでも後送りにできる訳でも無いので、どうやってうまくバランスを取っているのか気になるところだが、具体的なアルゴリズムなどは当然ながら公開されなかった。他にポイントとして挙げられたのはPolygon Listの圧縮化(Photo10)やTileの大型化(Photo11)なども挙げられており、こうした機能によって必要となるメモリ帯域を圧縮、消費電力削減と性能向上を果たしたとしている(Photo12)。

  • 効率は上がるのだろうが、画質にちょっと影響しそうではある

    Photo10:効率は上がるのだろうが、画質にちょっと影響しそうではある

  • Tileはレンダリングの処理単位

    Photo11:Tileはレンダリングの処理単位。Tileのサイズを大きくすると内部で必要になるメモリ量は増えるが、外部アクセスの頻度というか回数そのものは減るから、DVSと組み合わせる事で効果的にメモリアクセスを減らせると考えられる

  • Tileの大型化は、結果的にShadingのやり直しの頻度を減らす事にも繋がるとする

    Photo12:Tileの大型化は、結果的にShadingのやり直しの頻度を減らす事にも繋がるとする

他にも先に述べたように2xMSAAの専用ハードウェアの搭載(Photo13)とか、新たにExecution Engineで新命令を実装(Photo14)、細かいところではRay Tracing Unitが別のPower Islandになったなんて話もある(Photo15)。

  • 2xMSAAで十分な品質であれば4xMSAAまで行かずに済むのでその分性能が落ちないという話

    Photo13:2xMSAAで十分な品質であれば4xMSAAまで行かずに済むのでその分性能が落ちないという話

  • Dynamic BufferへのLoad/Store時にBound checkが行えるようになったというのも便利である

    Photo14:Dynamic BufferへのLoad/Store時にBound checkが行えるようになったというのも便利であるが、FP16というあたりはこれは描画というよりはAI向けという感じだ

  • Ray Tracingを利用しないアプリケーションの場合

    Photo15:Ray Tracingを利用しないアプリケーションの場合、Power GatingによってRay Tracing Unitへの電源供給そのものを止められるので、リークに起因する消費電力を抑えられるとする

細かい話では、ValhallまではOpenGL 2.0までの対応だったが、5th GenではOpenGL 3.0の降るプロファイルに対応したそうだ。

最後にラインナップであるが、これはレポートでも説明したように

  • 1～5コア:Mali-G620
  • 6～9コア:Mali-G720
  • 10～16コア:Immortalis-G720

となる。

  • Armの第5世代GPUアーキテクチャのラインナップ

    Photo16:Armの第5世代GPUアーキテクチャのラインナップ

ちなみにレポートのPhoto09の脚注で「Mali-G720/G620も同じく5th Gen GPU Architectureベースで、ただしRay Tracingの機能が無い物だろう」と書いたがこれは間違いで、Mali-G720/G620も普通にRay Tracing Unitは実装されている。

どこまでこれが使い物になるのか？　は疑問だが、一応プラットフォームとして実装されている事に意味があると考えたのかもしれない(この辺りはインプリメント時のオプションで無効化できるかどうか、不明である)。

あと補足を幾つか。先のレポートでは「CPUとの協調動作が容易になった、という説明もあったが具体的な内容は不明である。あるいはDynamIQのACP(Accelerator Coherency Port)を利用できるようになっているのかもしれない」と書いたが、確認したところACPポートはAIを利用する場合を含めて使わないとの事。では協調動作とは何をさすのだろうか？。あとSuper Sampling。PC向けGPUであっても、Ray Tracingを使う場合は猛烈に描画負荷が高くなるため、Super Samplingを併用するのが一般的になっている。そのあたりも踏まえて「NVIDIAとIntelはAIベースのSuper Samplingを、AMDはアルゴリズムベースのSuper Samplingを提供しているが、Armは？」とたずねたところ、そもそもSuper Samplingは現時点では提供の予定が無いという事で、ちょっと肩透かしに終わった。まぁ現状ではまだRay Tracing対応のモバイルゲームが非常に少ないから、そこまでSuper Samplingのニーズが無いのかもしれない。ただ今後もこの路線で行くとは考えにくいところで、どういう方向性を考えているのか気になるところだ。