NVIDIA Tegra K1のCPUとGPUのスペック

2014 CESでNVIDIAから(Tegra5と思われていた)Tegra K1のスペックが少し公開されたので、まとめました。

【重要】情報の信頼性は保障しません。

Tegra4の時の記事はこちら

ソース:http://www.nvidia.co.jp/object/tegra-k1-processor-jp.htmlhttp://www.nvidia.com/object/tegra-k1-processor.htmlhttp://blogs.nvidia.com/blog/2014/01/05/nvidia-rips-the-lid-off-tegra-k1-demos-64-bit-mobile-processor-running-android/

—–

■SoCスペック比較

SoC Tegra3 Tegra4 Tegra K1 (64bit)
ISA ARMv7 ARMv7 ARMv8(aarch64)
FPU ISA VFPv3 VFPv4 VFPv4
製造 TSMC 40nm LP/G TSMC 28nm HPL TSMC 28nm HPM
CPU Cortex-A9 r2 Cortex-A15 Denver
コア数 4 4 2
クロック[GHz] 1.21.6(boost 1.31.7) 1.9 2.5
L1キャッシュ(I/D) 32kB(4way,32B/line) +32kB(4way,32B/line) 32kB(2way,64B/line) +32kB(2way,64B/line) 128kB +64kB
L2キャッシュ 1MB 2MB(16way) ?
デコード(inst/cycle) 2 3 ?
発行(inst/cycle) 4 8 ?
実行ポート数(うちALUポート) 4(3) 8(3) ?(7)
省電力CPU Cortex-A9 Cortex-A15 なし
GPU ULP GeForce ULP GeForce Kepler
ALU Vertex 4 + Pixel 8 Vertex 24 + Pixel 48 192
クロック[MHz] 520 672 約950
GFLOPS 12.5 96.8 365
Direct3D 9 level 1 9 level 1 11.0
OpenGL ES 2.0 2.0 3.0
OpenGL NA NA 4.4
メモリ DDR3L / LPDDR2 DDR3L / LPDDR2 / LPDDR3 DDR3L / LPDDR3
クロック[MHz] 1500 1866 2133
バス 32bit 64bit 64bit
帯域[GB/s] 6.0 14.9 17
容量 (up to)2GB (up to)4GB (up to)8GB

—–

Tegra K1には2種類あり、CPUが4+1コアCortex-A15 r3ベースのものと、NVIDIAオリジナル設計の64bit CPUであるコードネームDenverコアを2コア搭載したものがあります。GPUコアはPC向けGPUであるGeForce 600シリーズをベースにしたもので、Tegra 2~4のGeForce 6ベースのアーキテクチャとは異なります。TDPは5W、32bit版が2014年上半期、2014年下半期に出荷予定です。

CPU/GPUの性能はPS3やXbox360を超え、GFXBenchのスコアがAppleが開発したApple A7 SoCより2.5倍高いことをアピールしました。

Huang CEOのプレゼンでは、Unreal Engine 4を動作させたり(物理ベースシェーディングやGI、物理シミュレーション)、64bit版Androidが動いている様子を見せたり、よくわかりませんが車のデモを見せました。

—–

■GPUがKeplerベースとなることの利点

もしGeForce 6xxから機能削減されていなければ、モバイルGPUは非常に面白くなってきます。演算精度は24bitからMax 64bitまで上がり、ジオメトリシェーダを使ったGPUベースの布・パーティクルシミュレーション、テセレーションを使ったLoDシステムの実現、Deffered RenderingやForward+といった最近人気のテクニックが全部使えます。CUDAも動くので、物体認識、流体シミュレーション、暗号処理など、応用範囲がけた違いに広がります。

ちょっとメモリ帯域がぎりぎりかなとも思いましたが、新GeFroce GT630が384コアで64bit DDR3-1800なので、192コアなら耐えきれそうです。

—–

■GPUクロックは約950MHz?

性能評価の手がかりとなりそうなのがこのスライドです。単位が馬力(Horsepower)でよくわかりませんが、下の頭でちょっと隠れているところを見ると、GPUはGFLOPS、CPUはSPECIntのスコアだそうです。

おさらいですが、Xboxは48個の4way SIMDなので、48(SIMD)*4(way)*2(MAD)*500(MHz)=240(GFLOPS)です(超越関数は考慮しない)。PS3はピクセルシェーダが24(SIMD)*4(way)*2(Unit)*2(MAD)*500(MHz)=192(GFLOPS)です。なぜか頂点シェーダの計算能力が図に入っていないようですが、大人の事情なのでしょう。

Tegra K1のクロック周波数を求めてみましょう。Tegra K1は365GFLOPSであると書かれているので、192(Core)*2(MAD)*x(MHz)=365(GFLOPS)という式が成り立ちます。xを解くと、950.52…という値が得られます。950MHzというのはモバイルにしては異様に高い値(というか過去の全モバイルGPUの中でトップ?)で、例えばAdreno 320を内蔵するSnapdragon 800は400MHzです。本当にこれが5Wで動くというのが信じられないのですが、とにかく計算上は950MHzです。

—–

■DenverコアのTegra K1はモバイルにもたらされるのか

(この項の考察は追記2、追記3に続きます)

驚いたことに、Denverコアはやたらリッチなスペックです。1コアあたりのL1命令キャッシュだけで128kBのCPUなんて見たことがありません。パイプライン段数がPentium4のように膨大になりそうな気がするのですが、大丈夫なのでしょうか。

“7-way Superscalar”という表記は少し曖昧な書き方ですが、幸いにも比較としてCortex-A15が3wayと書かれています。Cortex-A15の実行ポートは8つありますが、単純な命令を実行するSimple Clusterが2つ、乗算を実行するMultiply Accumulateが1つあるので、合計して3という計算でしょうか。もしかしたらSimple ClusterとBranch 1つを足して3かもしれませんが、可能性は低いと思います。ということは、ロードストアやSIMDを除いたALUポートが合計7つあることになり、ロードストアやSIMDを含めれば10ポートを超えそうで、スパコン用CPUであるPOWER7の12ポートに迫りそうです。

こうなってくると、本当にモバイルとして耐えうる電力なのかどうか疑問です。シングルスレッド性能を重視して、メニーコア化ではなくビッグな少数コアにする方針はApple A6/A7と同じであり、間違っていないとは思いますが、以前NVIDIAは「Project DenverはHPC向けで、Tegraにはもたらされない」と言っていましたし、難易度が高いように思えます。

そもそもSoCが5Wという時点でスマートフォンに乗せられるレベルではなく、TDP 4W / SDP 2WのIntel Atom Z3740を超える消費電力になります。となると、ひとつ考えらえるのは、クロック(と電圧)を下げたモデルを主流とし、電源が十分に確保できる組み込み機器でのみフルスペックで動作する、という方針です。最悪、GPUコア数を減らしたモデルが出てくるかもしれません。それならTegra4でいいじゃん、というお話になりそうですが。

—–

■じーしんく?じーぴーゆーくらうど?

そんな発表もあったような気がします。フランスからリアルタイム配信でアクションゲームを動かすのはすごいとおもいました(小並感)

—–

走り書きレベルですがTegra K1についてまとめました。まだWhitepaperが公開されていないようなので、公開されたら修正or追記するかもしれません。

—–

■追記1

先に後藤さんに記事を書かれてしまったようです

メモリがLPDDR3-2133 64bitと判明したので、表に書き足しました。GK104からの変更点は、今のところテクスチャユニット半減のみ分かっています。128kB L2キャッシュもそのまま載せてきたのはちょっと驚きです。

一方気になった点が2つあります。プレゼンと違い、消費電力が2Wと書かれています。32bit版だけのなのか、Denverでもそうなのかはわかりません。また、「Keplerアーキテクチャでは、テクスチャパスもロードに使うことが容易になっている」とありますが、これはGK110ベースのCompute Capability 3.5でのみ対応しています。GPUブロック図のSMXにUniform Cacheがあるので、これはGK104をベースにしたComptue Capability 3.0相当のはずで、Tegra K1には当てはまらないのではないかと思います。

—–

■追記2

Anandtechを見ていて、L1キャッシュが128kB+64kBのPC向けCPUが過去に存在したことを思い出しました。今はなきTransmetaのEfficeonです。

Efficeonは、x86命令をコードモーフィングソフトウェア(CMS)により独自命令セットの8way VLIWに変換し、実行していました。Efficeonやその前身であるCrusoeの高電力効率設計の衝撃は大きく、Intelの低電圧版Pentiumの市場の一部を奪いましたが、電力効率重視のアーキテクチャに転換したPentium Mに負けて撤退したことで有名です。CrusoeはALUが1つしかなく、Efficeonはダイサイズが大きくなり電力効率が下がった点が大きな欠点です。

“7-way superscaler”とNVIDIAは言っているので、EfficeonのようなVLIW命令セットではないと思います。しかし、ARMv8命令セットをデコードした後のμOpを、VLIWっぽい形で保持している可能性はあります。L1命令キャッシュ内の命令が(ARMv8命令ではなく)μOp形式で保持していると考えれば、(EfficeonがVLIW命令をL1命令キャッシュに保持していたように、)キャッシュが128kBあっても不思議ではありません。

VLIWではありませんが、L1命令キャッシュにμOpを入れ込むCPUは他にもあります。Pentium4のトレースキャッシュです。スペック表には12k μOpと書かれていますが、これは128kBに相当するそうで、ここでも128kBが登場します。Pentium4のトレースキャッシュは分岐予測性能が低く、またデコードも1命令/cycleと低かったため、失敗しました。

このように、巨大な容量のL1キャッシュに変換後の命令を保持するタイプのCPUは少なからず失敗しています。Denverも同じ穴のムジナになってしまわないか、不安になってしまいます。Denverはx86ではなくよりシンプルなARMv8命令セットなのでデコード能力はある程度ありそうですし、ALUの実行ポートが不足することもなさそうですが、ダイサイズ肥大化の可能性は現時点で否定できず、心配です。

とはいえ、デコーダのボトルネック回避のために、デコーダの周辺を改良して成功したCPUはあります。AMD K7やIntel Atom(Bonnelなど)は、L1命令キャッシュに入る段階でプレデコードが行われます。また、Intel 第2世代Core i(SandyBridge)は、L1デコーダの後段にμOpキャッシュを設け、実行効率が格段に上がりました。x86 CPUだけでなくCortex-A15でもデコーダが消費電力のうち1割ほどを占めており、デコーダ回りを改善する方針自体は間違っていません。

—–

■追記3

ふと思ったのですが、N-way superscalerの指すものは実行ポートではなく、命令デコーダかもしれません。Cortex-A15は3命令デコードなので、Denverは7命令デコードと言いたかったのかもしれません。実行ポートはCortex-A15は8ポートなので、Denverもポート数は8前後かもしれません。

しかし、だとしても7命令デコードというのは少々無茶に思えるので、もう少し調べてみると、NVIDIAがInstruction-optimizing processor with branch-count table in hardwareという特許を出していることを知りました。正直あまり理解できないのですが、ネイティブ命令を独自命令に変換して実行し、変換後の命令を一定期間保持し、再度キャッシュヒットしたら変換後の命令をフェッチする(このシステムのことを指してInstruction-optimizingと呼んでいる)のは間違いなさそうです。

ブロック図が非常に興味深いです。L3キャッシュにデータメモリと命令メモリが接続されており、命令メモリの中に命令変換ユニットトレースキャッシュがあります。デコーダはフェッチユニットの後にありますが、デコードをスルーするパスもあるので、ほとんどの簡単な命令はL3キャッシュに入るより前にネイティブ変換されてしまうでしょう。

さらに面白いのが、出願者の経歴です。あまりハードウェア技術者の名前を知らないのでググってみたのですが、Rupert BrauchとDavid Dunnは元ヒューレットパッカード(HP)でソフトウェアによるレジスタリネーミングや投機的実行の特許を出願しており、Ben Hertzbergは元Intelでトランザクショナルメモリの特許を出願しており、Madhu Swarnaは元IntelでPentium4でのセルの設計で特許を出しており、Ross Segelkenは元Intelで可変長命令の並列デコードの特許を出願しています。

HPとIntelは、以前ItaniumやItanium2プロセッサを共同開発していました。ItaniumはVLIWを拡張したEPICアーキテクチャで、x86命令をItanium命令に変換して実行する仕組みを持っており、この特許との関連性をなんとなく感じます。そもそもProject DenverはARMv8(AArch64)命令セットが確定する前から始まっていたので、CPUのフロントエンドにネイティブ変換を差し込むことで後から命令セットが変わっても対応できるように設計した、と想像できます。おまけに、David Dunnは元Transmeta社員でもあるそうで、DenverはCrusoe、Itanium、Pentium4(のトレースキャッシュ)など行き詰ったアーキテクチャがまとめて襲ってきたような恐ろしいCPUに見えます。成功すれば、CPU界隈はかなり面白いことになるでしょう。

参考までに、NVIDIAが出願したDenverに関係ありそうな他の特許も紹介しておきます。

Accessing and managing code translations in a microprocessor

Branch prediction power reduction

Instruction cache power reduction

Translation address cache for a microprocessor

Checkpointed buffer for re-entry from runahead

広告

NVIDIA Tegra K1のCPUとGPUのスペック」への1件のフィードバック

  1. denverのもともとの命令でも、構造が不明ですね
    ネイティブでarm v8なのか他のisaなのか
    もとはx86ように作っていた物を流用したとの話もあり、arm nativeではない可能性もありますね
    トランスレータは開発当初は苦肉の策だったかもしれませんが
    よくよく考えてみると、たんにcpu命令を変換するだけでなく
    javaや.netの返還に使えそうな気もするので、以外に儲けものなのかもしれません

    maxwell世代のgpuではフロントエンド的な役割も担うのでこちらでも
    cudaやdriverのコマンドのへんかんにも使えそうです
    また、cpuを取り込むことでdynamic warp formation,dynamic warp subdivisionなども本格的に使えそうです

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中