Mali-T622/Mali-V500

GPU周りに関しても同様に、Jakub Lamik氏(Photo09)にもう少しお話を伺った。

Photo09: Jakub Lamik氏(Graphics Product Manager, Media Processing Division)

まず最初はMali-T622について。Mali-T622はMidgard Generation 2に属する製品であり、構成的には同社がこれまで提供してきたMali-T624/T628と変わらない。違いはT-624/628が最大4/8 Shader Groupであるのに対し、T-622は最大2 Shader Groupであるだけであるとする。なので、例えばT-624を2 Shader Groupの構成で使った場合とT-622は「全く同じ」であるとする。では発表会で説明のあった「最大50%の電力削減」はどうやって実現しているか、についてLamik氏は「3種類のテクニックがある」とした。1つ目はH/W Optimizationで、Mali-T622がターゲットとするMid RangeのSoCに向けた回路構成とすることで消費電力を削減したとする。2つ目がS/W Optimizationであり、要するにドライバやライブラリの最適化を進めたという話。ただしこれはMali-T622専用という訳ではなくMidgardアーキテクチャを採用するすべてのGPUで効果があるとした。最後がSystem Level Optimizationで、Usage Modelにあわせた電力管理を行うという話である。

ちなみに「ではSoCベンダーはMali-T622ではなくMali-T624の2 Shader Group構成でも良いのでは?」と確認したところ、明確な回答こそはなかったが若干ライセンス/ロイヤリティに違いがあって、安くあがるという事らしい。要するに製品価格が厳しい(＝原価を低く抑えないといけない)Mid Rangeの製品向けSoCのために、最大構成に制限を設けてその分少し価格を抑えるという形で差別化したようだ。

またMail-T622のPOP IPがTSMCの28nm HPMのみ提供され、GLOBALFOUNDRIESの28nm SLPでは提供されないことに関しては「基本的にそうした事情は我々ではなくFoundryに聞いてほしい」としながら、別に提供しない訳ではなく、単に現時点ではTSMCの28nm HPMのみという事であった。要するにGLOBALFOUNDRIESの28nm SLPでは性能的に十分なものが出ないのだが、だからといってGLOBALFOUNDRIESの28nm HPPは利用可能な時期のめどがたってないので、これの目処がたつまでPOPの形では提供しない(or 28nm SLPでMali-T622を作ろうという顧客があんまりいない)というあたりではないかと思う。

もう一つの大きな目玉がMali-V500である。ARMのコミュニティにはいくつかのサードパーティーが提供するCodecが並んでいるほか、「実はARMもEncoder/Decoderは提供していた」(Lamik氏)そうだ。ただ従来提供してきていたのはSD解像度以下で、対応Codecもそう多くなかった。これに対してMali-V500はFull HDに対応しており、最大で4Kまでの解像度で120fpsのEncode/Decodeが可能となっており、「Full HDに対応した初めてのEncoder/Decoderである」とする。

そのMali-V500、内部には最大8つのコアを搭載しており、コア1つで2Kの60fpsに対応するため、8コアで4K/120fpsに対応できるという計算だ。ただ4KといえばCodecとしてH.265を期待したいところであるが、Mali-V500はH.265には未対応との事。「現時点ではまだH.265は完全に標準的になったわけではないので、当面H.265のEncode/Decodeが必要であれば、それはCPU+GPUで対処することになる」という話であった。ちなみに現時点でのV500の対応フォーマットは明確ではないが、「主要なフォーマットには対応している」という話だった。ただ将来H.265が標準になったらドライバの更新だけで対応できるようになるのか? というとそういう話では無いそうで、将来のVシリーズ製品でH.265に対応という形になる模様だ。

さてそのV500のCoreであるが、これはFixed FunctionとProgrammable Functionが混在したもので、多少のプログラミングの自由度はあるものの、全部が全部Programmableという訳ではないそうだ。そもそもMali-V500の目的が、大画面/高画質化するEncode/Decodeの要求に対し、よりCost & Power Efficiencyを高めるためという話であり、なのでフォーマットが確定しているCodecは可能な限りFixed Functionの形で実装するほうが有利である(逆にプログラミングの自由度が必要なら、GPGPUを使えばよい)。以前はこうしたニーズが低かったから、CPUあるいはGPGPUを使う形で対処できたが、ハイエンドのTabletはすでに2Kを超える解像度を持つ時代であり、また動画そのものも従来のSDからHDに移行している現状では、専用ハードウェアを搭載したほうが、性能を高く保ちながら低消費電力化もできるし、結果的にダイサイズの節約になるという事であった。

この話はH.265のサポートにも繋がる。H.265の処理負荷の高さを考えると、これを全部ハードウェアで実装するとかなりの回路規模になり、これはダイサイズの肥大化や消費電力の増大に繋がる。H.265のコンテンツが流通し始める時期までは、無理にH.265をサポートしてもメリットが無いという事なのであろう。

ちなみに現状、V500はHSAには未対応である。正確に言えばCache Coherencyはサポートされていない。MMUそのものはLarge Pageにも対応しているが、V500そのものの呼び出しは事実上CPUから呼び出して使う形のみに限られる事になる。またV500のコアの機能はEncode/Decode＋αであり、映像のPre/Post Processingとかカメラ制御などの機能は持っていないとする。従来だとSoCベンダーはISP(Image Signal Processor)という形でこうした機能を搭載しており、いくつかのメーカーの場合はこのISPの中に動画のEncode/Decodeを含む形で実装していたが、Mali-V500は純粋にEncode/Decodeのみをサポートするだけである。このあたりについてLamik氏は「これまではEncode/DecodeはSoCベンダーがIn-Houseで開発することが多かったが、今では標準的な機能になってきており、なのでMali-V500が受け入れられる余地は大きい」とする。逆にPre/Post ProcessについてはCPUとかGPGPUでカバーできるし、またSoCベンダーの製品差別化の武器でもあることから、ISP全体を置き換えることは考えていないという話であった。

ちなみにMali-V500に関しては現状POP IPなどの提供はないが、これは顧客からの要望が高ければ検討するという話だった。POPを作るのは、相応の期間とエンジニアリングコストが必要になるから、その費用をカバーできるほどのニーズが集まらない限り、ARMとしても何でもかんでもPOPを提供するという訳にはいかないのだろう。特に今回はMali-Vシリーズの最初の製品だから、まずはこれで様子を見てからということなのではないかと思う。

最後にImagination TechnologiesのPowerVRシリーズとの競合について尋ねたところ「5年前まではImaginationに居たんだ」(本当にこの業界は狭い)と前置きした上で「競合があることは望ましいと思うし、我々の製品は急速に売り上げを伸ばしているので、十分競合できると思う。もちろん、いつImaginationと同等のシェアに達するかは予言できないが」という返事であった。