PS5のTempest Engineとは？AMD GPU派生の技術を紐解いていく...
- Tempest 3D Audioとは？Temepest Engineとは？
- Tempest Engineの詳細
- Compute Unitベースのテクノロジー
- CellのSPEライクなアーキテクチャ
- まとめ
Tempest 3D Audioとは？Temepest Engineとは？
PS5ユーザーならすでに御存知の通り、PS5にはDolby Atmosなどとは違う、まったく独自の3Dオーディオが導入されている。
その名も”Tempesrt 3D Audio"。
ウリはもちろん立体音響であり、更なる音響表現をゲームに加えることを目的として新たに開発されたということ。
専用ヘッドホンだけではなく手持ちのイヤホンを繋いでも楽しめる手軽さに加えて、テレビのスピーカーなどでも立体音響を楽しめるようにデザインされている。
総合的にいえばPS5全体のオーディオシステムの総称とも言える。
（ちなみにPS5自体はDolby Surroundに対応しているためDolby対応タイトルも普通に楽しめるが、Dolby Atmosには対応していない）
それに加えてそれらの複雑な処理を滞りなく行うための専用ハードウェアとして新たに
”Tempest Engine”が開発された。
ということで今回の主題はTempest Engineを掘り下げようである。
ちなみにオーディオ関連の話はさっぱりなのでここでは取り上げない。
あくまでプロセッサ関連の話である。
Tempest Engineの詳細
実はこのプロセッサもSIE側からの情報が少なく、ほとんどの情報源はPS5のリードアーキテクトのマーク・サーニー氏がGDC2020で行ったセッションThe Road to PS5かテックメディアのDigital Foundryがマーク・サーニー氏に行ったインタビューぐらいでしか詳細な内容が公開されていない。
セッションやインタビューで言及されたポイントを挙げてみよう。
Tempest Engineのハード詳細についても総合して書き出すと
- 64flops/cycleの演算性能を持ち、GPUの動作周波数で動く
- PS4 CPUと同じ100Gflops程度
- Wavefront(演算タスク)は2つのみ
- 帯域幅は20GB/s程度
- キャッシュを持たないDMA転送のみ
サーニー曰く、「CPUよりも遥かに強力な並列処理ができるGPUのコアにSPEの性質を組み合わせて、強力なオーディオエンジンを作ったよ」ということである。
PS4時代はとくにオーディオ処理がネックだったようで、PS3のころのCellプロセッサを用いたオーディオシステムが良い意味で懐かしく思えたほどだったとのこと。（ちなみにPS4はAMD TrueAudioと呼ばれるオーディオDSPが載っていたのにも関わらず、PS4において何がネックだったのかは具体的に語られていない）
そして、さらに面白いのはハードウェアとしてはCellのSPEを使うのではなくGPUのCUをベースに改良したプロセッサを使うということだ。
Compute Unitベースのテクノロジー
まずは元となったAMD GPUのCompute Unit(以下CU)について見ていこう。
CUとはAMD GPUの中では演算処理の最小単位であり、GCN,RDNAアーキテクチャでは統一して64個のGPUコアが内包されている。ちなみにGCNとRDNAではそれぞれアーキテクチャによって配置が異なるが基本は64コアである。
Tempest Engineの64flops/cycleの演算性能を持つということは要するに1CUあたりの演算性能と合致する。(1サイクルに64基のGPUコアで浮動小数点演算を行う。)
GPUクロックで動作するなら単純計算で
64(flops) × 2.23(GHz) = 142.72(Glops)ということになる。
これはPS4 CPUと同じ100Gflops程度というサーニー氏のコメントとも一致する。
次にWavefront(演算タスク)は2つのみという話。
Wavefrontは注釈の通り演算タスクであり、つまりTempest Engineは2つの演算タスクのみを設定しているということである。
ちなみ一般的なCUだと以下の通り、各CUで合計40個近いWavefrontを保持できるようになっている。画像のとおりだと32コア単位で20個、それが64コアだと40個になる。
GPU全体だとCUの数で保持できるWaveforntは変わるため、例えば64CUあるならその数は2560個のタスクを保持できるor処理できると言っていい。
1CU単位で比べてもわかるがTempestはかなり控えめな設定となっている。
Tempestが処理できるWavefrontは2つだが、その内訳としては以下のように設定されている。
- 3Dオーディオ用とその他の機能
- ゲーム用
それぞれの処理がどのようなものかは解らないためここではあまり言及しない。
ちなみにWavefrontが少ない分、保持するためのレジスタは最低限にとどめることが出来ると考えられるので実際のTempest Engineは一般的なCUよりも小さいとも考えられる。
ちなみにサーニー氏が言うにオーディオ以外に汎用処理でも使えるとのことだがタスク数を限定している点と、やはり独特なアーキテクチャであるため実際に活用されるかは個人的に疑問だ。（CPU SIMDかGPGPUを活用したほうが速いのではないのか？）
また、Tempest EngineはRDNAのCUデザインを採用してる可能性が高い。
理由としては上記の画像の通り、RDNAの場合は32 x2でそれぞれタスクを振り分けられるようになっているからだ。RDNAではWave32という命令処理を導入しており32スレッド単位で処理する形態になっている。64コアのRDNAなら内部でWave32を2つ実行することが可能だ。（1コア1スレッドと考えれば解りやすい)。要するにWave32(Wavefront)を2つ、1サイクル処理できる。
GCNも同じく64コアであるが、RDNAと違うのはWave64を採用している点だ。
Wave64と言っても実際はWave16 x4に近く、RDNAで使われてるWave32と違いWave64は4サイクルで処理する必要がある。そのためGCNアーキテクチャーでは64コアを4つのクラスターで配置してる。一つのクラスターは16コアと仮定する。
要するに一つのクラスターでWave16を4サイクル掛けて処理するからWave64と呼ばれている。
この点から見るにTempest Engineのコンセプトとしては1サイクルで64flopsなので、おそらくGCNと同じデザインは採用してない可能性は高い。
最後にやや気になる点があるとすれば、64flops/cycleという書き方だ。
CUは基本、積和算(FMAorMAD)に対応してるため1サイクルあたりのスループットは×2になる。それを考慮した場合、2(MAD) × 64(core) × 2.23(GHz)＝285(Gflops)という結果になるため、これではサーニー氏のコメントと一致しなくなる。
おそらくサーニー氏は単純にMADではなく、AddかMulかの一方の計算のみの値を言及したのかもしれないし、あるいはハナからTempest EngineはMad演算に対応していないということなのかもしれないが、そこらへんまでは詳しく言及されていない。
もしくはCUのコア数が64基→32基に変更されてる可能性も考えられる。
先ほど説明したRDNAアーキテクチャならWave32 x2実行であるため、コア数を半減させれば一つのWave32で実行できる。
これなら2(MAD) × 32(core) × 2.23(GHz)＝142.72(Gflops)ということで辻褄があう。
現時点での説としては
64コアの積和算に対応してないモデル{64(flops) × 2.23(GHz) = 142.72(Glops)}
32コアの積和算に対応しているモデル{2(MAD) × 32(core) × 2.23(GHz)＝142.72(Gflops)}
これらが最有力候補だと推測する。
CellのSPEライクなアーキテクチャ
次に”CellのSPEライクなアーキテクチャを使ったオーディオエンジン”という点を掘り下げてみよう。
Cellは知る人ぞ知る、PS3のメインプロセッサである。あらゆる通常の演算を行うCPUコアとしてPPE(PwerPC Processor Element)と呼ばれるものの他に、非同期並列演算に特化したSPE (Synergistic Processor Element)と呼ばれる演算コアを組み合わせたプロセッサだ。当時としては珍しい異種混合型のマルチコアプロセッサだった。
なぜサーニー氏がCellに焦点を当てたのかというとCellの特殊性と優位性がここで輝いたというのがしっくりくるかもしれない。ここで重要なのはCellの中でもSPEのほうである。
SPEとの共通点として挙げられるのは
帯域幅は20GB/s程度とキャッシュを持たないDMA転送ということ
帯域幅は20GB/s程度というのはSPEとIO間の帯域幅と大体、一致しているため、Tempest EngineでもCellと同じような環境下で使えるとも言えるが、オーディオで20GB/sという帯域消費はかなり大きいためGPUなどの帯域喰らいと要相談ものだろう。
次にキャッシュを持たないDMA転送についてだ。
SPEの場合、メモリとのやり取りはすべてDMA転送(Direct Memory Access)を使うことが前提だ。
DMA転送というのはCPUを使わずに各デバイスがそれぞれ独立してデータ転送を行う処理のことを言い、今回の場合はCellのPPEを使わずSPEとメモリが直接データのやり取りを行うことを言う。
ちなみに、SPEに何故キャッシュがなくDMA転送を標準にしたのかという理由は、当時としてあれほどのCPUコアでキャッシュシステムを組むのは難しかったことと、SPEの演算性能を生かすにはある程度纏まったデータで処理するほうが効率が良かったと言われている。そのうえキャッシュがある場合、キャッシュミスしたらメモリアクセスなどでレイテンシが発生するためSPE内での演算効率が著しく低下する。
それを避けるためキャッシュを実装せずローカルストア呼ばれるSPE専用の小規模メモリを実装した。ローカルストアにはSPEが処理する命令とデータを一まとめに格納することにより纏めたデータを纏めて処理することができるのでSPEの演算効率を高めやすいという。また共通のキャッシュシステムがないため各SPE間での同期処理(キャッシュコヒーレンシ)を行う必要もないこと、そのためタスクを各SPEに効率よく分散できるようになり、それぞれのSPEの演算効率を高めたまま並列処理ができる。
この場合、キャッシュシステムがないため再起処理やメモリアクセスなどでキャッシングが効かないデメリットなどが存在するが、SPEの演算効率を限りなく高めるためにはキャッシュレスであることと、それを補うためにDMA転送が必要だったということである。
まとめ
Tempestは面白い。
というのが個人的な感想だ。
オーディオプロセッサでGPUコアをそのまま使うというのもなかなか面白いアプローチの仕方でもあるし、CellというDSPチックなアーキテクチャ経験のあるサーニー氏だからこそ考えつける発想だと言える。
最後に予想図を置いておく。
案の定、オーディオブロックなどは全部除いてある。
それでは。
