月別アーカイブ: 2012年11月

Silicon Studio MOBILE GPUMARK のスコア比較

ベンチマークソフトを手持ちのデバイスで試してみました。

Sillicon Studio MOBILE GPUMARK

MOBILE GPUMARK                             GEMS   DP   NB   GPU Total
---------------------------------------------------------------------
iPhone5             A6  PowerVR SGX543MP3   751  902  474  4068  6195
iPad4               A6X PowerVR SGX554MP4   665  729  429  3943  5757
iPad mini           A5  PowerVR SGX543MP2   582  695  362  2852  4491
Nexus 7             Tegra3 ULP GeForce(12)  362  623  231  3271  4487
EVO 3D ISW12HT      MSM8660 Adreno220       431  564  245  2235  3475
iPod touch5         A5  PowerVR SGX543MP2   385  450  239  2338  3412
Galaxy S2 SC-02C    Exynos4210 Mali-400MP4  577  730  174  1196  2677
Optimus Pad L-06C   Tegra2 ULP GeForce(8)   121  220   81  1838  2260
Galaxy Nexus SC-04D OMAP4460 PowerVR SGX540 160  161   63  1273  1657
HONEYBEE 101K       APE5R PowerVR SGX543MP  407  572  240 10673 11892 ※無効

・数値が大きいほうが高速。スコアは v1.0 時のもの
・GEMS=RIGID GEMS, DP=DEAD PARKING, NB= NATURAL BONE, GPU=GPU BENCHMARK
・CPU はすべて dual core 以上

iPad4 より iPhone5 の方が良い結果でした。
画面の解像度が小さい方が多少有利に働くのかもしれません。

SC-04D は非常に低速で、ひと通り完了を待つだけでもかなり時間がかかりました。
見かけの速度は速いですが、SGX540 はやはりひと世代前の GPU であることがわかります。
Galaxy S2 はそこそこのスコアですがディザがかかったような画面に見えるのが気になりました。

HONEYBEE 101K が突出した値に見えますが実は描画が正しく行われておりません。
もともとこの端末は OpenGL ES 2.0 で問題が生じることが多かったのですが、
GEMS,DP,NB の描画はラスタ状に一瞬見える程度でほとんど暗転しており、まるで
V-Sync を待たずにフレームバッファがクリアされているような画面になっています。
よってこのスコアは無効です。

GPU BENCHMARK の内容をさらに詳しく比較したのが下記の表です。

GPU BENCHMARK                 fill high many vert spec  pix norm  420  800 1280
-------------------------------------------------------------------------------
iPhone5      PVR SGX543MP3     538   82  242 1013  871  343  310  364  203  102
iPad4        PVR SGX554MP4     403  137  296  765  726  412  393  234  269  172
iPad mini    PVR SGX543MP2     484   62  158  640  560  241  222  274  144   67
Nexus 7      Tegra3 ULP GF(12) 185   56  116  828  571  288  235  667  218  107
EVO 3D       8660 Adreno220    283   98  123  384  378  320  279  191  132   47
iPod touch5  PVR SGX543MP2     286   39  130  601  513  183  164  243  123   56
Galaxy S2    4210 Mali-400MP4  253   37   26  193  138  159  145  196   29   20
Optimus Pad  Tegra2 ULP GF(8)   75   22   77  572  409  125  102  317   98   41
Galaxy Nexus 4460 PVR SGX540    87   31   48  302  265  190  131  134   62   26
HONEYBEE101K PVR SGX543MP     7768   72   91 1038  595  385  416  161  102   45

・数値が大きいほうが高速。スコアは v1.0 時のもの
・fill=Fill Test, high=High Polygon Model, many=Many Models
・vert=Per Vertex Lighting, spec=Per Vertex Lighting & Specular
・pix=Per Pixel Lighting & Specular, norm=Per Pixel Lighting & Specular & Normal Map
・420=YEBIS Resolution 420x234, 800=YEBIS Resolution 800x450, 1280=YEBIS Resolution 1280x720

PowerVR 系は頂点(vert,spec)とピクセル(pix,norm)のスコアに極端な差が
ついていることがわかります。
Unified Shader である PowerVR 系はピクセル負荷が下がった分だけ頂点性能が
大きく向上します。

同じ Unified ながら全く性質が異なるのが Adreno 220 系で、
頂点(vert,spec)とピクセル(pix,norm)の差がわずかです。
全体の負荷を下げてもピーク性能が上がらない代わりに、ある程度複雑な
ピクセルシェーダーを走らせても性能が落ちにくい傾向があります。

Discrete Shader である Tegra は頂点性能が非常に高いことがわかります。
ピクセル負荷に影響を受けず、Tegra2 でもアンバランスに見えるほど
頂点スコアが高くなっています。
Tegra3 はピクセルも強化されていますが、PowerVR とは異なり
シェーダーの演算能力よりも fill が弱点になっているようです。

Tegra と正反対なのが同じ Discrete の Mali-400MP4 です。
4 core あるのはピクセルユニットだけなので、どうしても相対的に頂点性能が
足りないようです。
spec, pix を比べるとわかりますが、頂点でライティングするよりもむしろ
ピクセルでライティングした方が速くなっています。
GEMS, DP だけを見ると上位に食い込むスコアなので、NB を含めて
ハイポリ系が大きくスコアを落とす原因となっているようです。

HONEYBEE 101K では 420,800,1280 (YEBIS) の描画が完全に壊れていました。
よってこのスコアは正しくないことに注意してください。
それ以外は一見正しく描画されていましたが fill の値だけなぜか突出しています。
この機種だけ Android 2.3 であることも何か関係しているかもしれません。

実際のラインキングを見ると Snapdragon S4 (Adreno225/320) がかなり
上位を占めているようです。

MOBILE GPUMARK – RANKING

ポストエフェクトなどスクリーン系エフェクトは TBDR の PowerVR 等とは
相性がよくなく、Mobile 系 GPU ではあまり用いられていませんでした。
このソフトでは非常によく動いており各種効果による違いもよくわかります。

PowerVR はかなり特徴が偏っているため、PC と同じアプローチだと他の GPU と
あまり差がつかないかもしれません。その点 Tegra の方が素直です。
また highp 演算が多い場合やピクセルの演算命令が複雑な場合は Adreno が有利です。

今後は様々な GPU が登場し、レンダリング手法も幅が広がってくるものと思われます。
Adreno 320 では TBR だけでなく Direct Rendering Mode も使い分けられるので、
このようなケースでも今まで以上に最適化が可能となるようです。

新しい世代の Adreno 320/Mali-T604 をまだ入手できていないので、
機会があればぜひ比べてみたいと思います。

関連エントリ
iPad 4 Apple A6X GPU PowerVR SGX554 MP4 の速度

Windows Phone 8 SDK と Direct3D 11.1

Windows Phone 8 では描画 API として Direct3D が使えるようになっています。
iOS/Android から遅れること 3 年、WindowsPhone でもようやく Shader が
使えるようになりそうです。

Microsoft Windows Phone SDK 8.0

WindowsCE だった WindowsMobile/WindowsPhone 7 までは、
Desktop の Intel/AMD、Mobile の ARM と OS だけでなく
アーキテクチャでも明確な切り分けが行われていました。

Windows 8 RT が Desktop / Tablet で ARM をサポートするようになり、
今後ハードウエアも OS/API も統合されていくものと考えられます。

Windows Phone 8 SDK では開発言語として Native C/C++ が使えるようになり、
描画 API も Direct3D がサポートされています。
iOS/Android 含めたプラットフォーム非依存の共通言語として期待できます。

もっとも WindowsCE の時代、WindowsMobile 6 までは Win32 API と C/C++ で
開発していたので WindowsPhone 7 だけが特別だったのかもしれません。

● Windows Phone 8 SDK

Windows Phone 8 SDK は開発環境が統合されており、
iOS の Xcode のようにインストールするだけで一式揃います。
WindowsCE 時代の eMbedded Visual Tools を思い出します。

注意点は、Windows Phone 8 SDK のインストールに Windows 8 x64 が
必須となっていることです。
その理由の一つに Windows Phone 8 Emulator の Hyper-V があるようです。

インストール時にオプション選択が無いので、対応 CPU では常に Hyper-V が
有効となり、未対応 CPU では Emulator 無しでインストールが行われます。
他の仮想 PC 系ソフトを併用している場合は競合することがあるので注意が必要です。

● Direct3D 11 10Level9

GPU 用 3D API は Desktop と同じ Direct3D11 です。
現時点で Windows Phone 8 が対応する feature level は 9_3 となっています。
よって GPU 機能は OpenGL ES 2.0 と同等で、
Direct3D 11 といっても Geometry/Hull/Domain/ComputeShader 等が
使えるわけではありません。

Direct3D feature levels (Windows)

WindowsVista 登場時に Direct3D10 がリリースされましたが、
DirectX 9 以前とは方針が異なり、一切下位互換を持たない仕様でした。
Direct3D 9 以下 (ShaderModel 4.0未満) の GPU は切り捨てられ、
新しい Direct3D 10 API は Direct3D 10 対応 GPU (ShaderModel 4.0以上)
でなければ使えませんでした。
そのかわり caps といった細かなハードウエア機能のチェックが不要です。

その後 Windows 7 で更新された Direct3D 11 は再び路線を変更し、
DirectX 9 以前と同じように API セットのレベルと GPU のハードウエア機能の
レベルが分離されました。下位互換が復活しています。

Direct3D 11 on DOwnlevel Hardware (Windows)

Direct3D 9/Direct3D 10 相当 (ShaderModel 5.0未満) の GPU でも
ドライバさえ対応していれば新しい API 経由で使えるわけです。
その代償として徐々に caps (feature level) が復活しつつあります。

Feature Level は blog の過去記事だとこのあたり↓で触れています。

 ・2008/11/09 Direct3D11/DirectX11 (4) FeatureLevel と旧 GPU の互換性、テクスチャ形式など
 ・2008/11/06 Direct3D11 Technical Preview D3D11の互換性、WARP Driver

● Windows 8 と Direct3D 11.1

メジャーアップデートだった Vista や 7 とは異なり、
Windows 8 の Direct3D は 11.0 から 11.1 と小規模な拡張にとどまっています。
特に Shader Model が 5.0 のままで、5.1 に更新されていないのは意外でした。

11.1 では GPU のハードウエア進化に合わせたハイエンド向けの機能拡張だけでなく、
むしろ Mobile GPU 向けの機能が大幅に追加されているようです。
時代を反映していると言えます。

例えば D3D11_FEATURE (Caps) の項目が 11.1 で著しく増えています。
Windows 8 RT や WindowsPhone 8 など OpenGL ES 2.0 GPU を
10Level9 でサポートするために必要になったと思われる項目が多数あります。

D3D11_FEATURE_DATA_ARCHITECTURE_INFO の
TileBasedDeferredRenderer はまさに Mobile GPU 向けの Caps で、
D3D11_FEATURE_DATA_D3D9_SHADOW_SUPPORT
SupportsDepthAsTextureWithLessEqualComparisonFilter も
ShaderModel 4.0 以降は標準のものです。

D3D11_FEATURE_DATA_SHADER_MIN_PRECISION_SUPPORT も
OpenGL ES 2.0 なら非常に馴染みが深い代物でしょう。

● Mobile GPU と演算精度

OpenGL ES 2.0 用 GPU で最適化を行う場合、シェーダーの演算精度は
非常に大きな問題となります。
shader 内で highp/mediump/lowp の適切な使い分けが要求されます。

Mobile GPU の比較 : Precision
OpenGL ES 2.0 GLSL precision 宣言と GPU 毎の演算精度を調べる

DirectX の場合、DirectX 9 初期 GeForce FX 5800 系の half 型以外では
演算精度を気にする必要がほとんどありませんでした。

11.1 の HLSL では GLSL の highp / mediump / lowp 同様、
最低限必要な演算精度を宣言ができるようになっています。

OpenGL GLSL          Direct3D HLSL
--------------------------------------
highp   float        float
mediump float        min16float (half)
lowp    float        min10float

OpenGL ES 2.0 同様に、WindowsPhone 8 や Windows RT で
最適化する場合に必要になってくるものと思われます。

● ShaderModel 5.0 アセンブラ命令

いつの間にかマニュアルに載っていました。
アセンブラでシェーダーを記述するわけではありませんがデバッグ時に役に立ちます。

Shader Model 5 Assembly (Windows)

Direct3D 10 (ShaderModel 4.0) 時代は載っていなかったので自分で調べていました。

ShaderModel4.0 アセンブラ命令

● DirectX SDK

Windows Phone 8 SDK と同じように、
Desktop 向け Direct3D 11.1 SDK は Windows SDK に統合されています。

Windows Software Development Kit (SDK) for Windows 8

VisualStudio Express 2012 for Windows Desktop の Windows SDK で
dll 番号を見ると 46 になっていました。

DirectX SDK Version 一覧

関連エントリ
2012/02/24 OpenGL ES 2.0 GLSL precision 宣言と GPU 毎の演算精度を調べる
2008/11/09 Direct3D11/DirectX11 (4) FeatureLevel と旧 GPU の互換性、テクスチャ形式など
2008/11/06 Direct3D11 Technical Preview D3D11の互換性、WARP Driver

iPad mini の軽さと左手の操作

iOS には iPhone (iPod touch) と iPad の 2種類のアプリケーションがあります。

iPhone アプリ     iPhone / iPod touch    3.5inch / 4.0inch
iPad アプリ       iPad / iPad mini       9.7inch / 7.9inch

iPad mini は iPad アプリを外で使えるように、外で使いやすくしたものといえます。
今までよりもさらに気軽に、どこでも iPad アプリを使えるようになりました。

一番これまでと違うと感じたのは本体の軽さと画面の大きさです。

iPad アプリを違和感なく使えるサイズで、iPad よりは小さいものの
今まで使っていた 7inch 端末よりも十分画面が大きいと感じます。
軽いおかげで片手で掴みこまなくても、端をつまむだけでも持っていられます。

主な用途はゲームなのですが、タッチする右手だけでなく
iPad mini を掴んでいる左手も頻繁に動かしていることに気が付きました。

紙に図形を書く場合に、ペンだけでなく紙の方を回転させるのと同じような感じです。
例えば左上の戻るボタンは遠いけど、だいたい半分の距離で届くことになります。
軽さも操作性に直結することがよくわかりました。

残念ながら Retina ではないので、
画面が綺麗なゲームを見つけると iPad 3 や 4 での映像が気になってしまいます。
結局 iPad 4 でもダウンロードして画面を確認して、
安心してから iPad mini で遊びなおす感じに。

iPad ELECOM TB-A12KBA タッチパネルにかぶせるキーボード

iPad などタブレットは画面が大きく、ソフトウエアキーボードも両手で
打てる調度良い大きさになります。
でもホームポジションに手を載せておくことはできません。
そこで ELECOM こんな↓キーボード(?)を使ってみました。

ELECOM アシスタントキーボード TB-A12KBA

キーを押し込むと画面に触れてタッチ相当になる仕組みです。
これなら指先でホームポジションを探すことができ、手を置いても誤動作しません。
押した感じも反応がよく期待が持てそうでした。

しかしながら、実際にホームポジションからタイプしてみると
中下段でかなりの取りこぼしが発生します。

原因はボタンに爪が当たっているせいでした。
静電容量式タッチ画面を爪で操作できないのと同じで、
爪でキーを押してもタッチパネルが反応しません。

ためしに指にアルミホイルを巻いてみたら、どんな角度でもボタンを押せるようになりました。

tba12kba_01.jpg

キーボード全体にアルミホイルを重ねても同じように打てるようになります。
触れている他の指がある場合、またはアルミホイルの面積が大きい場合は
タッチする指の代わりになるようです。

tba12kba_02.jpg

iPad 4/iPad mini A6X/A5 の CPU/GPU 速度

CPU の結果も追加しました。
今回から CPU もグループごとに速い順に並び替えています。

CPU benchmark

GPU に iPad mini も追加しました。

Mobile GPU bench mark

CPU/GPU ともに刷新された A6X が最速です。
GPU はより上位のプロセッサに置き換わってますがまだ同世代。
CPU と同じようにそろそろ次のアーキテクチャが出てきても
良いのではないでしょうか。

CPU では iPad mini の方が iPod touch 5 より速いですが
GHz あたりの演算速度ではほぼ同一の値です。
同じ A5 であることがわかります。

関連エントリ
iPad 4 Apple A6X GPU PowerVR SGX554 MP4 の速度
iPhone 5 / iPod touch 5 の GPU 速度
iPad 3 PowerVR SGX543MP4 の速度