Archives

June 2010 の記事

OpenGL ES 2.0 / Multitouch に続いて、立体視関連まとめ。

ステレオ 3D 開発関連 (立体視)

テストできる環境もだいぶ増えてきました。


現在使えるマルチタッチ対応 PC や同時認識点の個数、
OS 毎の各種マルチタッチ API など、調べたことを下記のページにまとめました。

Multitouch 関連情報

前回の OpenGL ES 2.0 とともにまめに更新しています。

マルチタッチと言っても 2点のみ認識可能なものが多く、3点以上取れる機種は
限られているようです。
特に 20インチ以上のタッチ対応一体型 PC の場合は、どれも同じ NextWindow の
光学式で 2点までとなっています。

ノート PC の場合は昔からある抵抗膜式をマルチタッチにしたものから、
TabletPC をマルチタッチにした 電磁誘導+静電容量 などバリエーションが豊富です。

店頭でいろいろ触ってみたところ、抵抗膜式で 5点取れる LOOX U G90、
ノートだけどペンが使えない静電容量式のみの Lenovo IdeaPad S10-3t あたりが
比較的特徴的な PC でした。

Multi touch API としてはメジャーなところで Windows 7, Android, iOS (iPhoneOS)
の 3種類試しています。


Mobile GPU の標準 API となっている OpenGL ES 2.0 関連を集めてみました。
対応端末、GPU core その他。

OpenGL ES 2.0



HTC X06HT (Desire) が手に入ったので Qualcomm Snapdragon QSD8250
(CPU core は Scorpion) を試してみました。
この CPU core は Cortex-A8 と同じ ARMv7 ですが設計が異なります。


iPhone は 3G→3GS で CPU 速度が大幅に速くなりました。
CPU Core が ARM11 (ARMv6) から Cortex-A8 (ARMv7A) へと世代交代したため
たとえ同クロックでもパフォーマンスに差が出ます。
ただし浮動小数演算に限っては例外で、むしろ速度が遅くなるケースが出てきます。

ARM11+VFP から Cortex-A8 へ変わったことで浮動小数演算命令は
VFP, NEON 2つの選択肢ができます。x86 の FPU と SSE の関係によく似ています。
以前 NetWalker (Cortex-A8 800MHz) で試した通り、Cortex-A8 の VFP は
非常に低速です。
NEON を使えば期待した速度が得られますが、過去のアプリケーションはどれも
VFP を使っていること、gcc が基本的にスカラ演算は VFP 命令しか出力
しなかったことから本来の能力が発揮されませんでした。
(新しい gcc は未確認)


Android の場合この辺の事情はまた違ってきます。
Android は iPhone よりもサポートするハードウエアの種類が多いため、
NDK も FPU 無しの ARMv5TE を基準にしています。
例えば Qualcomm MSM7201A では iPhone 3G と同じ ARM11 でも VFP がありません。
仮に Cortex-A8 な CPU 上で NDK を使って C/C++ ネイティブなコードを走らせても、
浮動小数演算では NEON どころか VFP 自体活用されていなかったことになります。

先月 (2010年5月) にリリースされた新しい Android NDK r4 ではこの辺が大幅に
改善されました。
ARMv7-A 専用のコードを使用することができ、Thumb2 も VFP も NEON 命令も
活用できるようになっています。
Android OS 2.2 と同時リリースですが、NDK r4 自体は以前の OS にも対応しています。
これで実質的に最適化時の iPhone とのパフォーマンス差は無くなったと言えます。


X06HT (Android 2.1) で NDK r4 で VFP/NEON 命令を走らせることができました。
どうやら Scorpion は Cortex-A8 と違って VFP も NEON と同じくらい速いようです。
むしろ VFP の方が速度を引き出しやすいので、スカラ演算は積極的に VFP 命令を
使った方が良いかもしれません。
よって、単純な VFP を使ったコードなら Cortex-A8 より Snapdragon (Scorpion)
の方がかなり高速に動作する可能性があります。

当初 NEON を使ったコードの速度が VFP と比べて予想よりも遅い結果となりました。
調べたところデスティネーション側のインターリーブで解消したので、参照して
いないレジスタでも、書き込み時の競合でパイプラインストールが発生している
ようです。VFP 命令では問題なかったので、NEON 命令の場合だけリネーミング
されないのかもしれません。

Cortex-A8 は単純に NEON 命令への置換えで済みましたが、Scorpion まで考慮に
入れるとそう簡単ではなさそうです。


● まとめ

・iPhone は Cortex-A8 になって浮動小数演算の速度を引き出すために工夫が必要。
・Android は別の理由で浮動小数演算が遅かったが NDK r4 で同等になった。
・VFP が遅くないので単純な浮動小数演算では Snapdragon の方が速度を引き出しやすい。
・NEON 最適化は Scorpion の特性も考慮する必要あり。


関連エントリ
ARM Cortex-A8 の NEON と浮動小数演算最適化
NetWalker PC-Z1 Cortex-A8 の NEON 命令とメモリ速度
SSE の浮動小数演算速度
NetWalker PC-Z1 Cortex-A8 浮動小数演算の実行速度
NetWalker PC-Z1 Atom と速度比較
Direct3D Mobile と T-01A の Snapdragon