2011/05/16
DirectX 11 Driver Command Lists
NVIDIA GeForce GTX 460 でドライバを v270.61 に入れ替えたら
ついに! Driver Command Lists が Yes になっていました。
Direct3D 11 が出てから1年半、ようやくフル機能使えるようになりました。
関連エントリ
・OpenGL 4.1 GeForce GTX 460
・DirectX 11 / Direct3D 11 と RADEON HD 5870 の caps
・Direct3D11/DirectX11 GeForce の ComputeShader とドライバ
ついに! Driver Command Lists が Yes になっていました。
Direct3D 11 が出てから1年半、ようやくフル機能使えるようになりました。
関連エントリ
・OpenGL 4.1 GeForce GTX 460
・DirectX 11 / Direct3D 11 と RADEON HD 5870 の caps
・Direct3D11/DirectX11 GeForce の ComputeShader とドライバ
2011/05/15
Android 3.0 の改良点
Optimus Pad L-06C で使ってきた Android Tablet も 3台目です。
Android 3.0 は色々改良されていて良くなっています。
その一つが以前書いた内部ストレージの扱いです。
使いづらかった部分やハードごとの互換性問題を1つ1つ丁寧に
取り除いているようです。
例えば機種ごとに配列が異なっていて、統一性がなかったハードウエアキーも
無くなりました。BACK, HOME などのボタンは画面のシステムバーの上にあります。
・機種ごとに配列が異なることがなくなった
・向きに依存せず常に画面左下にあり場所が固定されていて分かりやすい
・周囲が暗くても確実にボタンを判別できる
そのかわり
・システムバー(ステータスバー)の位置が画面の上端から下端に変更された
・画面下部に常にシステムバー(ステータスバー)とボタンが表示される
BACK, HOME がないと操作できなくなるので、フルスクリーンアプリで
あっても常にシステムバーが表示されるようになりました。
アプリが使える画面の面積は 2.x 時よりわずかに少ないことになります。
●アプリ管理
Android 2.x までのアプリケーション管理は iOS と違い、設定の中にある
専用の一覧画面で行います。
Home 画面への配置、実行、アプリ削除、などの方法がどれもばらばらで
最初は分かりにくいと思いましたが、よく考えると Windows PC も同じです。
その点 Android 3.0 は iOS に近づきました。
アイコンが並ぶアプリ一覧画面から、アプリ実行と Home 画面への配置
だけでなくアンインストールや管理ができるようになっています。

アンインストールはアイコンをドラッグして上のゴミ箱へ運ぶだけです。
右上の info マークへ運ぶと詳細が開きます。
マーケットボタンも右上に配置されており、入手から実行、削除までが
ひとつの画面でできるようになりました。
ソフトウエアをインストールすると Windows のインストーラのように
Home 画面にアイコンが配置されています。
●その他気がついたこと
・MENU ボタン
BACK, HOME は左下に配置しますが、Honeycomb のメニューボタンは右上
アクションバーにあります。
2.x 以前のアプリを起動した場合は互換性のため、システムバーの並びに
メニューボタンが現れます。
・検索ボタン/タスクボタン
2.x 以前はあれだけ主張していた検索ボタンがなくなっています。
タスクは HOME 長押しではなく専用のボタンが配置されるようになりました。
・ステータス
右下の時計エリアタッチで詳細がポップアップします。ポップアップした
ウィンドウをもう一度タッチすると、明るさ調整や画面の回転ロック、
モード切り替え、などの設定変更ができます。
設定用のウィジットを Home 画面にたくさん並べなくてもよくなりました。
関連エントリ
・Android 3.0 LG Optimus Pad L-06C と USBメモリ
・Android 3.0 の内蔵ストレージはわかりやすい
Android 3.0 は色々改良されていて良くなっています。
その一つが以前書いた内部ストレージの扱いです。
使いづらかった部分やハードごとの互換性問題を1つ1つ丁寧に
取り除いているようです。
例えば機種ごとに配列が異なっていて、統一性がなかったハードウエアキーも
無くなりました。BACK, HOME などのボタンは画面のシステムバーの上にあります。
・機種ごとに配列が異なることがなくなった
・向きに依存せず常に画面左下にあり場所が固定されていて分かりやすい
・周囲が暗くても確実にボタンを判別できる
そのかわり
・システムバー(ステータスバー)の位置が画面の上端から下端に変更された
・画面下部に常にシステムバー(ステータスバー)とボタンが表示される
BACK, HOME がないと操作できなくなるので、フルスクリーンアプリで
あっても常にシステムバーが表示されるようになりました。
アプリが使える画面の面積は 2.x 時よりわずかに少ないことになります。
●アプリ管理
Android 2.x までのアプリケーション管理は iOS と違い、設定の中にある
専用の一覧画面で行います。
Home 画面への配置、実行、アプリ削除、などの方法がどれもばらばらで
最初は分かりにくいと思いましたが、よく考えると Windows PC も同じです。
その点 Android 3.0 は iOS に近づきました。
アイコンが並ぶアプリ一覧画面から、アプリ実行と Home 画面への配置
だけでなくアンインストールや管理ができるようになっています。

アンインストールはアイコンをドラッグして上のゴミ箱へ運ぶだけです。
右上の info マークへ運ぶと詳細が開きます。
マーケットボタンも右上に配置されており、入手から実行、削除までが
ひとつの画面でできるようになりました。
ソフトウエアをインストールすると Windows のインストーラのように
Home 画面にアイコンが配置されています。
●その他気がついたこと
・MENU ボタン
BACK, HOME は左下に配置しますが、Honeycomb のメニューボタンは右上
アクションバーにあります。
2.x 以前のアプリを起動した場合は互換性のため、システムバーの並びに
メニューボタンが現れます。
・検索ボタン/タスクボタン
2.x 以前はあれだけ主張していた検索ボタンがなくなっています。
タスクは HOME 長押しではなく専用のボタンが配置されるようになりました。
・ステータス
右下の時計エリアタッチで詳細がポップアップします。ポップアップした
ウィンドウをもう一度タッチすると、明るさ調整や画面の回転ロック、
モード切り替え、などの設定変更ができます。
設定用のウィジットを Home 画面にたくさん並べなくてもよくなりました。
関連エントリ
・Android 3.0 LG Optimus Pad L-06C と USBメモリ
・Android 3.0 の内蔵ストレージはわかりやすい
2011/05/06
Android 3.0 LG Optimus Pad L-06C と USBメモリ
Android 3.0 Table である LG Optimus Pad L-06C には microUSB の
HOST ケーブルが付属しています。
USB メモリや USB タイプの SD カードリーダーなどをつなぐと
一応認識されているようです。
Android の設定画面には現れず、/data の中にあるためファイラーから
フォルダをたどっても見つけることができません。
直接 /data/usbdisk のパスを入力すればアクセスすることが可能でした。
パスを直接入力できるファイラーが見つからなかったので、
アストロ FILE MANAGER の Home フォルダに設定しています。
マウントは自動で行われますがアンマウントする手段がないので、
取り外す場合は一旦本体の電源を切らなければなりません。
HOST ケーブルが付属しています。
USB メモリや USB タイプの SD カードリーダーなどをつなぐと
一応認識されているようです。
Filesystem Size Used Free Blksize /dev 331M 36K 331M 4096 /mnt/asec 331M 0K 331M 4096 /mnt/obb 331M 0K 331M 4096 /system 393M 199M 194M 4096 /data 28G 1G 26G 4096 /cache 393M 6M 387M 4096 /mnt/sdcard 28G 1G 26G 4096 /data/usbdisk 14G 37M 14G 32768 ←ここ
Android の設定画面には現れず、/data の中にあるためファイラーから
フォルダをたどっても見つけることができません。
直接 /data/usbdisk のパスを入力すればアクセスすることが可能でした。
パスを直接入力できるファイラーが見つからなかったので、
アストロ FILE MANAGER の Home フォルダに設定しています。
マウントは自動で行われますがアンマウントする手段がないので、
取り外す場合は一旦本体の電源を切らなければなりません。
2011/05/04
Android 3.0 の内蔵ストレージはわかりやすい
Android 3.0 ではストレージの扱いが大きく変わっているようです。
本体に大容量のフラッシュメモリを内蔵している場合、Android 2.x 以前は
システムとメディアに分かれていて、さらに他に SDカードもあったりして
分かりにくい構造をしていました。(詳しくはこちら)
比べると Android 3.0 非常にシンプルです。内蔵フラッシュメモリは
iOS のようにほぼ単一で区別なく扱えるようになっています。
下記は LG Optimus Pad L-06C (Android 3.0, 内蔵フラッシュ 32GB)
の 設定→ストレージ の画面です。

内蔵メモリの区別がなく、ひとつの領域として扱われているのがわかります。
互換性のため内部では /data, /sdcard と 2つのパーティションが
マウントされていますが、よくみるとディスクが共有されているようです。
区別がないので「SDカードへのアプリケーションインストール」自体が
不要となっています。
3.0 のアプリケーション管理画面には「SDカードに移動」がありませんでした。
↓/sdcard は仮想的なドライブになっているようです。
マスストレージではなく MTP を使った PC との接続であること、
現時点で外付け SD カードに対応していないことなども、
密接に関連しているのだと思われます。
関連エントリ
・Android とストレージ領域
本体に大容量のフラッシュメモリを内蔵している場合、Android 2.x 以前は
システムとメディアに分かれていて、さらに他に SDカードもあったりして
分かりにくい構造をしていました。(詳しくはこちら)
比べると Android 3.0 非常にシンプルです。内蔵フラッシュメモリは
iOS のようにほぼ単一で区別なく扱えるようになっています。
下記は LG Optimus Pad L-06C (Android 3.0, 内蔵フラッシュ 32GB)
の 設定→ストレージ の画面です。

内蔵メモリの区別がなく、ひとつの領域として扱われているのがわかります。
互換性のため内部では /data, /sdcard と 2つのパーティションが
マウントされていますが、よくみるとディスクが共有されているようです。
Filesystem Size Used Free Blksize /dev 331M 36K 331M 4096 /mnt/asec 331M 0K 331M 4096 /mnt/obb 331M 0K 331M 4096 /system 393M 199M 194M 4096 /data 28G 962M 27G 4096 ← /cache 393M 6M 387M 4096 /mnt/sdcard 28G 962M 27G 4096 ← (/sdcard)
区別がないので「SDカードへのアプリケーションインストール」自体が
不要となっています。
3.0 のアプリケーション管理画面には「SDカードに移動」がありませんでした。
↓/sdcard は仮想的なドライブになっているようです。
/dev/block/mmcblk0p4 /data ext4 rw,nosuid,nodev,noatime,barrier=1,data=ordered 0 0 /dev/fuse /mnt/sdcard fuse rw,nosuid,nodev,relatime,user_id=1023,group_id=1023,default_permissions,allow_other 0 0
マスストレージではなく MTP を使った PC との接続であること、
現時点で外付け SD カードに対応していないことなども、
密接に関連しているのだと思われます。
関連エントリ
・Android とストレージ領域
2011/05/02
Snapdragon の本当の浮動小数点演算能力
A5 は Cortex-A9 dual ながら NEON 搭載で一安心でした。(前回)
調べていて気がついたのは Snapdragon (Scorpion) が A5 に匹敵するスコアを
出していたことです。
Snapdragon はあまり詳しく検証していなかったのでもう少し調べてみました。
↑まずは Cortex-A8/A9 の場合です。
上記結果は先日の表の抜粋で、40命令× 1億回数 = 4G 命令のおおよその
実行時間となっています。
1GHz 時に約 4秒なのでほぼ 1命令/cycle となっています。
D が付いているものは「vadd.f32 d0, d1, d2」等の 64bit 命令、
Q が付いているものは「vadd.f32 q0, q1, q2」等の 128bit 命令の結果です。
128bit (Q) は実行時間がちょうど 2倍となっているため、x86 の初期の
SSE 同様 64bit 単位で実行が行われていると考えられます。
vmla (積和) を考慮すると 1サイクルあたり float が 4演算なので、
A8/A9 の NEON は 1GHz 時にピークで core あたり約 4GFLOPS。
↑Snapdragon も 1GHz 時におよそ 4秒で 1命令/cycle に近い数字となっています。
注目すべき点は Snapdragon の場合 D(64bit) と Q(128bit) の実行時間に差が
ないことです。
Cortex-A8/A9 比だと 128bit 演算は 2倍近い速度となっており、
32bit float x 4 = 128bit 単位で実行出来るものと考えられます。
これらの結果を検証するために、128bit で演算が行われているかどうか
テストしましたが、当初は想定した結果にならず Cortex-A8 より遅くなる
ケースもありました。
Snapdragon のスループットは 128bit 時に最高で 2倍となりますが、
その代わり全体的に命令のレイテンシが大きいようです。
遅くなったのは、Cortex-A8 向け最適化だとパイプラインが完全に埋まらず
ストールが発生していたためだと思われます。例えばすぐ直後の命令と
競合していた場合は、レイテンシが大きい方が遅く見えます。
ピークで cycle あたり 8 float 演算が可能なので、Snapdragon の
Scorpion core は 1GHz 時に 8GFLOPS 相当となります。
Dual core の Snapdragon が登場したら、浮動小数点演算能力における
最速の座はあっさりと奪われてしまうことになりそうです。
なお実測したとは言え、理論上のピークを求めるものなので演算結果には
意味を持っていません。実際のプログラムではバス帯域等もありここまで
大きく差が出ないものと思われます。
他にもいろいろ実験してみましたが、Snapdragon の NEON のパイプラインを
無駄なく埋めるのはなかなか困難でした。
関連エントリ
・iPad2 A5 と浮動小数演算 VFP/NEON
・Tegra2 Cortex-A9 と浮動小数演算
・Snapdragon と浮動小数演算速度
・ARM Cortex-A8 の NEON と浮動小数演算最適化
調べていて気がついたのは Snapdragon (Scorpion) が A5 に匹敵するスコアを
出していたことです。
Snapdragon はあまり詳しく検証していなかったのでもう少し調べてみました。
iPad1 A4 Cortex-A8 1GHz vadd.f32 D 4.04sec vmul.f32 D 4.06sec vmla.f32 D 4.57sec vadd.f32 Q 8.12sec vmul.f32 Q 8.11sec vmla.f32 Q 8.13sec
↑まずは Cortex-A8/A9 の場合です。
上記結果は先日の表の抜粋で、40命令× 1億回数 = 4G 命令のおおよその
実行時間となっています。
1GHz 時に約 4秒なのでほぼ 1命令/cycle となっています。
D が付いているものは「vadd.f32 d0, d1, d2」等の 64bit 命令、
Q が付いているものは「vadd.f32 q0, q1, q2」等の 128bit 命令の結果です。
128bit (Q) は実行時間がちょうど 2倍となっているため、x86 の初期の
SSE 同様 64bit 単位で実行が行われていると考えられます。
vmla (積和) を考慮すると 1サイクルあたり float が 4演算なので、
A8/A9 の NEON は 1GHz 時にピークで core あたり約 4GFLOPS。
Desire X06HT Snapdragon QSD8250 Scorpion 1GHz vadd.f32 D 4.35sec vmul.f32 D 4.34sec vmla.f32 D 4.33sec vadd.f32 Q 4.35sec vmul.f32 Q 4.36sec vmla.f32 Q 4.12sec
↑Snapdragon も 1GHz 時におよそ 4秒で 1命令/cycle に近い数字となっています。
注目すべき点は Snapdragon の場合 D(64bit) と Q(128bit) の実行時間に差が
ないことです。
Cortex-A8/A9 比だと 128bit 演算は 2倍近い速度となっており、
32bit float x 4 = 128bit 単位で実行出来るものと考えられます。
これらの結果を検証するために、128bit で演算が行われているかどうか
テストしましたが、当初は想定した結果にならず Cortex-A8 より遅くなる
ケースもありました。
Snapdragon のスループットは 128bit 時に最高で 2倍となりますが、
その代わり全体的に命令のレイテンシが大きいようです。
遅くなったのは、Cortex-A8 向け最適化だとパイプラインが完全に埋まらず
ストールが発生していたためだと思われます。例えばすぐ直後の命令と
競合していた場合は、レイテンシが大きい方が遅く見えます。
ピークで cycle あたり 8 float 演算が可能なので、Snapdragon の
Scorpion core は 1GHz 時に 8GFLOPS 相当となります。
Dual core の Snapdragon が登場したら、浮動小数点演算能力における
最速の座はあっさりと奪われてしまうことになりそうです。
Snapdragon QSD8250 Scorpion 1GHz = 8GFLOPS (NEON 128bit, 8GFLOPS x1) iPad2 A5 Cortex-A9 1GHz x2 = 8GFLOPS (NEON 64bit, 4GFLOPS x2) iPad1 A4 Cortex-A8 1GHz x1 = 4GFLOPS (NEON 64bit, 4GFLOPS x1) Tegra 250 Cortex-A9 1GHz x2 = 4GFLOPS (VFP 32bit, 2GFLOPS x2)
なお実測したとは言え、理論上のピークを求めるものなので演算結果には
意味を持っていません。実際のプログラムではバス帯域等もありここまで
大きく差が出ないものと思われます。
他にもいろいろ実験してみましたが、Snapdragon の NEON のパイプラインを
無駄なく埋めるのはなかなか困難でした。
関連エントリ
・iPad2 A5 と浮動小数演算 VFP/NEON
・Tegra2 Cortex-A9 と浮動小数演算
・Snapdragon と浮動小数演算速度
・ARM Cortex-A8 の NEON と浮動小数演算最適化