ゲームコンソールへの採用もきまったJaguar Coreコア

さてそのKabiniやTemashは、完全なSoC(System On Chip)である(Photo16)。

Photo16:これはKabiniの例だが、Temashも若干外部のI/Fが異なる程度で、基本は同じ

競合の製品をみると、CloverTrailやまもなく登場するHaswellもSoCなどと呼ばれている場合もあるが、実際はパッケージこそ1つにまとまっているが、内部は複数のダイから構成されているSiP(Silicon in Package)であり、これに比べると一歩先んじた感はある。

さてそのTemash/Kabini、冒頭で述べたとおりJaguarコアのCPUとGCNベースのGPUを組み合わせた製品である。この組み合わせは、SONYのPS4に加えてMicrosoftのXbox Oneでも採用が決まったことで、割と長く使われることになりそうなものとなっている。GCNについてはこれまでも多く説明してきたが、Jaguarコアに関してはあまり説明してこなかったので、この機会にちょっと説明をしたいと思う。

Jaguarコアは第2世代のBobcatという扱いになる。基本はBobcat同様、小規模なOut-of-Orderのスーパースケーラプロセッサである。ただし拡張命令に関しては、ほぼBulldozerに準拠したものとなっている(Photo17)。

Photo17:AVXに加えてAMDの独自拡張命令であるXOP/FMA4にも対応。物理アドレスは40bit(1TB)までサポート。ちなみにここからのスライドは、2012年のHot ChipsでAMDが公開したものを利用している

その新しいJaguarコアであるが、4つのコアとL2 I/F、それとL2キャッシュ(最大2MB)を一つのCU(Compute Unit)として取り扱う仕組みが取り入れられている(Photo18)。

Photo18:PS4とかXbox Oneの8コアは、なのでこのCUを2つ搭載しているものと思われる

パイプライン構成も、基本はBobcatのものを踏襲しているが、まずFront Endでは新たにLoop Bufferが取り入れられたり、動作周波数を引き上げるためDecode段を増やしたりといった工夫が盛り込まれた(Photo19)。

Photo19:loop bufferはIntelで言うところのLoop Stream Detector(LSD)に相当するものではないかと思う。要するに繰り返し処理を検出して、この場合はDecode済の命令をパイプラインに流すことでDecode段をとめることで省電力を図るというもの

整数演算のOut-Of-Orderも、同時に処理できる命令数そのものは変わらないが、スケジューラやROBのサイズを増やすとともに、一部の命令処理の高速化を図ったとしている(Photo20)。

Photo20:Hardware Dividerの詳細は不明。たとえばIntelがPenrynで搭載したRadix-16 Dividerは整数だけでなく浮動小数点演算を高速化するのがメインだったが、Photo21を見る限り浮動小数点演算に関してはそうした改善はなされていないようだ

浮動小数点演算に関しては、AVXに対応して演算ユニットの128bit化を図ったのが最大の違いである(Photo21)。

Photo21:勿論AVXは256bit命令なので、AVXに関しては2cycleを要することになる。ここでもRegister Fileのステージを増やすことで動作周波数の引き上げが可能になったとしている

Load/Storeユニットに関しては、もっぱら効率改善がメインで、特に新機能というものは見当たらない(Photo22)。

Photo22:128bitのデータパスは、FPUが128bit化されたことへの対応である

最後のBus Unitは、Photo18で出てきたL2 Interfaceに相当する部分であるが、ここも新機能というものはないが性能改善が図られたとしている(Photo23)。

Photo23:データを8つ、命令を3つ、In-Flightの形で処理できるとしている。命令に比べてデータのIn-Flight数が多いのは、AVXのサポートで同時に扱うべきデータ量が増えたことによるものと考えられる

Photo24がJagureのPipeline構造であるが、整数命令であれば13ステージ程度で、これは昨今のトレンドから考えればそれほど多いものではない。それでもBobcatと比べてPipeline段数を2段増やしたことで、他の条件が同じであれば動作周波数を10%引き上げられるとしており、これも性能改善の一助となる。

Photo24:ただパイプライン段数を増やした(おそらくDEC2)ことにより、分岐ミス時のLatencyが1増えたとするが、これはまぁ仕方ないところだろう

で、性能は?ということでIPCと性能/消費電力比を比較したのがこちら(Photo25)。

Photo25:"Bobcat Virus"はBobcatに最適化したアプリケーション、"Jaguart Virus"はJaguarに最適化したアプリケーションを示す。"Gater Efficiency"はClock/Power Gatingによりどれだけ効率が良いかを示す指標

通常のアプリケーションの場合でIPCは0.95→1.10、Bobcatに最適化したアプリケーションでも若干IPCは改善しており、Jaguarに最適化すると2倍以上改善するとしている。

Jagureコアそのもののフロアプランはこんな感じ(Photo26)。Bobcatと比較した場合、一回り小さくなっていることが分かる(Photo27)。

Photo26:Integer(整数演算ユニット)とROB(Re-Order Buffer)があんまり大きさが変わらないとか、MicroCode ROMの大きさも結構馬鹿にならないとか、いろいろ興味深い

Photo27:面積そのものも4.9平方mm→3.1平方mmで50%以上縮小しているが、それより大きいのはIP macroの削減が進んでいるところ。それぞれのフロアプランで白い小さな四角の部分がこのIP macroで、このmacroの利用が減っているというのは相対的に最適化が進んだと考えて良いだろう

Temash/Kabini全体のダイ写真はこんな感じ(Photo28)であるが、斜めになっている関係で比率が正確には分からない。そこで、JagureコアがPhoto26と同じ比率になるように補正を掛けたのがこちら(Photo29)。

Photo28:こちらはAMD提供のもの

Photo29:もっともPhoto26が本当に正しい縦横の比率なのかは不明である

ここから推定すると、4コアのTemash/Kabiniのダイサイズはおおよそ116.8平方mmと推定される。ダイ、というかパッケージ写真としてはTemashのものが公開されており(Photo30)、パッケージが26mm角だとすると、ダイサイズはおおよそ119.8平方mmと読み取れる。そんなわけで、ダイサイズはおおむね120平方mm弱、と想像される(Photo31)。

Photo30:ダイは正方形よりも微妙に縦方向が長い程度

Photo31:こちらはおまけであるがパッケージ裏面写真。FCHまで統合している関係で、さすがにball数が多い

話がちょっと前後してしまうが、Temash/Kabiniは別にJaguarコアだけで構成されるわけでなく、GCNベースのコアやNB/FCH/Memory Controllerなども統合されている。このあたりについてもちょっと説明しておきたい。

前世代、つまりZacateの世代の場合は、単にCPUとGPUでMemory Controllerを統合しただけというレベルであったが、Temash/Kabiniの世代では、きちんとCache/Memory Coherencyを確保した構成となっている(Photo32)。

Photo32:GPUはNorth Bridgeに直接アクセスするためのバス(Graphics Memory Bus)とは別に、Cache CoherencyをとるためのFCL経由のLinkを搭載している。ちなみにFCL Linkは128bit幅の双方向、Graphics Memory Busは256bit幅の双方向となっている

また消費電力低減はTemash/Kabiniにおける主要なテーマの一つであり、単にCPUコアを省電力化するだけでなく、システム全体としての消費電力低減を考えたものになっている。

面白いのは、CPU CoreとGPU Coreが隣接していること(Photo33)で、GPU中心な処理の場合はCPU Coreが(Photo34)、CPU中心な処理の場合はGPU Coreが(Photo35)それぞれヒートシンクとして作用することで、うまく熱の分散を図っている事だ。

Photo33:ここで初めて、Temash/Kabini全体のフロアプランが出てきた。Photo29の写真を、左に90°回転させた形になる

Photo34,35:どちらにしても発熱の中心はダイの中心部となるので、これをカバーするようにヒートシンクを設ければうまく冷却ができることになる

ちなみにCPUコアに関しては、消費電力ベースの制御を行っていることが示されている(Photo36)。

Photo36:ここでもう一つ判るのはコアの消費電力。Jaguarコアは待機時は0.02W、1GHz動作で1W、1.2GHz動作で1.5W、1.4GHz動作で2Wという消費電力になっている

その制御方式の詳細がこちら(Photo37)。4つのコアの温度と消費電力を動的に監視し、さらにGPUやDisplayなどの消費電力の情報も加味してTurbo Coreの倍率を制御しているという話であった。

Photo37:この制御そのものはFCH側でやっている可能性もあるが、今回は完全にSoCなので、それによる遅れ(従来型の場合、FCHとCPUが別なので、通信の遅延が無視できなかった)は考えなくて良いのだと思う

次のページ:今回の評価環境