ホイール欲しい ハンドル欲しい

backlightwin を作るときに調べたもの。

・MSDN IOCTL_VIDEO_QUERY_SUPPORTED_BRIGHTNESS

LCD デバイスを open します。

HANDLE	hlcd= CreateFile(
		_T("\\\\.\\LCD"),
		GENERIC_READ|GENERIC_WRITE,
		FILE_SHARE_READ|FILE_SHARE_WRITE,
		NULL,
		OPEN_EXISTING,
		0,
		NULL );

バックライトを何段階に調光可能か調べます。

const DWORD	levelbuffersize= 256;
unsigned char	levelbuffer[levelbuffersize];
DWORD		levelCount= 0;
DeviceIoControl(
		hlcd,
		IOCTL_VIDEO_QUERY_SUPPORTED_BRIGHTNESS,
		NULL,
		0,
		(LPVOID)levelbuffer,
		levelbuffersize,
		&levelCount,
		NULL
	);

levelbuffer にはバックライトの明るさテーブルが返ります。
たとえば VAIO type P なら 9 段階に調整可能で、levelbuffer には 9 個の値が
返ります。内容は下記の通り。

4 16 28 40 52 64 76 88 100

バックライトの明るさが 4% から 100% まで、上記の刻みで変更できることを意味
しています。levelCount は返したパラメータのサイズなので、結果として調整可能な
段階に等しくなります。

デバイス(PC)によってこの値も刻み方も変わるようです。
明るさの値 (DISPLAY_BRIGHTNESS の UCHAR ucACBrightness など) は unsigned char
を使うため、テーブルも最大 256 まで。
でも 0～100% の値だから 102 以上のサイズに意味があるのかどうかわかりません。

現在の明るさの読み出し。

DWORD	bytereturn= 0;
DISPLAY_BRIGHTNESS	bright;
DeviceIoControl(
		hlcd,
		IOCTL_VIDEO_QUERY_DISPLAY_BRIGHTNESS,
		NULL,
		0,
		(LPVOID)&bright,
		sizeof(DISPLAY_BRIGHTNESS),
		&bytereturn,
		NULL
	);

bright.ucACBrightness, bright.ucDCBrightness に現在の明るさが入ります。
明るさは IOCTL_VIDEO_QUERY_SUPPORTED_BRIGHTNESS で読み出したテーブルの
通り、必ず 4 , 16, 28, ... 100 の値のどれかになります。
ucDisplayPolicy は現在 AC か DC なのかフラグが設定されるはずですが、
VAIO type P では常に 2 (DC power) が入っています。

明るさを変更する場合。

DeviceIoControl(
		hlcd,
		IOCTL_VIDEO_SET_DISPLAY_BRIGHTNESS,
		(LPVOID)&bright,
		sizeof(DISPLAY_BRIGHTNESS),
		NULL,
		0,
		&bytereturn,
		NULL
	);

IOCTL_VIDEO_QUERY_DISPLAY_BRIGHTNESS で読み出した構造体をそのまま
書き換えて渡せばよいはずです。ucDisplayPolicy のフラグが 3 なら DC/AC
両方を意味するため、より確実に変更が可能となると思われます。
VAIO type P の場合そのままで大丈夫でした。

・backlightwin v1.00

本当はボリューム変更や HID のキー周りも調べたのですが、結局何もしなくても
画面表示がないだけでボリューム変更のショートカットは有効でした。


関連エントリ
・VAIO type P Windows7 beta とバックライト調整など

小型キーボードはたとえキーピッチが小さくなっても等幅の方がタッチタイプ
しやすいという仮説

VAIO type P のキーボードは十分な広さが確保されており、詰まったキーも少なく
押しやすく出来ています。
たまに右側 [_] のキーを押し間違えることがあるのは、おそらく直前まで 1年間
使ってきた EeePC にすっかり手がなじんでしまっているからです。
EeePC のキーボードはさらに横幅が狭く、変形している記号キーも type P より
1列分多くなっていました。

その前に使っていた Let's note R4 もそうだったし、小型のキーボードでは右側の
記号部分の幅が狭く変形しているものが少なくありません。

キーのタイピングは人によって異なるし好みもやり方も多数あると思いますので、
今回はあくまで個人的な内容のお話となっています。


●小型キーボード

こちら でも触れたように、キーボードはすべてのキーが等幅であれば
全体のスケールが小さくなっても意外にタッチタイピング出来ることがわかりました。
もちろんあくまで個人的な感想で、個人的な経験からの判断です。

その昔、普段記号キーも見ないで打っていたのでキーボードに結構拘っていました。
ノートPC もデスクトップと同じサイズでないと打てない、とか思い込んでいたし。

これなら打てる! とかなり気に入ったのが MobileGearII MC/R700 で、すぐに電源が
入って使える便利さに魅了されてその後すぐに MC/R530 を購入。
キーピッチは小さいもののすべてのキーが等幅でしっかりしており、非常に打ちやすい
ものでした。
最初から Ctrl/Caps Lock を交換する機能もあったし、ATOK も入っていたし、IME の
キー割り当ても変更できたのでカスタマイズ性も申し分ないです。

Jornada680～ はさらに一回り以上小さいハンドヘルド PC です。
小さいながらもキーは電卓ボタンではなくノートPC と同じ形をしています。
店頭で Jornada720 触ってみたらぎりぎりだけどホームポジションに全部の指が乗る
ことを発見。
キー配列は等幅で必要なキーがそろっており配列も自然。一部異なっている部分も
カスタマイズで変更可能な範囲でした。
入力はタッチタイピング可能で、議事録なども内容をそのまま記録しつつ、かつ
タイプしながら内容を整理してまとめられるくらいに余裕で打てました。
MobileGearII MC/R530 と Jornada720 は本当に長い間使い込んでいます。

それ以降ここまで使えた小型キーボードにはあまり出会っていません。
小型化のためにキーボードが変形していて、一部キーが他の場所にあったり部分的に
幅が狭くなっていたりするとなぜかだめなのです。慣れるまで非常に時間がかかるし、
慣れてもデスクトップ PC の普通のキーボードを使うときに間違えるようになるし。


●タッチタイピング

タッチタイプできるかどうかの境目は「知識」にあると考えています。
どこに手を置いてどの指にどのキーを割り当ててどうやって指を運んで戻すのか、
これらの基礎知識がないままキータイプを続けてもあまり上達しません。

見ないのにキーを打てるからくりは、すべてのキーをホームポジションからの
相対位置で覚えるからです。
重要なのは必ずホームポジションに手を置いておくこと。

ホームポジションから打ちたいキーに指を出し、一文字タイプしたらできるだけすぐ
ホームポジションに戻す。
この動作が基本で、あとは徐々に上達するごとにホームポジションを経由しない
指の運びを、おそらく決まったフレーズの組み合わせで覚えていくのだと思います。

たとえば [Y] のキーを押した状態から他のキーへ指を運ぶ動作はキーの数だけ存在
します。
この指の運びを、最初からすべてのキーの組み合わせの数だけ覚えるのはちょっと無理。

だけど常にホームポジションに戻ることで、各キーへの指の運びを1つだけ覚えれば
確実にキーを探せるというわけです。


●小型キーボードとタッチタイプ

小型キーボードでキーピッチが詰まった場合も、とりあえず形だけホームポジションに
手が乗れば何とかなります。
サイズが違うためキーの位置も変わっているはずですが、すべて等幅なら比較的容易に
補正することが出来ます。

それは指を出す方向は一緒だから。
伸ばす距離が変わるだけでキーの位置のあたりが比較的容易に付けられるというわけです。

だから一部のキーだけ変形してキーピッチが狭くなっていたりすると、指を運ぶ角度
が変わってしまいます。あるはずの方向に無意識に手を伸ばしても、キーを探すことが
なかなか出来ないのではないかと考えられます。

1. キー配列が変わっていて一部のキーが別の場所に移動している場合
　　そのキーの位置は完全に独自に覚え直し

2. 一部のキーだけキーピッチが変わっている
　　そのキーに対して指を伸ばす方向と距離が変わってしまう
　　角度と距離の両方に対して補正が必要。

3. 全部等スケールで小さくなった場合
　　キー間の距離が違っていても指を伸ばす方向は合っている。

よって 3つのケースでは、全部のキーが等幅の方が一番覚え直すこと、補正する部分が
少なくて済むのではないかと考えられます。

あくまで数字や記号キーを含めてすべてのキーをタッチタイプで入力する前提です。

同じ理由から、EeePC や ELECOM TK-UP84CP 等のように数字の段が微妙に左に
ずれているキーボードは、数字の入力でかなりタイプミスしました。

またせっかく登場した Happy Hacking Keyboard Professional の日本語版も、
最下段 Z X C～ の段が左にずれているので購入を躊躇してしまいます。(悔しい)

・最低限キー配列がそのままであること (シグマリオンや LOOX U のようにキーの位置が移動していない)
・キーピッチを小さくするなら全部まとめて小さくする (部分的に変えない)

これが個人的には理想の小型キーボードです。
だから HTC Shift はかなり気になる存在なのです。


おそらく英語キーボードのスペースに無理矢理日本語キーボードを押し込めた事情が
あるのだとは思います。
それでも全部のキーが等幅な小型キーボードも出して欲しいと切望します。


関連エントリ
・VAIO type P Windows7 beta とバックライト調整など
・DHARMAPOINT キーボード
・Bluetooth キーボード Rboard for Keitai RBK-2000BT2
・emobile EM-ONE 改造その2 ([es]もOK)
・emobile EM・ONE USBキーボードの改造
・東プレ Realforce 買った!

Debian (lenny) を使った設定メモ
Subversion が使えるところまで


●準備

・Debian -- The Universal Operating System

左側の CD ISO images から "testing" distribution をダウンロード。
必要なのは debian-testing-i386-CD-1.iso だけ。


●VirtualBox

今回は VirtualBox 2.1.2 を使っています。

・VirtualBox

(1) 仮想マシン作成
　　新規→ OSタイプ Linux / Debian を選択 → RAM default の 256MB

(2) 仮想ハードディスク
　　新規 → 可変サイズのストレージ
　　　　→ 容量必要に応じて(今回はdefault 8GBを選択) → 完了

swap を使うなら、swap 専用に仮想ハードディスクを分けて作成しておいた方が
良いと思われます。

(3) 作られた仮想マシンを選択して「設定」
　　　CD/DVD-ROM
　　　　　→ CD/DVD ドライブのマウントにチェック
　　　　　→ ISOイメージファイルを選択
　　　　　→ 仮想メディアマネージャに debian-testing-i386-CD-1.iso を追加＆選択
　　　ネットワーク
　　　　　→ 割り当てを「NAT」から「ホストインターフェース」に変更

1.x の時はコマンドラインで設定が必要だったので、ネットワーク設定は以前より
簡単になっているようです。

(4) キーボードの確認
　　　キーボードに右 Control キーがあるならそのままで OK
　　　もし無いなら、メニューのファイル→環境設定→入力
　　　　　ここでホストキーを別のキーに変更しておく

(5) 起動
　　　マウスがキャプチャされた場合(マウスカーソルが消えた場合)は、右 Control
　　　キーで復帰することをあらかじめ覚えておきます。
　　　(4) でキー割り当てを変更した場合はそちら。


●Debian install

(1) 起動した画面で「Install」選択
　　　言語選択 日本語 → あとはインストーラに従う

インストーラのメッセージや手順は etch と同じです。
(PS3 やっぱり Debian 再インストールメモ)

(2) 以下手順

スワップは設定しない方針で。必要になったら別の仮想ハードディスクを作って
割り当てる。または仮想マシンに割り当てる物理メモリ量を増やす。

キーボード配置の選択
　　日本 (106 キー)

ネットワークの設定
　　ホスト名: 任意
　　ドメイン名: 任意

ディスクのパーティショニング
　　手動
	→ "IDE1 マスタ (hda) - 8.6GB VBOX HARDDISK" を選択
	→ 「新しいパーティションテーブルを作成しますか？」 はい
	→ "基/論 8.6GB  空き領域" を選択
	→ "新しいパーティションの作成" を選択
	→ サイズ 8.6GB のまま、続ける
	→ "基本パーティション" を選ぶ
	→ マウントポイントが / なっていることを確認して
		"パーティションのセットアップを終了" を選ぶ
	→ "パーティショニングの終了とディスクへの変更の書き込み"
	→ スワップがないと怒られるけど無視 (いいえ を選ぶ)
	→ 書き込みの最終確認が出るので「はい」

root のパスワード、ユーザーアカウントの設定

パッケージマネージャの設定
　　別の CD や DVD を検査しますか？: いいえ
　　ネットワークミラーを使いますか？: はい
	ミラーを選ぶ
　　Debian パッケージ利用調査に参加しますか？: いいえ

ソフトウエアの選択
　　デスクトップ環境のチェックを外して、ウェブサーバとファイルサーバを追加
　　　　[ ] デスクトップ環境
　　　　[*] ウェブサーバ
　　　　[ ] 印刷サーバ
　　　　[ ] DNS サーバ
　　　　[*] ファイルサーバ
　　　　[ ] メールサーバ
　　　　[ ] SQL データベース
　　　　[ ] ラップトップ
　　　　[*] 標準システム
　　続ける

samba server
　　ワークグループ/ドメイン名: 任意
　　DHCP から WINS 設定を使うよう smb.conf を変更しますか？: はい

GRUB ブートローダのインストール
　　マスターブートレコードに GRUB ブートローダをインストールしますか？: はい

インストールの完了
　　メニューの デバイス → CD/DVD-ROM マウントの解除
　　続けるを選択し再起動、しばらく待つと login: プロンプトになる。

●Debian の設定

(1) root でログインして ssh を入れる

コンソールでそのまま続けても構いませんが、日本語がでないしテキストのコピペが
出来ないので ssh 入れて putty 使います。

# vi /etc/apt/sources.list

deb cdrom:[Debian GNU/Linux testing _Lenny_ - Official Snapshot i386 CD Binary-1 20090119-04:20]/ lenny main
の行をコメントアウトします。先頭に # を付ける。

# apt-get update
# apt-get install ssh

文字化けしてるけど気にしない。何か聞かれるので Y

# vi /etc/dhcp3/dhclient.conf

send host-name "ホスト名"

send host-name の行のコメントを外してホスト名(サーバー名)を書き込む。

終わったらログアウト

・PuTTYjp
puttyjp を起動して、ウィンドウ→変換→文字セットを「UTF-8(CJK)」に変更
ホスト名を入れてログインする


(2) サーバーの設定

以後 root 作業です。

# vi /etc/samba/smb.conf

[homes] の read only を no に変更
read only = no

# smbpasswd -a USER

ユーザーを追加してパスワード登録。('USER' は作成した個人アカウント)
これでファイルなどの転送が Windows の explorer からできます。

# apt-get install subversion
# apt-get install libapache2-svn libapache2-mod-encoding

dav_svn の設定はマニュアルを参考にします。

# more /usr/share/doc/libapache2-svn/README.Debian

/etc/apache2/mods-available/dav_svn.conf を見よ、と 1行しか書いてなかった。

# cd /etc/apache2
# vi mods-available/dav_svn.conf

下記の行のコメントを外す (必要に応じて書き換える)

<Location /svn>
  DVA svn
  SVNPath /var/lib/svn
  AuthType Basic
  AuthName "Subversion Repository"
  AuthUserFile /etc/apache2/dav_svn.passwd
  Require valid-user
</Location>

SVNPath の代わりに SVNParentPath を使うと複数のリポジトリを指定出来るように
なるとのこと。Windows の apache2 で dav_svn を設定するとこちらになるので
前から違うなと思ってましたが、、ここにありました。

# a2enmod auth_basic authn_file
# htpasswd -c /etc/apache2/dav_svn.passwd USER

Basic 認証のユーザー登録。'USER' 部分は置き換えてください。

リポジトリ作成。(既存のリポジトリをコピーして使うなら不要)

# svnadmin create /var/lib/svn

ポート番号などの設定を変えるなら次も書き換える。変更しないなら不要

# vi ports.conf
# vi sites-available/default
# vi sites-available/default-ssl

SSL の設定はやはりマニュアルを参考にする。

# zmore /usr/share/doc/apache2/README.Debian.gz

設定方法が書いてありました。手順通りに実行してみます。

# apt-get install ssl-cert
# make-ssl-cert generate-default-snakeoil --force-overwrite
# a2ensite default-ssl
# a2enmod ssl
# /etc/init.d/apache2 restart

これは self-signed のみのサンプルです。必要に応じて変更してください。
今回の用途は家庭内サーバー用。


(3) 確認

PC や他のマシンのブラウザで確認します。うまくいけば次の通り。

http://作成したサーバー/svn
https://作成したサーバー/svn

ユーザー名とパスワードが必要。空のリポジトリが表示される。


関連エントリ
・PS3 やっぱり Debian 再インストールメモ

画面は 8インチながら 1600x768。
普段デスクトップ PC で使っている PC モニタと横解像度が同じでフォントを最小に
すると、目に痛いくらい広い。でも文字のサイズは VGA の WindowsMobile 端末でも
これくらいだし、本当に痛いのはグレア液晶のせいかも。

近距離で凝視するスタイルには向かないので非光沢フィルタを貼ってみます。
12.1 インチ液晶用フィルタの短辺がちょうどぎりぎり横幅に一致しました。
細長く切って液晶面だけ覆うように貼りましたがこれは少々失敗。

type P は液晶面がフラットで周囲との段差がなく液晶の枠部分にもうつり込みが
あります。もっと大きめに切って貼った方が良かったかも。
なお枠部分は、本体の色によってうつり込みの印象が異なるかもしれません。
ちなみに黒。


●解像度の計算

ドット(ピクセル)密度を計算してみました。
簡単に求めるには次のようにします。

sqrt( 横 ^2 + 縦 ^2 ) / インチ

画素が正方形という前提ですがこれで dpi (ppi) になります。
実際に定規で測ったり、カタログに載ってる ppi と比べたところほぼ一致するので
これで問題なさそうです。
たとえば type P の 8インチ 1600x768 なら

sqrt( 1600 ^2 + 768 ^2 ) / 8

これを google の検索欄にコピペすると結果が出ます。
実例 sqrt( 1600 ^2 + 768 ^2 ) / 8

＞ sqrt((1 600^2) + (768^2)) / 8 = 221.846794

だいたい 222ppi (dpi) 。1pixel が 0.114mm くらい。
1mm 四方に 76pixel ほど詰まっていることになります。

同じようにいろいろ計算してみました。

VAIO type P        1600 x 768  8.0inch = 221.8 ppi
EIZO L887          1600 x1200 20.1inch =  99.5 ppi (公式 dotpitch 0.255mm)
EIZO HD2452W       1920 x1200 24.1inch =  93.9 ppi (公式 dotpitch 0.270mm)
BenQ E2200HD       1920 x1080 21.5inch = 102.5 ppi (公式 dotpitch 0.248mm)
LOOX U (Atom)      1280 x 800  5.6inch = 269.5 ppi (公式 dotpitch 0.0945mm)
LOOX U50 (A110)    1024 x 600  5.6inch = 221.9 ppi
EeePC901           1024 x 600  8.9inch = 133.4 ppi
EeePC701            800 x 480  7.0inch = 133.3 ppi
EeePCS101          1024 x 600 10.2inch = 116.4 ppi
Let's note R8      1024 x 768 10.4inch = 123.1 ppi
XPS M1730          1920 x1200 17.0inch = 133.2 ppi

HTC Touch Diamond   640 x 480  2.8inch = 285.7 ppi
iPhone/iPod touch   480 x 320  3.5inch = 164.8 ppi (公式 163ppi)
WILLCOM 03 WS020SH  800 x 480  3.0inch = 311.0 ppi
W-ZERO3[es]WS007SH  640 x 480  2.8inch = 285.7 ppi
Softbank 930SH      854 x 480  3.0inch = 326.6 ppi
Softbank 931SH     1024 x 480  3.8inch = 297.6 ppi

調べた中では PC だと新 LOOX U (Atom) が一番高密度でした。
全体的に携帯端末の方が密度が高くなっていて、携帯の中には 300ppi を超えるものも
あります。

ppi が高いと密度が増えるので、解像度が高くても画面が広いというより、ドットが
詰まって細かいイメージになります。画素が細かくフォントやエッジのぎざぎざも
見えにくくなります。

PC の画面がだいたい 96dpi を想定しており、同じくらいの解像度でモニタが作られて
いるとしたら、type P でも 2.3倍 面積で 5倍以上。
通常のモニタ比で何もしなくても 4x FSAA 相当が色を圧縮しないでそのままの形で
出ていることになります。HD ムービーなどがきれいに見えるわけです。

269.5ppi の LOOX U だと 9x FSAA 相当に近く、300ppi クラスの携帯端末だと
PC モニタの密度比で 9x FSAA を超えていることになります。

モニタのサイズが違うし再生されるコンテンツの大きさも異なるし視聴時のモニタとの
距離も異なるので必ずしも一概に比較できませんが、高密度なモニタは色数が増える
のと同じで効果あるようです。
そういえば外で Touch Diamond の画面を見ていると、たまに紙のようだなと思うことが
あります。

このまま TV や PC モニタの性能が上がったら、Anti Aliasing とか考えずに逆に
見えすぎる解像度をぼかしたり、どう見せるかの方で頭を使うことになるのでしょうか。
それより当面の問題はテクスチャ解像度が足りなくなること。


関連エントリ
・VAIO type P Windows7 beta とバックライト調整など

VAIO type P 手に入れました。
このサイズはちょうど昔使ってた MobileGearII MC/R530 と同じくらいです。

MobileGear2 MC/R530  245 x 131 x 28.8 770g  8.1inch  640x240 STN 110000円
VAIO type P VGN-P90S 245 x 120 x 30.8 688g  8.0inch 1600x768 TFT 122800円
(P はバッテリーL で重さは実測 = 688g)

かつて長いこと WindowsCE のハンドヘルド端末(H/PC)を愛用していたことがあります。
ボタンを押すとすぐ電源が入って直前の状態から操作できて、バッテリーも結構持つし
HDD レスで遠慮無く鞄に放り込んで持ち歩くことが出来る。
ちょっとしたメモや議事録などテキスト記録用に重宝していました。

狭いキーピッチは最初は無理だと思ったけど、Libretto 100 → MobileGear II →
Jornada720 を経て、すべて等幅で配列さえ合っていればすべてのキーでタッチタイプ
できることがわかりました。最近は右側記号部分のキーピッチが詰まっているキー
ボードばかりで個人的には少々残念。

H/PC が終了して後継機種も無くなってからは、代わりとなる環境を延々と探し続けて
いる感じです。PocketPC + 外付けキーボードだったり Windows NotePC を試したり
WindowsMobile + Bluetooth Keyboard など。
ずっと WindowsMobile で入力系のソフトばかり作ってるのもそのせい。

現在この用途で活躍していたのが EeePC901。少々重いけどバッテリーが持つので
スリープ状態で電源入れっぱなしでも大丈夫。WindowsCE H/PC のようにすぐ使える
機動性がありました。

ほぼキーボード大の本体で薄くて軽い。(ポケットにも入る)
ファンレス ＋ SSD 、バッテリー L なら長時間持つ。
これならかつての H/PC のように扱えるか、と思い type P に飛びついてみました。


●描画は遅い

EeePC901 より速い構成のはずですが確かに遅いです。レスポンスもだし
特にAero が無効となっているためウィンドウの重ね合わせが変わると再描画が
発生します。この再描画の転送が目に見えるため印象を悪くしている気がします。

Aero だと合成がハードウエアなので他のウィンドウを再描画しません。
CPU に負担がかかって処理が落ちても見た目に変化がないので、処理落ちやあらが
目立ちにくいのだと思われます。
EeePC901 では GPU にそこそこパワーがあるため Aero で快適に使えました。

CPU にかかる負担を減らすことが重要かもしれません。とりあえず標準状態で常駐して
いるソフト類、プリインストールソフトを全部捨てて、Vista と Windows7 を
クリーンインストールしました。EeePC のように。

(ちなみに WindowsCE H/PC の描画はもっと遅かった。MobileGearII MC/R700 などは
コンソールのスクロールが波打つくらいに。)


●ドライバの保存

(1) 購入直後の状態でリカバリディスク作成
(2) C:\Windows\drivers の下を丸ごと SD カードなどに保存


●WindowsVista

パーティションを半分にしてまず片方に WindowsVista を入れました。
SSD 128GB にしておけば良かったかも。
もともと Vista PC なので必要なドライバは付属のものそのままです。
(2) で保存したドライバを使用します。

一応 Aero も使えるので実験 (詳しくはこちら)

Fn キーを使ったキーボードショートカットは音量変更のみ使用できました。
画面の明るさ調整が使えないと不便なので、代わりとなるソフトを作りました。

・backlightwin v1.00

実行すると Ctrl + Alt + [F5]/[F6] で画面の輝度(バックライト)調整が出来ます。
もう一度実行すると常駐解除。自動起動するならスタートアップへ。


●Windows7 beta / build 7000

すでに多くの方が挑戦されているので参考にします。

・type P wiki Windows7ベータ

Vista と同じく、最初に保存しておいた付属のドライバを適用します。
無線 LAN は最初から認識していますが、そのままだと 11g になります。
付属の無線LAN ドライバに入れ替えると 11n で 300Mbps で接続可能となりました。

入れたもの
・Chipset Driver (Intel)
・Graphics Driver (Intel)
・Ethernet Driver (Marvell)
・Wireless LAN Driver (Atheros)
・Sony Firmware Extension Parser Driver
・Sony Programmable I/O Control Device

やはり音量調節のみ可能で、画面の明るさ変更は出来ません。
Vista と同じように下記ソフトでとりあえず代用できます。

・backlightwin v1.00


● VAIO type P は結構速い

しばらく作業していて気がついたのは、VAIO type P (SSDモデル) はきちんと
使っていくと結構速いということ。

たとえば Windows7/Vista 等のクリーンインストールは短時間で終わるし、起動や
終了も待たされません。VisualStudio 2008 のインストールも、時間がかかった
EeePC と比べるとあっけなく完了。
EeePC では結局あきらめたけど、type P なら本体でコンパイルする気になります。
RAMDISK も設定しないでそのまま Vista も Windows7 も使っています。

これまで使ってきた EeePC4G/EeePC901 と比べて SSD の書き込みがかなり速いようです。
type P は GPU が貧弱で描画のレスポンスは遅いけど、SSD モデルであれば最初の印象
よりも結構速くて使えると感じました。

もちろん EeePC901 だってより高速な SSD に交換可能だし、ZIF コネクタにつなぐ
タイプなら各種選べるはずです。type P を見てしまうと、EeePC の SSD ももっと
速いタイプに交換したくなります。


ちょうど Eye-Fi が使えなかったことを機にルータを入れ替えたばかりでした。
type P はプロパティの表示で 300Mbps でつながっています。

LAN 接続(Gbit)の Desktop PC から大きめのファイル (DXSDK_Nov08.exe 483MByte)
をコピーして 15MB/sec 前後の速度でした。おおよそ 120Mbps くらい。
へたに SD カードとかを経由してデータコピーするより速いです。

同じく 11n 対応の EeePC 901 はなぜかプロパティの表示で 135Mbps なので、
ドライバが古いだけかもしれません。

PowerVR SGX を採用した Intel US15W の GMA500 は、こちらで調べたように
正直あまり速くないという印象です。
その考えられる要因は次の通り

・シェーダーユニット (USSE) の数が少ない (2個)
・1 ALU あたり 32bit float x1 演算
・公称のピーク性能を達成できるのは 1 ALU で 8bit x 4(ARGB) のレガシーなカラーを扱った場合のみ
・フィルレートは 3D 時の内部 Z オクルージョンカリングを含めたもので実際のバスは細い

シェーダーユニット USSE あたり 1ALU との明確な記述はありませんが、その参考に
なりそうなのが頂点性能です。Transform Only でも頂点あたりに必要な clock 数が
かなり多いことから、1clock あたりの演算能力がかなり低いことがわかります。
(詳細は 前回)

転送能力は 2pix x 200MHz = 400Mpix/sec
Z/stencil 不要なので 64bit x 200MHz = 1.6GB/sec

ちなみに USSE は汎用的な Unified Shader なので、Video/Image 処理にも使われる
(または利用できる) と書かれています。
他に Video Decode Unit が搭載されているので本当に使われているのかどうかは
わかりません。GMA950 系よりは汎用的なのは確かなので、描画以外でも恩恵を
受けられるメリットはあるかもしれません。
もしくは PowerVR がライセンスしている Video Decode 機能自体も USSE の
Video/Image processing に依存している可能性があります。

追記: シェーダーユニットが 2個というのは UnifiedShader 世代のスカラー換算なので、
　ShaderModel 3.0 世代でいえば 0.5 個分ということです。3.0 世代 GPU は複数の
　ALU を搭載していたものが多かったのでそれを考慮すればもっと少ない。


●Windows Aero / Aero Glass と相性が悪い

Windows の Aero / Aero Glass においては ShaderModel 2.0 (PiselShader 2.0) を
利用して Window 描画を行います。そのため、特に PixelShader2.0 以上を使うと
pixel 性能が極端に下がることが致命的だと考えられます。

GMA500 が Windows Aero / Aero Glass と相性が悪い原因

　(1) PixelShader 2.0 以降では Pixel 処理能力が 1/4 以下となる
　　　8bit x4 SIMD mode が使えない、1ALU で済んでいたカラー演算が 32bit float
　　　演算となるため 4ALU 必要となる。

　(2) 半透明の重ね合わせは PowerVR 独自の On Chip Z Occlusion をスポイルする。
　　　おそらく Aero / Aero Glass など Window GUI に必要なのは、
　　　賢く速度を稼ぐ描画ではなく力業の転送能力なのだと考えられます。

根本的な原因はおそらく (1) の方で、(1) の方が処理負担に対する割合が高いと
考えられます。(2) の方が大きな原因であれば、Aero Glass → Aero 不透明に
切り替えることで改善できるはずです。


●PowerVR SGX の性能がわかりそうな資料(1)

前回調べておきながら、取り上げるのを忘れていた資料に OMAP があります。
OMAP は SGX を搭載しています。

・TEXAS INSTRUMENTS OMAP3530

PowerVR SGX といっても様々なグレードがあるため一概に比較はできませんが、
資料を読むといろいろと興味深いデータが含まれています。

OMAP3530
＞ 10MPoly/sec

GMA500 は 13.3MPoly/sec なので若干遅い程度。

さらに上記ページから落とせる下記の資料が参考になります。
　・OMAP35x 2D/3D Graphics Accelerator Reference Guide-TRM Ch 13 (Rev. B) (spruff6b.pdf, 199 KB)

＞ 8 parallel depth/stencil test per clock

チップ内部の pixel 処理能力が 8pixel/clock であることを意味しています。
tile 単位のラスタライズ(以下 SGX の処理内容の予想)

(1) depth/stencil 8pixel/clock (OMAP3530の場合)
　　　すべての Primitive をラスタライズして depth/stencil だけ先に test
　　　Pixel Shader はせず Texture も読まない

(2) deferred pixel shading、(1) を通過した pxiel のみ描画する。
　　　Z が最前面の pixel だけ PixelShader の実行、Texture のフェッチを行う

(3) (2) の出力を最大 2pixel/clock (GMA500の場合) で出力する

(1) は PC の GPU でもよく使用する depth のみの前レンダリング似ています。
GPU の多くはカラー無しの depth/stencil のみの出力では 2倍ほどの pixel レートで
描画できるようになっています。


●PowerVR SGX の性能がわかりそうな資料(2)

ルネサスの SH-Navi3 のニュースリリース

SH7776 CPU 533MHz, 4.27GB/sec, PVR SGX ?MHz
　・RENESAS 業界初、車載情報端末向けに画像認識処理機能内蔵のデュアルコアSoC「SH7776」（SH-Navi3）を製品
　MBX から SGX でポリゴン性能が 2倍

SH7770 CPU 400MHz, PVR MBX 100MHz
　・カーナビに最適な2D/3Dグラフィックスエンジンを業界で初めて内蔵し、さらに、次世代カーナビに必要な機能を1チップにした「SH7770」を製品化

SH7774 CPU 600MHz, PVR MBX MBX 300MHz
　・カーナビ向けSoCで、世界で初めて画像認識処理機能を搭載した「SH7774」を製品化
　SH7770 の3倍


● Intel GMA500 と ShaderModel

実際に Atom Z500 + US15W の Intel GMA500 を搭載した PC を手に入れたので
軽く試しました。

　・ShaderModel3.0 まで

対応している ShaderModel は 3.0 まで。
アーキテクチャ的には Unified Shader で 4.1 (D3D10.1) まで出来そうに見えますが
(wikipedia Intel GMA にも 4.1 と書かれていますが)
ドライバが対応しているのは 3.0 まででした。
VertexShader も PixelShader もハードウエアです。

D3D10CreateDevice1() がエラーになるのは当然としても、少々問題なのは
D3D11CreateDevice() までエラーを返してくること。
本来なら D3D_FUEATURE_LEVEL_9_3 あたりを返してきて欲しいところです。

これが原因で GMA950 なら D3D11 API に移行できるのに、GMA500 では
ShaderModel3.0 でも D3D11 API に移行することが出来ません。
もちろん WARP なら可能です。


● Intel GMA500 と Aero Glass

WindowsVista では Aero / Aero Glass に切り替えられました。
やはり重いです。Aero Glass を切って Aero にすると多少軽くなります。
以下手順。

　◎ Aero Glass に切り替える ---- (A)
　　デスクトップのカスタマイズ→個人設定→ウィンドウの色とデザイン→
　　　　配色「Windows Aero」を選ぶ

　かなり処理落ちしているようで、ウィンドウ操作などがマウスカーソルについて
　こなかったりします。
　下記の設定で半透明を無効にすると、同じ Aero でも若干速くなります。


　◎ Aero の半透明を無効にする ---- (B)
　　デスクトップのカスタマイズ→個人設定→ウィンドウの色とデザイン→
　　　　ウィンドウの色とデザイン→透明感を有効にするのチェックを外す

　半透明を切るだけで結構軽くなりました。半透明というよりも、ぼかしフィルタ
　などのシェーダーコードの実行がボトルネックになっているのかもしれません。

先にパフォーマンスのチェックを全部外しておいてから Aero にすると、もう少しだけ
軽い設定の Aero になります。


　◎ 出来るだけ軽い Aero にする方法

　(1)スタートメニュー→コンピュータの右ボタンメニューでプロパティ
　　　　→システムの詳細設定→パフォーマンス→設定→チェックボックスを全部外す

　(2) ここで強制的に BASIC に戻される

　(3) (A) の設定で再び Aero Glass に切り替えてから、(B) の設定で半透明を無効にする。

見た目は Vista Basic と変わりませんが、上のウィンドウを動かしても重なった下の
ウィンドウに再描画が発生せず、ハードウエアによるアクセラレートが効いている
ことがわかります。

Windows の描画モード

XP
  Luna                    ハードウエア
  Classic                 ハードウエア

Vista
  Aero Glass (透明感 ON)  WDDM ハードウエア 3D描画
  Aero 不透明/Standard    WDDM ハードウエア 3D描画
  Vista Basic             CPU 描画
  Windows Classic         CPU 描画

Windows7
  Aero Glass (透明感 ON)  WDDM ハードウエア 3D描画
  Aero 不透明/Standard    WDDM ハードウエア 3D描画
  Basic                   ドライバが対応していればハードウエア

Windows7 では Aero を有効にすることが出来ませんでした。
ドライバにまだ問題があるのかもしれません。


参考資料
・IntelR Atom Processor for Mobile Internet Devices Technical Documents
　　・IntelR System Controller Hub (IntelR SCH) datasheet (PDF)
　　・IntelR System Controller Hub (IntelR SCH) specification update (PDF)

・Imagination Intel
　　・IntelR CE 3100 (PDF)


関連エントリ
・Intel GMA500 の機能と性能と Aero

PC を移行したり OS を入れ直したり HDD を交換したりと、何かと環境の再構築が
連続したので個人的なメモです。(Windows Vista)


●Chrome
　ブックマークマネージャーからエクスポートしてバックアップ


●Firefox
　ブックマークの管理からバックアップ＆htmlとしてエクスポート


●iTunes
　移行前にコンピュータの認証解除
　データ自体は C:\Users\＜USER＞\Music\iTunes や設定詳細で指定したフォルダ移行


●Office Outlook (2007)
　　C:\Users\＜USER＞\AppData\Local\Microsoft\Outlook
　の中身を保存しておく。
　Outlook を install し、起動して初期化した後に上のデータを上書き。


●Thunderbird
　　C:\Users\＜USER＞\AppData\Roaming\Thunderbird
　の中にある profiles.ini と Profiles フォルダを保存する。


●3ds Max
　ライセンスを別マシンに export


●個人フォルダ
　　C:\Users\＜USER＞\Downloads
　　C:\Users\＜USER＞\Desktop
　　C:\Users\＜USER＞\Documents
　　C:\Users\＜USER＞\Pictures
　　C:\Users\＜USER＞\Music
　　C:\Users\＜USER＞\Favorites
　移行時はフォルダの移動ではなく、コピーして元を削除する。


●VirtualStore の確認
　　C:\Users\＜USER＞\AppData\Local\VirtualStore\Program Files (x86)
　　C:\Users\＜USER＞\AppData\Local\VirtualStore\Program Files
　Program Files にデータを書き込もうとするアプリケーションのデータは
　こちらに落ちているので一応みておく。


●その他

普段からフォルダごとに分類

・インストール不要なアプリケーションの実行ファイルフォルダ
　　　Program Files とは別フォルダに分けておくとコピーしてパスを通すだけ

・バックアップが必要なデータ用フォルダ
　　　別サーバーにミラーしているので無くてもいいけどコピーした方が再構築が楽

・バックアップ不要だけど移行した方が後で便利なデータフォルダ
　　　ダウンロードしたアプリのインストーラや周辺機器付属のドライバのコピーなど。
　　　なくても何とかなるので優先度低い。

数百GB～TB クラスになると USB2.0 でもコピーに時間がかかるので SATA でないと厳しい。
仮に 480Mbps 上限いっぱい使えると仮定しても 60MB/s、1TB=4時間半。(実際は数倍かかる)

ATOK2008 はキーカスタマイズをファイルに書き出してあるので install 後読み込むだけ。
テキストエディタなど設定ファイルもまとめて svn に入れて複数 PC 間で共有。

サーバーなどは仮想PCにしてるので、そのうち開発環境も仮想 PC で済むようになるかも。


●移行後

・移行直後なんか Vista が重い
　　デフォルトで個人フォルダがインデックス付けの対象となっているため。
　　個人フォルダに大量にファイルがあると一通りインデックス化が終わるまで重くなる。
　　「コントロールパネル→インデックスのオプション」で対象から外せる

・環境変数の設定画面を簡単に呼び出す
　　スタートメニューのアイコン画像を左クリック
　　　→左側のタスクから環境変数の設定

ARM 一色といって良いほど ARM が幅をきかせているように、
3D プロセッサも PowerVR 一色になりそうな勢いでした。
そんな中 Qualcomm は ATI (AMD) を貫き通すようです。

・Qualcomm、AMDからハンドヘルド向け事業を買収
・AMD、ハンドヘルド・チップ事業をクアルコムに売却

ちょうど最近なにかと苦労してたのがこの GPU。
Direct3DMobile ではなく OpenGLES だったりとか、他のドライバや API でもっと
きちんと使えば、もっとパワーのある描画性能を見せてくれるのかもしれません。

PowerVR 系も SGX が増えてくるので、そろそろ Shader を搭載した次の世代の
GPU も期待したいところ。


関連エントリ
・HTC Touch Diamond で Direct3DMobile その(11) 問題まとめその他
・HTC Touch Diamond で Direct3DMobile その(10) d3dmclock v1.10 3Dクロック 更新
・HTC Touch Diamond で Direct3DMobile その(9) d3dmclock v1.00 3D クロック
・HTC Touch Diamond で Direct3DMobile その(8) ノーマルマップの解説
・HTC Touch Diamond で Direct3DMobile その(7) ノーマルマップを表示する
・HTC Touch Diamond で Direct3DMobile その(6) 頂点性能続き
・HTC Touch Diamond で Direct3DMobile その(5)
・HTC Touch Diamond で Direct3DMobile その(4) 高速化
・HTC Touch Diamond で Direct3DMobile その(3) 実際の頂点性能
・HTC Touch Diamond で Direct3DMobile を使う。その (2)
・HTC Touch Diamond で Direct3DMobile を使う。ハードウエアアクセラレータ

Windows7 beta の PC でリモートデスクトップを使ってみました。

接続時に、リモートデスクトップの オプション → エクスペリエンス から
パフォーマンスのオプション画面でとりあえず全部チェックを入れておきます。
これで普通に Aero Glass が出ています。


↑LOOX U50 (Win7βクライアント) から EeePC901(Win7β) に接続

リモートデスクトップを使うためには、あらかじめホスト側の設定が必要です。
　コントロールパネル → システム → リモートの設定 →
　　リモートデスクトップを実行しているコンピュータからの接続を許可するを選ぶ

Vista が相手だと Aero Glass になりません。

Aero Glass
○　Win7β Client → Win7β Server
×　Win7β Client → VistaSP1 Server
×　VistaSP1 Client → Win7β Server

どの PC もローカルで Aero Glass が動くだけのスペックがあります。
(LooxU50 は Atom ではなく A110 の古いタイプです)

Aero Glass が出るなら Direct3D はどうだろう、ということで試しました。
あっさり動きました。



↑LOOX U50 (Win7βクライアント) から EeePC901(Win7β) に接続

ところが Vista でも動きました。



↑LOOX U50 (Win7βクライアント) から Desktop PC (VistaSP1) に接続

Aero は出ていませんが D3D アプリは動いています。
自分が知らなかっただけで Vista ですでに対応していたのかもしれません。

動作するアプリケーションはサーバー(ホスト)側の GPU に依存しています。
下記の通り認識されているデバイスが異なります。

HAL(sw vp): RDPDD Chained DD　(チップセット内蔵 GMA950 EeePC901 Win7)
HARDWARE: RDPDD Chained DD　　(GeForce GTX260 Desktop Vista)

サーバーが EeePC の場合 GeometryShader を使った D3D10 アプリは動きませんが、
GTX260 の Vista では動きます。よってサーバー側の GPU でレンダリングした結果の
画像を RDP で転送しているのだと考えられます。
もともと Vista 同士でも D3D アプリが動作していたのかもしれません。


Windows7 ではさらに、Direct3D のコマンドレベルのリモート描画に対応しているようです。
以前 masafumi さんのところで紹介されていた DXGI 1.1 beta のドキュメントによると、
Windows7 の DXGI1.1 だと RDP7 によって Remote PC の Adapter を取得できるとのこと。

・DXGI 1.1のドキュメント

詳しいドキュメント(White Paper)がこちらにありました。

・Microsoft Developer White Papers: PDC08
　より一番下の 「Direct3D 10.1 Command Remoting 」

Command Remoting の違いは下記の通り

・Vista
　サーバーの GPU でレンダリングした結果を bitmap でクライアントに転送。

・Windows7 DXGI1.1 対応アプリ
　描画コマンドを送ってアプリではクライアント側でレンダリングできる
　ただし既存の(未対応) Direct3D10.1 アプリはビットマップ転送

よって最初に紹介したキャプチャなど、現在描画されている Direct3D の画面はただの Vista の機能でした。

Command Remoting を使うには対応したアプリケーションを作成し、Windows7 上で
走らせる必要があります。
Full Screen Mode が使えないなど若干制限があり、また実際は通信帯域を考慮した
描画コマンドの最適化が必要となるようです。

コマンドレベルの転送＋クライアントレンダリングによって帯域を減らせるので、
リモートで走らせているアプリケーションでも描画レスポンスが向上すると思われます。
また未対応だったり不要なものは従来通り bitmap 転送なので、サーバーとクライアントで
レンダリング処理を分散させるなど応用できるかもしれません。

残念ながら 10.1 なので D3D11 アプリは当分未対応だと思われます。
WARP といい、とりあえず Windows の描画に必要な 10.1 が 1つの目標になっているようです。

HTC Touch Diamond の Direct3D Mobile を使い Texture に直接レンダリングしようと
思ったらエラー。cpas を見たら対応していないことに気がつきました。
テクスチャに対して BackBuffer からのコピーは出来たので、必要ならフレーム
バッファをコピーしながら使うことになります。
ちょっと昔の GPU といった感じです。

IDirect3DMobileTexture* iTexture0;
CreateTexture( 512, 512, ..., &iTexture0 )
IDirect3DMobileSurface* iSurface0;
iTexture0->GetSurfaceLevel( 0, &iSurface0 );
～
RECT rect;
rect.left= 0;
rect.top= 0;
rect.right= 480;
rect.bottom= 480;
CopyRects( iBackBuffer, &rect, 1, iSurface0, NULL );

●現在までにわかっている問題点

HTC TouchDiamond (Qualcomm MSM7201A 内蔵 ati core 用 d3dm_ati.dll) で
Direct3DMobile を使用した場合に遭遇した各種症状です。
Emulator の Reference Driver では問題がないので、何らかのバグの可能性が高いと
思われます。

・640x480 window mode/full screen でレンダリングできない
　639x480 や 640x479 以下なら大丈夫

・HW T＆L の光源が World space ではなく Local space で適用されてしまう

・XYZ_RHW 形式の頂点でレンダリングすると RHW の値が座標値にも影響を与えてしまう
　rhw = 1 以外で screen 座標を正しく与えることが出来ない。

・XYZ_RHW 形式(Transform済み頂点)と、そうでない頂点の混在が出来ない。
　RHW 無し頂点が出なくなる。

・D3DMTSS_TEXCOORDINDEX が無視される。常に Stage に一致した頂点 uv を参照する。
　仕様かもしれません。

・D3DMFVF_TEXCOORDFIXED が指定できない。常に頂点 uv は FLOAT とみなされる。

・Texture の mipmap ありなしと D3DMTSS_MIPFILTER の設定を厳密に合わせないと
　テクスチャが真っ白になる。
　存在しない miplevel へのアクセスが all 255 になるのかと思ったけど違うようです。

・ZWRITEENABLE を FALSE にできない。症状未確認。

・TextureStage でテクスチャを使用していない描画とテクスチャを使用している描画が
　混在しているときに Texture が表示されないことがある。

　厳密な発生条件は未検証です。他にも複数の描画で、上書きしているはずの
　TextureStage の設定が相互に影響し合っていることがあります。
　d3dmclock でも、オプションによって Texture が不要なケースなのにテクスチャを
　読み込んで演算で無視するなどやってます。

その他危なそうなものは避けて使っているので他にもあるかもしれません。


関連エントリ
・HTC Touch Diamond で Direct3DMobile その(10) d3dmclock v1.10 3Dクロック 更新
・HTC Touch Diamond で Direct3DMobile その(9) d3dmclock v1.00 3D クロック
・HTC Touch Diamond で Direct3DMobile その(8) ノーマルマップの解説
・HTC Touch Diamond で Direct3DMobile その(7) ノーマルマップを表示する
・HTC Touch Diamond で Direct3DMobile その(6) 頂点性能続き
・HTC Touch Diamond で Direct3DMobile その(5)
・HTC Touch Diamond で Direct3DMobile その(4) 高速化
・HTC Touch Diamond で Direct3DMobile その(3) 実際の頂点性能
・HTC Touch Diamond で Direct3DMobile を使う。その (2)
・HTC Touch Diamond で Direct3DMobile を使う。ハードウエアアクセラレータ

Android Dev Phone 1 (G1) の実機端末を見せてもらいました。
想像よりずっと良かった、というのが第一印象です。
端末は思ったよりもコンパクトでしっかりした作り。
スライド式キーボードも弧を描くような動きでユニーク。
ボタンの中央にあるのはカーソルキーでもスティックポインタでもなくてトラックボール。

・HTC T-Mobile G1

タッチパネルは指で軽く触れただけでスムーズに動きます。
これ iPhone/iPod touch と同じです。
ノート PC などのタッチパッドと同じで、指で操作するならこちらの方がやりやすいと感じます。

WindowsMobile 系端末に使われてる感圧式タッチパネルはスタイラスが使えるものの、
触れただけでは反応せず少々押す力がいります。
指操作だと反応してるかどうか若干わかりにくく、ものによっては爪を立てた方が
操作しやすくなります。
HTC の G1 も同様の感圧式かと思っていたので、この点でまず気に入りました。

使われているチップ自体は Touch Diamond と同じ Qualcomm MSM7201A だそうです。
画面解像度は iPhone 等と同じ 480x320 でした。
GPS 等は Diamond にもありますが、電子コンパスが目新しい機能です。

Android の OS 自体はさまざまな端末にも多くの方の努力によって移植されています。
HTC の WindowsMobile 端末で動作するものがあるようです。

・HTC Android

実際に手持ちの EMONSTER lite (S12HT, Touch Dual) と Touch Diamond (S21HT) で
試してみました。上記サイトを参考に、落としたファイルの exe を実行。

S12HT は一発目は起動成功しましたが、2度目以降は起動したり出来なかったりで
何度もリセットしながらです。
Android の操作をよく知らないせいか、試す前にホーム画面に戻れなくなったりと
はまってしまってまだきちんと使えていません。

S21HT は比較的すぐに起動できました。
コマンドラインに仮想キーボードからコマンドをタイプしなければならないですが、
しばらく待つと Dev Phone で見たような画面になります。
カーソルキー上下でメニュー階層の行き来が出来るようですが、Diamond のカーソルは
押しづらくて、さらに間違って OK (←) が押されてしまうと固まるみたいなので
こちらもまだうまく使いこなせていないところです。





2009/01/17 23:58 写真追加

Atom Z500 系の CPU を使ったノートが増えてきました。
小型軽量なものも多く魅力的です。
レビュー記事を見ていると Vista や Windows7 の Aero は off になっているとのこと。
気になったので調べてみました。

使われている GPU はチップセット (System Controller Hub) US15W 内蔵の GMA500。
最近携帯デバイスで多く使われている PowerVR core の一種ですが、アーキテクチャが
さらに進化した SGX に属するもののようです。

その特徴は Unified Shader であること。
DirectX10.1 (Direct3D10.1) 世代に対応できるだけの高度な機能を持っており、
VertexShader, PIxelShader や GeomteryShader を実行可能。
32bit float 演算可能でプログラム長の制限もなく分岐等の制御命令も備えています。
GPGPU として汎用処理に用いられることも想定しているようです。

機能だけ見ると GMA950～ 等よりも上に見えます。
実際に D3D10 対応ドライバが出ているのかどうか、Windows で D3D10.1 や
ShaderModel4.1 が使えるのかどうかわかりませんが、かなり興味が出てきました。

ドキュメントはこのあたりから落とすことが出来ます。
・IntelR System Controller Hub US15W Technical Documents

詳しい仕様は Datasheet の方で、Specification update でいくつか更新が入っています。
(update の方で 2GB RAM 対応が書かれています)

datasheet 「9 Graphics, Video, and Display」の一番最初、頂点性能なのに
15 clock/triangle と書かれている点がまず気になりました。
これは 3頂点分なのか、直後に書いてあるように
「 Vertex/Triangle Ratio average = 1 vtx/tri 」で 1頂点分なのか、
それとも 「 peak 0.5 vtx/tri 」の方を指している (つまり1頂点の半分の数値)
なのか曖昧です。

ただ 1頂点で 15cycle は少々多すぎような気がします。実際に計算すると
200MHz 動作なので 13.3M triangle/sec 。
wikipedia PowerVR に書かれている SGX535 の 28Mpoly/sec と比べて半分ほどです。

またピークの fill rate は 2pixel/clock と書かれています。
200MHz なので 400Mpixel/sec。
この数値は GPU としてはかなり低く GMA950 の数分の一。ここで重要なのが
PowerVR であるという事実。PVR はバスの効率を 2～3 倍とみなすため、
800M～1Gpix/sec 相当と書かれていることがあるようです。
Z/Stencil を内部メモリだけで処理可能で、3D のシーンなどポリゴンの重なりが
多くても、描画順に依存せずに常に一番上のポリゴンのみ描画可能だからです。

200MHz という記述は datasheet p.46 (CFG による選択で GFX 200MHz) や
Specification update の p.12 に Graphics Frequency 200MHz と書かれています。
112/160MHz はモニタ出力時のドットクロックのことで、core の動作クロックでは
ないようです。

NVIDIA や AMD で sp, spu 等と呼ばれているシェーダーユニットは、PowerVR SGX
だと USSE (Universal Scalable Shader Engine) という名称になっています。
例えば下記 wikipedia の記述を見ると SGX520～540 の性能はちょうど整数倍です。

・wikipedia PowerVR

GeForce や RADEON のように、シェーダーユニットの個数でグレードを分けている
のかもしれません。となると問題は GMA500 にはいったい何個載っているのか。

datasheet の説明を読むと、どうやら USSE は 2個ではないか、と思えます。
wikipedia の記述には GMA500 のシェーダーユニットは 4個と書かれています。
(SGX535相当とのこと) でも 4個だといまいち計算が合いません。

・wikipedia Intel GMA

datasheet には同時に 4つのシェーダーが実行可能状態になると書かれていますが、
もしかしたら同時実行ではなくインターリーブしている可能性もあります。
(ちなみに待機状態を含めて 16スレッドの状態を同時に保持できるようです。
レジスタは 1スレッドあたりスカラー 128個)
また下記の記事を見ても 535 までは USSE は 2個であるとのこと。

・Centrino Atomにも搭載されるIMGのPowerVRビジュアルIPコア

さらに PowerVR の本家サイト下記ページから、Intel CE3100 の pdf を
読むことが出来ます。

・Imagination Intel

Intel CE3100 は同じく GMA500 を搭載したメディアプロセッサで、pdf によると
dual USSE、13M triangle/sec、 2pixel/clock と書かれていました。
こちらの数値 13M triangle/sec は 200MHz 動作の 15clock/triangle とも
一致しますし、US15W の GMA500 と同じと思って良さそうです。
結局 SGX530 に近い数値ですが、同じものなのかそれとも計算方法が違うのかは
わかりません。

USSE の演算ユニットの構成は詳しくはわかりませんが ALU は 32bit 幅とのこと。
他の GPU でも D3D10 世代の Unified Shader はスカラー単位で動作しているので
USSE も同じような構造になっているのかもしれません。

もし 1 USSE が 1 ALU だとしたら、unified shader をフルに割り振っても
float4 の計算に 2cycle かかります。2pix/clock に間に合いません。
datasheet によると ALU は float x1 または fixed16 x2 または int8 x4 を
SIMD として一度に演算できるそうです。
レガシーな GDI のように 8bit ×4 の 24/32bit color ならば 1 ALU だけで済みます。
この場合のみ 2pix/clock が実現できるという意味かもしれません。

逆に言えば pixel にも float 演算が必要な ShaderModel2.0 以降は、ピクセル処理
速度が 1/4 になるということ。RGB だけでも 1/3。
ShaderModel1.0 でも符号付き 8bit なので 9bit 必要です。
おそらく fixed16 の演算が必要になると思われます。この場合 1/2。
Unified Shader なので頂点や GeomteryShader など他の処理も割り込みます。

もしこれらの仮定が正しいとするなら、GMA500 は pixel 性能が足りていないのだと
予想できます。3D のように深い重なりが無ければ PowerVR の特性も活かせず、
タイトなバスがそのまま見えてしまうでしょう。

特に Aero が半透明やレンダリング途中のフレームバッファを使った特殊効果を
利用しているなら、PVR の良いところがさっぱり発揮できていないのかもしれません。
よくよく考えると相性悪そうです。タイルをまたぐ大きなポリゴンも多いし。
さらに ShaderModel2.0 以上を必要とする Aero だと、シェーダーためにカラー
演算能力が 1/4 になっている可能性もあります。

Aero が使えなくても D3D10.1 相当のシェーダーが使えればおもしろそうなので、
実物を触る機会があったら試してみたいと思っています。
そういえばテクスチャユニットとかは全く情報がありませんでした。

これらの内容はすべてドキュメントを元にした想像で書いていますので、
実際に検証しながら調べたわけではないです。
いろいろ勘違いしている可能性が高いですのであらかじめご了承ください。
間違いがありましたらごめんなさい。

続き＞Intel GMA500 のスペックについて考える。続き (2)

メニューから任意の画像を読み込めるように変更しました。(前回)
対応フォーマットも大幅に増えて、任意サイズの画像を直接背景として登録できます。


↑ Windows7 ぽい感じに・・

ダウンロードはこちら
・d3dmclock v1.10 ダウンロードページ

WindowsMobile 用アプリです。

速度はだいたい 16～21fps 程度です。
速度は主に時間帯と背景テクスチャの解像度で変わります。
時間帯で速度が変化するのは、各数字モデルのポリゴン数が違うから。

1024x1024 に変換されてしまう大きな画像だともっと速度が落ちるかもしれません。
HTC Touch Diamond は VGA (640x480) なので、512x512 がちょうど良いくらいでしょう。
QVGA の端末ならもっと小さくて構いません。


Touch Diamond は 2.8インチで VGA (640x480) の解像度があるため、かなり密度が
高くきれいに見えます。輪郭のジャギも気にならないし、この密度でリアルタイムに
レンダリング出来てリアルタイムに動いているのだから十分かもしれません。
blog のキャプチャは 1/4 に縮小しています。

WindowsMobile だと、せっかく載っている 3Dアクセラレータがあんまり活用されていないのは
もったいないですね。


テクスチャの読み込みは、当初 Direct3DMobile D3DMX のテクスチャローダーを
そのまま使用していました。これ対応フォーマットは dds と bmp だけ。
しかも bmp は 16bpp を読み込めないことがわかりました。
さらに 2の n乗以外のサイズも読み込めるけど固まったかと思うくらい低速です。

テクスチャローダーを作り直しました。
参考にしたのは WindowsMobile6.0 SDK サンプル
Windows Mobile 6 SDK\Samples\Common\CPP\Win32\Imaging

これで bmp だけでなく jpeg や png 、gif などメジャーなものはたいてい
読み込めるようになりました。しかも速いです。

流れは次の通り

(1) IImage として画像を読み込む
(2) IBitmapImage に変換する
(3) LockBits() してピクセル情報にアクセス
(4) SystemMemory の Surface (CreateImageSurface()) に格納する
(5) CreateTexture()
(6) Texture から Surface を取り出す。
(7) (6) の Surface に (4) の Surface をコピーして vram に転送
(8) テンポラリリソースとインターフェースを Release

#include  <imaging.h>

// interface 取得
IImagingFactory*	iImageFactory= NULL;
CoCreateInstance( CLSID_ImagingFactory, NULL, CLSCTX_INPROC_SERVER,
			IID_IImagingFactory, &iImageFactory );
// ファイル読み込み
IImage*	iImage= NULL;
iImageFactory->CreateImageFromFile( file, &iImage );

ImageInfo	info;
iImage->GetImageInfo( &info );
int	w= info.Width;
int	h= info.Height;

// bitmap に変換
IBitmapImage*	iBitmap= NULL;
iImageFactory->CreateBitmapFromImage( iImage, w, h,
	PixelFormat24bppRGB, InterpolationHintDefault, &iBitmap );

iImage->Release();
iImageFactory->Release();

// lock
static BitmapData	lockdata;
iBitmap->LockBits( NULL, ImageLockModeRead, PixelFormat24bppRGB, &lockdata );

lockdata.Width;
lockdata.Height;
lockdata.Stride;
lockdata.Scan0;

// texture を作成
IDirect3DMobileTexture*	iTexture= NULL;
CreateTexture( w, h, 1, 0, D3DMFMT_R5G6B5, GetTexturePool(), &iTexture );

// SystemMemory の surface を作成
IDirect3DMobileSurface*	iSurface= NULL;
CreateImageSurface( w, h, D3DMFMT_R5G6B5, &iSurface );

// 書き込み
D3DMLOCKED_RECT	dlock;
iSurface->LockRect( &dlock, NULL, 0 );
uintptr_t	di= reinterpret_cast<uintptr_t>( dlock.pBits );
for( int y= 0 ; y< h ; y++ ){
    unsigned short*	dp= reinterpret_cast<unsigned short*>( di );
    for( int x= 0 ; x< w ; x++ ){
        const unsigned char*	sp= image.GetXY( x, y );
        unsigned int	b= sp[0];
        unsigned int	g= sp[1];
        unsigned int	r= sp[2];
        *dp++= ((r<<8)&0xf800)|((g<<3)&0x07e0)|((b>>3)&0x001f);
    }
    di+= dlock.Pitch;
}
iSurface->UnlockRect();

// texture の surface を取り出す
IDirect3DMobileSurface*	iTexSurface= NULL;
iTexture->GetSurfaceLevel( 0, &iTexSurface );

// コピー
CopyRects( iSurface, iTexSurface );

iSurface->Release();
iTexSurface->Release();

// unlock
iBitmap->UnlockBits( &lockdata );
iBitmap->Release();

関連エントリ
・HTC Touch Diamond で Direct3DMobile その(9) d3dmclock v1.00 3D クロック
・HTC Touch Diamond で Direct3DMobile その(8) ノーマルマップの解説
・HTC Touch Diamond で Direct3DMobile その(7) ノーマルマップを表示する
・HTC Touch Diamond で Direct3DMobile その(6) 頂点性能続き
・HTC Touch Diamond で Direct3DMobile その(5)
・HTC Touch Diamond で Direct3DMobile その(4) 高速化
・HTC Touch Diamond で Direct3DMobile その(3) 実際の頂点性能
・HTC Touch Diamond で Direct3DMobile を使う。その (2)
・HTC Touch Diamond で Direct3DMobile を使う。ハードウエアアクセラレータ

せっかくなのでもうちょっと実用的なやつを。
デジタル時計にしてみました。



HTC Touch Diamond の加速センサーに対応したので、本体の傾きに合わせて画面が
スムーズに回転します。
意味もなく数字 1つ 1つがポリゴンです。


↑数字が不揃いなのはバグではありません。

ダウンロードはこちら
・d3dmclock v1.00

WindowsMobile6.0/6.1 で動作します。加速センサーが無くても起動します。
ただし 3Dアクセラレータがないと非常に低速です。
おそらく HTC Touch Diamond 系、Touch Pro 等で動作すると思われます。

加速センサー以外にも、画面タッチの左右で回転、上下でズームします。



↑どんな角度にもなります。

背景画像は適当なので入れ替えて使ってください。
プログラムと同じフォルダに入っている bgimage0.bmp ～ bgimage2.bmp です。
サイズが 256x256 や 512x512 ならおそらく何でも大丈夫です。


textimage0.dds～textimage7.dds ファイルを置き換えれば、数字用のテクスチャも
入れ替えできます。こちらもサイズは 2の n乗で mipmap が必要です。
フォーマットは R5G6B5 にしてください。


Menu の Light にチェックを入れると、光源を操作できます。
この状態で画面をタッチすると、タッチした位置から画面中央に向かうベクトルを
光源の向きと見なします。

iPhone/iPod touch みたいにスムーズに動くものを、と思ったけどなかなか難しいですね。
Touch Diamond 系をお持ちの方はよろしければ一度お試しください。


関連エントリ
・HTC Touch Diamond で Direct3DMobile その(8) ノーマルマップの解説
・HTC Touch Diamond で Direct3DMobile その(7) ノーマルマップを表示する
・HTC Touch Diamond で Direct3DMobile その(6) 頂点性能続き
・HTC Touch Diamond で Direct3DMobile その(5)
・HTC Touch Diamond で Direct3DMobile その(4) 高速化
・HTC Touch Diamond で Direct3DMobile その(3) 実際の頂点性能
・HTC Touch Diamond で Direct3DMobile を使う。その (2)
・HTC Touch Diamond で Direct3DMobile を使う。ハードウエアアクセラレータ

設定等をもう少し説明してみます。(→前回)



ダウンロードはこちら
・bumptest v1.00

スマートフォン HTC Touch Diamond は Qualcomm MSM7201A 内蔵の
3D アクセラレータを搭載しており ATI の GPU core となっています。

Direct3DMobile は PC でいう DirectX8 のサブセットですが、機能自体は
DirectX7 世代相当で固定パイプラインのみ。シェーダーは使えません。

caps を調べるとハードウエアアクセラレータとして認識していることがわかります。

D3DMDEVCAPS_HWTRANSFORMANDLIGHT
D3DMDEVCAPS_HWRASTERIZATION
D3DMDEVCAPS_NATIVEFLOAT

また使用できるマルチテクスチャは 2枚で TextureStage 数も 2段です。
無理矢理シェーダーにたとえれば ShaderModel 1.0 でピクセル単位に

・テクスチャ命令 x2
・演算命令 x2

を実行できるということ。DirectX7 世代のレジスタコンバイナそのままです。
TextureStage で使用できる演算として D3DMTEXOPCAPS_DOTPRODUCT3 が有効に
なっていたのでこれを使用します。


TextureStage には外部から与えられる定数がありません。
試しに D3DMRS_DIFFUSEMATERIALSOURCE を使って頂点カラーの代わりに Material
からパラメータを取れないか試しましたがだめでした。
これはライティングユニットへの入力時にのみ機能するようです。

外部から定数を渡すことが出来ればすぐにでもオブジェクトスペースの
ノーマルマップでテストできるのですがあきらめます。
パラメータは頂点カラーとして渡すことにします。
どうせ頂点を経由するなら最初からタンジェントスペースにします。

頂点の光源計算はもともと CPU で行っていました。
このときオブジェクトスペースに変換した光源ベクトルを使いますが、ここで
DotProduct せずにベクトルをそのままカラー値として出力します。

まずは D3DMTEXOPCAPS_DOTPRODUCT3 のベクトルフォーマットを確認します。
いくつかのカラー値を通してみてどのような復号が行われているか推測。
マニュアルには符号付きとだけ書かれており明確ではありませんでしたが、
やはりシェーダー同様 _bx2 相当 ( (x-0.5)*2 ) でした。


モデルデータの頂点にはオブジェクトスペースからタンジェントスペースへの変換
マトリクスを埋め込んでおきます。
1軸は法線と共有するため +2 vect。CrossProduct するなら +1 のみ。
データの生成と export は昔 3ds Max 用に作った自作プラグインを使用しています。

WorldSpace (GlobalSpace)
　　　→ ObjectSpace (LocalSpace)
　　　　　　　→ TangentSpace (TextureSpace)

元の光源ベクトルは WorldSpace に配置されているため、頂点法線も WorldMatrix
(3x3) で変換してから演算する必要があります。
一般的に光源の数より頂点の方が多いので、CPU 演算の手抜きライトの場合は光源の方を
WorldMatrix(3x3) の逆行列で ObjectSpace に変換した方が演算量が減ります。
同じようにノーマルマップからサンプリングした法線を適用するため、
光源ベクトルを TangentSpace まで逆変換します。

頂点単位のライティングの代わりに、オブジェクトスペースへ変換した光源ベクトルを
タンジェントスペースへ変換する演算を追加します。変換 matrix (3x3)をかけるだけ。
結果を 0～1.0 に収まるよう _bx2 の逆変換で格納します。
固定小数演算なのでビットシフト等で最適化します。

vect3 tslightdir;
TangentMatrix.Transformation( tslightdir, oslightdir );
colorr= ((tslightdir.x+ FIXED16(1.0f))* 255)>>17;
colorg= ((tslightdir.y+ FIXED16(1.0f))* 255)>>17;
colorb= ((tslightdir.z+ FIXED16(1.0f))* 255)>>17;

シェーダーがあれば VertexShader でやっているところです。
またノーマルマップ生成ツールによって座標系が異なってることがあるので
軸の符号などは合わせます。

テクスチャステージでは読み込んだノーマルマップの値と頂点から出力した上記の
光源ベクトルを DotProduct します。

一段目はノーマルマップで光源演算。

SetTexture( 0, iTexture0 );
SetTextureStageState( 0, D3DMTSS_COLORARG1, D3DMTA_TEXTURE );
SetTextureStageState( 0, D3DMTSS_COLORARG2, D3DMTA_DIFFUSE );
SetTextureStageState( 0, D3DMTSS_RESULTARG, D3DMTA_CURRENT );
SetTextureStageState( 0, D3DMTSS_COLOROP, D3DMTOP_DOTPRODUCT3 );
SetTextureStageState( 0, D3DMTSS_ALPHAOP, D3DMTOP_DISABLE );
SetTextureStageState( 0, D3DMTSS_TEXCOORDINDEX, 0|D3DMTSS_TCI_PASSTHRU );

二段目はカラーマップの合成。

SetTexture( 1, iTexture1 );
SetTextureStageState( 1, D3DMTSS_COLORARG1, D3DMTA_TEXTURE );
SetTextureStageState( 1, D3DMTSS_COLORARG2, D3DMTA_CURRENT );
SetTextureStageState( 1, D3DMTSS_RESULTARG, D3DMTA_CURRENT );
SetTextureStageState( 1, D3DMTSS_COLOROP, D3DMTOP_MODULATE );
SetTextureStageState( 1, D3DMTSS_ALPHAOP, D3DMTOP_DISABLE );
SetTextureStageState( 1, D3DMTSS_TEXCOORDINDEX, 0|D3DMTSS_TCI_PASSTHRU );

まだ ALPHA があいています。
PowerVR だと適用可能なオペレーションの種類がもっと多いのでいろいろ出来るでしょう。


関連エントリ
・HTC Touch Diamond で Direct3DMobile その(7) ノーマルマップを表示する
・HTC Touch Diamond で Direct3DMobile その(6) 頂点性能続き
・HTC Touch Diamond で Direct3DMobile その(5)
・HTC Touch Diamond で Direct3DMobile その(4) 高速化
・HTC Touch Diamond で Direct3DMobile その(3) 実際の頂点性能
・HTC Touch Diamond で Direct3DMobile を使う。その (2)
・HTC Touch Diamond で Direct3DMobile を使う。ハードウエアアクセラレータ

Touch Diamond でノーマルマップの表示が出来ました。



だいたい 22～24fps くらい。
さすがにピクセル単位のライティングは、ローポリでもきれいに出ます。
やっとハードウエアアクセラレータらしい表示が出るようになりました。


↑カラーマップだけ


↑ノーマルマップだけ


↑両方適用

テクスチャは PC 用 Direct3D のサンプルを使用しています。
本当はレリーフマップ用のデータですが、ただのノーマルマップとしてだけ使っています。
これが PC のシェーダーだったら本当はレイキャストで視差も出るし影も落ちるのですが。


この WindowsMobile 用のプログラムは下記から落として試せるようにしました。

ダウンロード
・bumptest v1.00


●動作を確認したもの

◎ハードウエアアクセラレータが有効なもの

　・HTC Touch Diamond (EMOBILE S21HT 他)
　　　Qualcomm MSM7201A 内蔵 ATI core
　　　Touch Diamond はハードウエアアクセラレータで高速に動作します。
　　　おそらく Touch Pro もいける。

◎ハードウエアアクセラレータが無効だけど動くもの

　・HTC Touch Dual (EMONSTER lite S12HT 等)
　　　CPU のリファレンスラスタライザで起動します。
　　　非常に低速ですが画面はきちんと出ます。

◎動作しないもの

　・SHARP EM・ONEα S01SH2
　　　CPU ラスタライザですが XScale ドライバ D3DMXSC50PB です。
　　　マルチテクスチャ＆マルチ UV 未対応なため起動しません。

各端末の 3D 機能について詳しくはこちらを参照してください。

http://hp.vector.co.jp/authors/VA004474/wince/d3dmcapslist.html


●解説など

頂点が遅い＆ハードウエアライティングが遅いので、ピクセルライティングを
試してみました。思ったよりきれいに出ました。
これならローポリでも違和感なく表示できそうです。
ただしその分テクスチャが増えます。

タンジェントスペースの計算は CPU で行っています。
前回調べた結果の通り、CPU ですべて頂点変換を行ったとしてもその割合は
たいしたことありません。
よって CPU 側で少々凝った計算をしても全体へはさほど影響しないとの判断です。

ただ何度も述べてるように、rhw バグがあるため CPU だけで全部の計算を行うと
テクスチャのゆがみが見えてしまいます。
そこで次のようにします。

(1) 動的に CPU で頂点バッファを生成する
　　　ライティングやタンジェントスペースの計算はここで行う。
　　　頂点カラーを求める。
　　　座標は素通りさせる。

(2) 座標変換は Direct3D Mobile に任せる
　　　ここではライティングせずに座標変換のみ。

これで rhw バグを回避できますし、Direct3D Mobile の重いライティングを使わずにすみます。

済むはずでした。

rhw バグは根が深いようです。
フォントの表示など 3D 変換が不要な頂点には最初からスクリーンスペースの座標を
与えると簡単ですが、この場合頂点は XYZRHW 形式になります。
モデルの方は Direct3D Mobile に任せるため RHW の無い XYZ です。

この両方の頂点形式のデータを交互に描画すると、XYZ 形式のモデルが表示されなくなるようです。
仕方なくフォントも 2D 変換の Projection を通して描画するように変更。

その他トラブル
・ZWRITEENABLE を FALSE にすると表示が崩れるので ON 固定に。
・TextureStage の TEXCOORDINDEX が効いてない気がするので頂点側を MultiUV に変更。
・MipFilter を有効にすると MipMap が強制される。MipMap 無しのテクスチャが含まれていると真っ白になる。


問題が多く低速な頂点に比べると、ピクセル側は比較的問題が少なく素直に動いている気がします。
使用可能なテクスチャ形式が少ないことが少々難点です。
16bit フォーマットを選ばざるを得ないので、結局 565 になってしまいます。

22～24 fps くらいしか出てませんが、Touch Diamond の d3dm_ati.dll だとなぜか
空のデータでも最大 28fps 程度にしかならないので、これでも軽い方なのです。


関連エントリ
・HTC Touch Diamond で Direct3DMobile その(6) 頂点性能続き
・HTC Touch Diamond で Direct3DMobile その(5)
・HTC Touch Diamond で Direct3DMobile その(4) 高速化
・HTC Touch Diamond で Direct3DMobile その(3) 実際の頂点性能
・HTC Touch Diamond で Direct3DMobile を使う。その (2)
・HTC Touch Diamond で Direct3DMobile を使う。ハードウエアアクセラレータ

●EeePC 901-X

これまでもずっと EeePC 901 で WindowsVista を使い続けてきたため、特に違和感も
無く普通に使えています。
ただ Vista の時と同じように RAMDISK の設定は行いました。

EeePC の画面縦 600dot だとダイアログが切れることがあるため、タスクバーは左端
縦に配置しています。もともと文字が無くアイコンだけなので意外に大丈夫かも。
Windows7 のタスクバーは他のウィンドウの下にならないので、解像度が足りないと
結構邪魔です。

電源設定は修正。休止状態無しでスリープのみ行うように。
仮想メモリもページングファイル無しに設定しています。

BIOS を更新したらログイン画面などで暗転するようになったので徐々に戻しました。
とりあえず BIOS 902 だと問題なく動いています。
× 1808, 1703, 1301
○ 902
これ以外は未確認。

エクスペリエンスインデックスは、ページングファイル無しで、かつテンポラリを
RAMDISK に設定していると評価に失敗します。
あれこれ設定を行う前に評価を済ませておいた方が良いです。


●FMV BIBLO LOOX U50

A110 800MHz の古いタイプなので、Atom 機と比べると重いです。
ですが、もともと Vista が乗っているマシンなのでほぼそのまま。
指紋認証は使っていませんがワンセグも動いています。
タッチパネルの補正が失敗。
追記: タッチパネル補正できました。

FMV BIBLO LOOX U50X/V
Intel A110 800MHz / RAM 1GB / 1.8HDD
CPU 1.5
RAM 3.9
AERO 2.0
GAME 2.4
HDD 3.7

EeePC 901-X
Atom N270 1.6GHz / RAM 2GB / 32GB SSD (SHD-DI9M)
CPU 2.2
RAM 4.5
AERO 2.1
GAME 3.0
HDD 2.9



関連エントリ
・LOOX U でも Windows7 beta
・EeePC 901 Windows7 beta
・EeePC 901 SHD-DI9M 32G と Vista 設定 (2)
・EeePC 901 の SSD 交換 BUFFALO SHD-DI9M 32G と Vista
・EeePC 901 に Windows Vista その5
・EeePC 901 に WindowsVista

Touch Diamond で Direct3DMobile を使った描画の続きです。
CPU 側の各処理の測定時間になります。

頂点数 ポリゴン数  頂点計算時間  1frame合計    cpuv/v   total/v  total/t
   401       760           700       40000      1.75     99.75    52.63
  1679      3120          2800       46000      1.67     27.40    14.74
  5039      9660          8500       90000      1.69     17.86     9.32
 10199     19800         17000      160000      1.67     15.69     8.08
 22799     44700         38000      348000      1.67     15.26     7.85
                          usec        usec

CPU で行う頂点の変換自体は float よりも固定小数の方が 5～6 倍ほど高速でした。
それでも描画速度向上がわずかだったのは、全体の処理時間からみたら
たいしたことがなかったからです。
全体の処理時間のうち頂点計算の割合は 10% 程度。
残りは全部 Present() が占めます。

カメラ位置を変えてポリゴン自体の描画面積が変わっても、動作速度にはほとんど
変動がありませんでした。
よって kick したあとの実際の描画処理では、頂点数に比例して増加するなんらかの
重い処理が CPU で行われていると予想できます。
あとはレンダーステートの組み合わせなど軽くなる条件を探していくしかなさそうです。

iPhone/iPod touch の実際の描画性能がどのくらいなのか気になるところです。


関連エントリ
・HTC Touch Diamond で Direct3DMobile その(5)
・HTC Touch Diamond で Direct3DMobile その(4) 高速化
・HTC Touch Diamond で Direct3DMobile その(3) 実際の頂点性能
・HTC Touch Diamond で Direct3DMobile を使う。その (2)
・HTC Touch Diamond で Direct3DMobile を使う。ハードウエアアクセラレータ

LOOX U50 Windows7 beta build 7000

LOOX U50X/V A110

CPU  1.5
RAM  3.9
AERO 2.0
GAME 2.4
HDD  3.7

クリーンインストールです。
EeePC 901 同様最初から Aero ON でした。
LAN/WLAN はそのまま認識したのでネットは使えます。
いくつか足りないドライバがあるけどワンセグその他
追記: 付属 CD-ROM アプリケーションディスク1 より
pt901_p1, button\driver, button\utility, o2micro, fpsensor を install

EeePC 901 はこちら

EeePC 901 N270

CPU  2.2
RAM  4.5
AERO 2.1
GAME 3.0
HDD  2.9

関連エントリ
・EeePC 901 Windows7 beta

とりあえず EeePC 901 で試しています。
Windows7 beta build 7000
RAM 2GB + SSD 32GB へ増設済み



LAN/WLAN 以外はそのままで認識。最初から Aero Glass が有効でした。
LAN/WLAN ドライバは Vista と同じように付属 CD-ROM のもので OK。

Vista フルインストール時と異なり最初から使い物になる印象。
不要なサービスを切ったり設定を詰めなくても軽いです。
RAMDISK 等何も設定していませんが十分かもしれません。
AeroGlass の描画は、Vista の方がかっちり同期をとって描画していた印象。
ただしまだ beta なので何ともいえません。

いろいろ使いやすく軽くなっている反面、Vista で気に入っていた設定が
できなくなってるところも結構あって複雑な気分。
タスクバーとかは慣れが必要です。

d3d10warp.dll、d3d11.dll が最初から入っています。
d2d1.dll というものも。


関連エントリ
・EeePC 901 SHD-DI9M 32G と Vista 設定 (2)
・EeePC 901 の SSD 交換 BUFFALO SHD-DI9M 32G と Vista
・EeePC 901 に Windows Vista その5
・EeePC 901 に WindowsVista

時間が無くてほとんど触っていませんが、、結果速くなりませんでした。
CPU 処理の方が有利と結論づけるにはまだ検証が足りないようです。

光源ありの場合は不要なものを大幅に省けるので相対的に速度が出ます。
逆に軽いデータでもピーク性能が全く伸びません。
少々触っただけでは何ともいえないので、時間があるときに詳しく測定して
原因を特定する必要がありそうです。

rhw の問題も回避手段が見つからないので、その(3) の結果を受け入れた方が
良いのかもしれません。

・ FIXED のテクスチャ頂点の問題

頂点形式を固定少数 D3DMFVF_TEXCOORDFIXED(0) にした場合に uv 値がおかしい、
テクスチャが出なくなるという問題がありました。

調べたところ FIXED 指定は無視され内部では常に float でアクセスしているようです。
FVF に何を指定しようが float 値を書き込むとうまくいきます。
やはりセットアップエンジンへは float で値が渡っているのでしょうか。
頂点も演算だけ FIXED で行い、バッファへは float で書き込んでみるのもありかも
しれません。

・ rhw の問題

D3DMFVF_XYZRHW_FLOAT や D3DMFVF_XYZRHW_FIXED の rhw に 1.0 以外の値を
書き込むと、ポリゴン自体の描画位置がずれてしまう問題があります。
こちらは特に触っていないので進展は無いです。


関連エントリ
・HTC Touch Diamond で Direct3DMobile その(4) 高速化
・HTC Touch Diamond で Direct3DMobile その(3) 実際の頂点性能
・HTC Touch Diamond で Direct3DMobile を使う。その (2)
・HTC Touch Diamond で Direct3DMobile を使う。ハードウエアアクセラレータ

速くなりました。光源入りで 4つ表示して 23.2fps。
その(2) の時は 1つで 18.5fps しか出ていなかったデータです。


TouchDiamond (Qualcomm MSM7201A) Direct3DMobile

● 前回 調べた結果から

数値を見る限り 30fps でフレーム 10000頂点くらいがいいところでしょうか。
しかもデータ側の頂点数ではなく実演算の頂点数です。
ポリゴン数だとがんばって 3000～4000ポリゴン相当くらい。

さらに裏面や画面外など、描画してないけど計算してしまったポリゴンも含むので
実際に使うと予想以上に少なく感じるはずです。
頂点がかなり足を引っ張る形になります。
(API 呼び出しのオーバーヘッドとかフィル周りはまだ未調査です)
Dreamcast とか PSP クラス とかとても無理で、おそらく DS 未満。

光源を入れるとさらに 2.5 倍ほど重くなるようです。

いろいろ考えた結果、caps が HWTRANSFORMANDLIGHT を返してくるのはたぶん嘘では
ないかと。頂点はおそらく CPU 計算です。


試しに CPU だけで頂点の変換を行ってみたところ、同等以上の速度で描画することができました。
しかも FPU (VFP) が乗ってない CPU で float 演算しているのにこの速度。
caps が NATIVEFLOAT を返してくるので D3DM も CPU で float 演算している可能性が
あります。

固定少数でためしたら、float よりちょっとだけ速くなりました。
これが 最初にのせた 23.2fps の結果となります。

最適化とかほとんど考慮していないのに、それなりに速いのには理由があります。

　・クリッピングしていない
　・頂点バッファ単位で変換しているので共有頂点は一度しか計算していない
　・光源計算は必要最小限で不要なものを省いている

よって実際に使える状態まで機能を入れるともっと負担が多くなるはずです。


●ここまでの結論

　Touch Diamond で D3DM を使う場合
　・CPU で自前で頂点演算をやる
　・CPU 内で完結するものは固定小数演算

自前で書けば、プログラマブルシェーダーのように必要最小限な処理に最適化できます。
ライティングなども実用的な速度で動作すると思います。


●問題点

実際に CPU で頂点演算をしてみると、いくつか問題が出てきました。

・rhw の挙動がおかしい

　自分でスクリーンスペースまで変換した場合、変換後の頂点の rhw の挙動が
　どうもおかしい。狙った通りの結果になりません。
　これがだめだとパースペクティブコレクションが効かないので少々致命的です。

・Fixed 形式の頂点だと Texture の uv が出ない

　負の uv 値でおかしなテクスチャの値になる。原因調査中


関連エントリ
・HTC Touch Diamond で Direct3DMobile その(3) 実際の頂点性能
・HTC Touch Diamond で Direct3DMobile を使う。その (2)
・HTC Touch Diamond で Direct3DMobile を使う。ハードウエアアクセラレータ

HTC Touch Diamond の 3D アクセラレータの速度テストです。
Qualcomm MSM7201A 内蔵 ATI core

時間がないので軽く調査、厳密なテストではないです。
頂点性能だけ見たかったので TriangleStrip で見えるか見えないかぎりぎりの
極小ポリゴン描画を並べたもの。ほとんど 1pixel 以下です。
単一バッファで一度だけ DrawPrimitive() しています。


●低負荷と思われるフォーマットでどれだけ頂点処理できるか

テクスチャ無し、ライティング無し、頂点カラーのみ

FVF = D3DMFVF_XYZ_FLOAT|D3DMFVF_DIFFUSE
struct { // 16byte
	float	x, y, z;
	DWORD	color;
};

頂点数  解像度  頂点形式     速度
 16384   VGA    xyz col     17.0fps   58msec
 32768   VGA    xyz col      9.6fps  103msec
 49152   VGA    xyz col      7.8fps  128msec
 65536   VGA    xyz col      5.7fps  176msec

おおざっぱに 16K 頂点が 40msec とすると、どんなにがんばっても最高 40万頂点/sec
程度しか出ない計算に。
ボトルネックが、頂点補充が追いつかないのか演算なのかは不明。


●ピーク速度に近づきたいために頂点カラーも無くしてみる

FVF = D3DMFVF_XYZ_FLOAT
struct { // 12byte
	float	x, y, z;
};

頂点数  解像度  頂点形式     速度
 16384   VGA    xyz         17.4fps   57msec
 32768   VGA    xyz          9.9fps  100msec
 49152   VGA    xyz          8.0fps  125msec
 65536   VGA    xyz          5.8fps  172msec

頂点カラーの影響は 16K 頂点あたり 1msec くらい。
65536頂点時に 38万頂点/sec


●解像度変更

頂点数  解像度  頂点形式     速度
 16384   VGA    xyz         17.4fps   57msec
 16384   HVGA   xyz         15.7fps   63msec
 16384   QVGA   xyz         22.5fps   44msec
 65536   VGA    xyz          5.8fps  172msec
 65536   HVGA   xyz          9.2fps  108msec
 65536   QVGA   xyz         11.2fps   88msec

フィルの影響も調べるために解像度も変えてテスト。
ポリゴン描画以外はクリアと Flip (COPY) だけなのに解像度の影響がかなりあります。
頂点数の増加によって解像度の影響をより強く受けているので、極小ポリゴンとは
いえそれなりにフィルを消費していることがわかります。

VGA = 639x480 (なぜ 639 なのかはこちら)
HVGA = 480x320 (iPhone/iPod touch や Android G1 がこれ)
QVGA = 320x240


●Memory Pool の違い

頂点数  解像度  頂点形式  Pool          速度
 65536   VGA    xyz       videomem      5.8fps 172msec
 65536   VGA    xyz       systemmem     5.8fps 172msec

caps ではどちらにも配置可能。特に差は無し。
速度が同じなのか、最初から同じメモリなのか、内部で Pool を無視して同一処理して
いるのかは不明。


●Index かどうか

もともと TriangleStrip だし頂点キャッシュが(もしあったとしても)有効なケース
ではないので、アクセスすべきメモリが増えた分だけ遅くなるはず。

頂点数  解像度  頂点形式  Index                   速度
 65536   VGA    xyz       DrawPrimitive           5.8fps 172msec
 65536   VGA    xyz       DrawIndexedPrimitive    5.8fps 173msec

結果、誤差の範囲でほとんど差は出ていません。


●浮動小数と固定少数の違い

頂点形式を FIXED にしても全く差がなかったです。
もともと caps が NATIVEFLOAT を返してくるし HW T&L 入ってるので Float だと
思いますが、どちらにせよ頂点バッファを作った時点で効率よい形式に
変換されていると考えられます。


● Texture つき

一番実用に近いと思われる頂点形式でテストです。
これが使い物になれば何とでもなる。

FVF=	D3DMFVF_XYZ_FLOAT|D3DMFVF_TEX1
	|D3DMFVF_TEXCOORDSIZE2(0)|D3DMFVF_TEXCOORDFLOAT(0)
struct _VTYPE {
	float	x, y, z;
	float	tu, tv;
};

頂点数  解像度  頂点形式       速度
 16384   VGA    xyz tex       16.8fps   59msec
 32768   VGA    xyz tex        9.6fps  104msec
 49152   VGA    xyz tex        7.6fps  131msec
 65536   VGA    xyz tex        5.3fps  190msec
  1000   QVGA   xyz tex       28.5fps   35msec
  1000   VGA    xyz tex       28.0fps   35msec
  5000   VGA    xyz tex       27.4fps   36msec
 10000   VGA    xyz tex       25.8fps   38msec
 20000   VGA    xyz tex       15.9fps   62msec

頂点の負担を見ることが目的なので、結果に大きな影響が出ないように Texture は
1pixel しか読み込んでいません。

ずっと気になっていたのが、必ず 29fps くらいで頭打ちになること。
設定はどれも D3DMPRESENT_INTERVAL_IMMEDIATE です。
これを D3DMPRESENT_INTERVAL_ONE にしてもなぜか同じ。


● Texture + Color つき

かなり使われることが多いフォーマットです。
これが使えればテクスチャを減らせます。

FVF=	D3DMFVF_XYZ_FLOAT|D3DMFVF_DIFFUSE|D3DMFVF_TEX1
	|D3DMFVF_TEXCOORDSIZE2(0)|D3DMFVF_TEXCOORDFLOAT(0)
struct _VTYPE {
	float	x, y, z;
	DWORD	color;
	float	tu, tv;
};

頂点数  解像度  頂点形式       速度
 16384   VGA    xyz col tex   16.6fps   60msec
 32768   VGA    xyz col tex    9.2fps  108msec
 49152   VGA    xyz col tex    6.9fps  145msec
 65536   VGA    xyz col tex    5.2fps  193msec
 10000   VGA    xyz col tex   25.8fps   38msec
 20000   VGA    xyz col tex   15.9fps   63msec

実用的な頂点処理能力としては、フレームあたり 1万ポリゴンくらいが限界といったところです。
ただし単一バッファで一回の描画でこの数値です。
実際は多数の DrawPrimitive() を呼び出すことになるので速度は落ちるはずです。


また前回やった通りライティングはかなり遅いのでテストしてません。
●光源処理あり 2008/01/07 3:02 追記

せっかくなので本当にどれだけ遅いのか光源もテストしてみました。
ハードウエア光源を使うだけで頂点が 2.5倍以上重くなっています。
これは純粋に演算量の増加によるものでしょう。

FVF = D3DMFVF_XYZ_FLOAT|D3DMFVF_NORMAL
struct { // 16byte
	float	x, y, z;
	float	nx, ny, nz;
};

◎平行光源 x1、スペキュラ無し
頂点数  解像度  頂点形式    光源                      速度
 16384   VGA    xyz normal  Dir x1  Diffuse           7.0fps  143msec
 32768   VGA    xyz normal  Dir x1  Diffuse           3.7fps  264msec
 49152   VGA    xyz normal  Dir x1  Diffuse           2.7fps  371msec
 65536   VGA    xyz normal  Dir x1  Diffuse           2.0fps  497msec

◎平行光源 x2、スペキュラ無し
頂点数  解像度  頂点形式    光源                      速度
 16384   VGA    xyz normal  Dir x2  Diffuse           6.9fps  144msec
 32768   VGA    xyz normal  Dir x2  Diffuse           3.7fps  275msec
 49152   VGA    xyz normal  Dir x2  Diffuse           2.6fps  380msec
 65536   VGA    xyz normal  Dir x2  Diffuse           1.9fps  512msec

◎平行光源 x1、スペキュラあり Power=10
頂点数  解像度  頂点形式    光源                      速度
 16384   VGA    xyz normal  Dir x1  Diffuse+Specular  6.1fps  165msec
 32768   VGA    xyz normal  Dir x1  Diffuse+Specular  3.2fps  310msec
 49152   VGA    xyz normal  Dir x1  Diffuse+Specular  2.3fps  440msec

◎平行光源 x2、スペキュラあり Power=10
頂点数  解像度  頂点形式    光源                      速度
 16384   VGA    xyz normal  Dir x2  Diffuse+Specular  6.0fps  165msec
 32768   VGA    xyz normal  Dir x2  Diffuse+Specular  3.2fps  311msec

●TriangleList の負荷 2008/01/07 9:30 追記

TriangleStrip で描画していた全く同じ頂点配列＋ポリゴンを、Index で
TriangleList に展開したものです。
Index の数が (vertices-2)*3 に増えた分だけメモリアクセスが増えますが、
キャッシュがある一般的な GPU だと速度が落ちません。

頂点数  解像度  頂点形式 描画API      PrimitiveType   速度
 32768   VGA    xyz    DrawPrimitive  TriangleStrip  10.1fps   99msec
 32768   VGA    xyz    DrawIndexedPri TriangleStrip  10.0fps  100msec
 32768   VGA    xyz    DrawIndexedPri TriangleList    4.0fps  248msec

プログラムが間違っていなければ頂点キャッシュ無し確定。
おそらく演算が 3倍になってると思われます。


問題はむしろフィルの方なので、あとはピクセルがどれくらい出るかどうか。

・IT Media QUALCOMM、MSM7201A上で動作するAndroidのデモを公開
上のページには PSP に近いくらいと書かれていますが、現状とてもそこまで
出せそうにないです。


関連エントリ
・HTC Touch Diamond で Direct3DMobile を使う。その (2)
・HTC Touch Diamond で Direct3DMobile を使う。ハードウエアアクセラレータ

前回は板を描画するだけで力尽きたので、もうちょっとだけテスト。
16bit 565 なのでマッハバンドが目立ちます。




401頂点、760ポリゴン、平行光源×1(Diffuseのみ)、
Texture 1枚、256x256xR5G6B5 (mip無し、バイリニアフィルタ)
1頂点 32byte (xyz normal texuv float)

TouchDiamond S21HT   VGA  639x480  ATI  d3dm_ati.dll      18.5  fps
EMONSTER lite S12HT  QVGA 320x240  REF  d3dmref.dll        0.25 fps
EM・ONE S01SH        WVGA 800x480  XSC  D3DMXSc50PB.dll    4.3  fps

Touch Diamond は光源なしだとテクスチャ付きでも 30fps 出てました。
LightEnable を TRUE にしただけで 18.5fps へ。
SpecularEnable ではあまり変わらないけどローポリの頂点単位だと見た目がきつい。

他の端末でも走らせてみましたが、解像度が違うのであんまり参考にならないかも。
Reference Driver は遅いです。

Touch Diamond の光源処理には少々問題があります。
World だけの回転でなぜか光源も一緒に動いてしまうこと。
法線用の Matrix の設定が間違っているのか少々バグっぽい挙動です。

・Qualcomm MSM7201

上記ページによると 頂点性能 4M triangle/sec、フィルレート 133M pixel/sec。
1/30sec で frame 13万頂点。おそらくライティング無し、最小頂点形式のピーク値。

フィルは VGA (640x480) の場合全部転送と見なして 14画面分に相当します。
ただし GPU の処理能力なのかバス能力の上限なのかはわかりません。
おおざっぱに 読み出し 16bit texture + 16bit depth 、書き込み 16bit color
+ 16bit depth で 133MHz といったところでしょうか。

4M Triangle/sec というと、スペック上の数値だけなら Dreamcast クラスに見えます。
VGA 解像度や 16bit 565 フレームバッファも同じ。
でも数値だけなのでもちろん無理。

しかもバス帯域を効率よく使う PowerVR に比べるとフィルで不利だし、caps 一覧を
見る限り DXT 圧縮テクスチャがないのも PVR よりバスを圧迫しそう。

実際 D3DM 経由でどの程度パフォーマンス出せるかまだわからないですが、現状
オーバーヘッドもかなり多そうです。
CPU も FPU 無しだし、解像度も高いし、iPhone/iPod touch 比ではかなり不利だと
思われます。


関連エントリ
・HTC Touch Diamond で Direct3DMobile を使う。ハードウエアアクセラレータ

やっと HTC Touch Diamond で Direct3DMobile が動くようになりました。
ハードウエアアクセラレータがきいていて、一応 VGA のフルスクリーンで
28～29fps くらい出ています。
かなり苦労しました。



caps を見ると Touch Pro なども同じかもしれません。


●苦労話

とにかく Touch Diamond では Direct3DM が全く動かなくて驚きました。
昔作ったプログラムも全滅で、WindowsMobile6 SDK のサンプルもだめ。
プログラムは動作するものの全く描画されないという症状。

caps はそれらしい値が取れていて、しかもハードウエアアクセラレータが有効との
魅力的な値を返してきます。
実際に d3dm_ati.dll が読み込まれているところまでは確認できます。

それでも画面は変わらず Clear() で埋めたカラーすら画面には現れてこないという。
D3DMPRESENT_PARAMETERS の組み合わせをいくら変えてもだめ。
画面の回転方向を変えてもだめ。

API 呼び出しは矛盾する設定をするとエラーになるので、一応動作しているようにも
見えます。

ちなみに d3dmref.dll も無いのでリファレンスラスタライザも使えません。
何とか d3dm_ati.dll が動く条件を見つけるしかなさそうです。

とりあえず Present() が悪いのかレンダリングそのものが走っていないのかだけ確認
してみます。

BeginScene();
Clear();
EndScene();
Present();

GetBackBuffer();
CopyRect(); // BackBuffer → ImageSurface
ImageSurface->LockRect()
// 読み出し
ImageSurface->UnlockRect()

こんな感じで BackBuffer の値を読み出してみると、一応カラーが書き込まれている
ことがわかりました。
Present() が失敗してるだけでレンダリングそのものは動いています。
でも Present() はエラーを返さず、Device も Lost していません。

BackBuffer には書き込まれていることがわかったので、Lock して読み出して
自分で Window に描画すれば (力業だけど) 描画できるのではないかと思いつきました。

フレームバッファの値を直接読み出して CPU で DIB に変換。CompatibleBitmap に
描画してからウィンドウにコピー。
最終的には R5G6B5 サーフェースの値がそのまま DIB として利用できることが
わかったので、転送や変換を減らして下記の通りです。

  ～
iDevice->Present( NULL, NULL, NULL, NULL );

IDirect3DMobileSurface*	iBack= NULL;
iDevice->GetBackBuffer( 0, &iBack );
iDevice->CopyRects( iBack, NULL, 0, iSurface, NULL );
iBack->Release();

D3DMLOCKED_RECT	lock;
iSurface->LockRect( &lock, NULL, D3DMLOCK_READONLY );
SetDIBitsToDevice( hDC, 0, 0, Width, Height, 0, 0, 0, Height,
		lock.pBits, &BitmapHead, DIB_RGB_COLORS );
iSurface->UnlockRect();

一応これで VGA (640x480) フルスクリーンでの Direct3DM の描画に成功しました。
でもかなり遅いです。上の最適化した状態で目測 5fps 程度。

この方法は FullScreen でも Windowed どちらでも動作しますが、最終的には
Bitmap 化するためウィンドウの中に描画しています。
転送を減らすため、試しに QVGA 240x320 くらいにフレームバッファを縮小してみます。

FullScreen の場合デバイスの解像度と一致していないとハングアップするので
Windowed = TRUE に。QVGA だとこの方法でも 15fps くらいになりました。

ふとこの状態で Lock ＆ Copy をやめてみると、DIB を通さなくてもちゃんと
描画されていて、しかも 30fps 近く出ていることを発見！
ハードウエアアクセラレータ効いています。

その後いろいろためした結果、なんと「640x480 のレンダリングだけ」失敗することが
わかりました。
例えば 1pixel 減らして 480 x 639 や 478x640 にすると描画できます。

FullScreen (Windowed = FALSE) の場合デバイスの解像度と一致していないと
エラーで落ちるので、WindowMode (Windowed = TRUE) が必須となります。


●結論

・解像度を 480x640 より小さくする (480x639 or 479x640 など)
・小さくするために必ず WindowMode にする

の条件さえ満たせば Touch Diamond でも Direct3D でポリゴン描画できます。

SDK のサンプルなど、多くのプログラムは GetSystemMetrics( SM_CXSCREEN )、
GetSystemMetrics( SM_CYSCREEN ) を使ってデバイスの解像度でレンダリング
しようとしています。これが原因でした。

わかってしまえば簡単なんだけど、、、途中何度挫折しかけたことか。
リファレンスラスタライザが使えていたらすぐあきらめていたかも。

Touch Diamond には、触れただけで反応するタッチセンサーが付いています。
ボタンやカーソルキー周りがそうです。

このタッチセンサーの値を受け取るには HTCAPI.dll を呼び出します。
ウィンドウに関連付けされ、あとはモードを設定するだけでメッセージ (WM_USER～)
で通知が来るようです。
参考にさせていただいたのは加速度センサーの読み出し同様こちらです。

・Scott's Weblog Fun with the Diamond's tilt sensor

タッチセンサーは左右に分かれており、それぞれ個別に座標値が取れます。

・中央のカーソルキーから左側、通話ボタンやホームボタン側
・中央のカーソルキーから右側、終了ボタンや ← (OK) ボタン側

座標値は左上が原点 (0,0) で、0～67 くらいの範囲。
ただし中央のカーソルキー周囲は回転のジェスチャーとして識別されるため座標が
取れません。

中央の決定ボタンは、座標が不正な範囲 (255,255) の状態で押されることで
判別できます。カメラのオートフォーカスで半押し状態がこれ。

タッチしたイベント (DOWN) と指を離したイベント (UP) が送られてくるだけで、
MOVE イベントがありません。押した座標、離した座標は取れますが、移動中の
イベントがないのでスライドによるスクロールなどには向いていないようです。

液晶面の感圧式タッチパネルだとスクロール等のスライドを指で行うのが
難しかったりするので、本当ならこちらのタッチセンサーでスクロールできたら
よかったのですが。


また左右のパネル両方同じイベント扱いなので、どちらかにタッチしてしまうと
DOWN 状態になります。座標は独立して取れるものの状態が共有なので、
マルチタッチのような使い方にも向いていないようです。

なお液晶面のタッチパネルとは別物なので、タッチボタンと液晶画面など別センサー
同士の同時タッチは可能です。


HTCNavClose() の引数は DWORD ではなく、HWND が正しいようです。
よって HTCNavSetMode() で与えた DWORD を Close() するのではなく、使い方としては
HTCNavOpen() に与えた HWND を指定して一度だけ Close() します。

中央の回転ジェスチャーは WM_USER + 200 だけでなく WM_USER + 201 にも何らかの
データが送られています。終了イベントのようですが、送られないこともあります。

いろいろ試したけど生の値が取れる方法はまだわかりません。
とりあえずボタン部分に触れただけで反応するような感度の良いアプリは作れると
思います。

同じ部分に指を置いても

(1) 触れる → タッチセンサー
(2) 押し込み → ボタン
(3) 触れたまま揺らす → 加速度センサー

といった使い分けもできるでしょう。


関連エントリ
・HTC Touch Diamond のボタン部分とタッチセンサー
・HTC Touch Diamond の加速センサー

HTC Touch Diamond の加速センサーから値を読み出してみました。
参考にさせていただいたのは下記サイトのプログラムです。

・Scott's Weblog Fun with the Diamond's tilt sensor

API は Touch Diamond に含まれている HTCSensorSDK.dll を呼び出しています。
取り出せる値は 3軸センサーのそれぞれの加速度 X Y Z。
ソースにはだいたい -1000～1000 程度の範囲で傾きと書かれていますが、
やはり重力加速度を表しているようです。
何もしない状態で ±1000 前後 (1G)。強く振ると ±2400 程度の値も取れます。

データの連続取得は 40msec 程度の間隔が必要です。
当初動かしたときは 1/30 や 1/60 sec でサンプリングしていたため、値が更新されず
少々悩みました。

使用しているセンサーはレジストリの DeviceVendor より Kionix KXSD9。

direction=5  液晶背面方向 -Z
direction=4  液晶面方向   +Z
direction=1  左サイド     -X
direction=0  右サイド     +X
direction=2  下           +Y
direction=3  上           -Y

struct SENSORDATA {
    short   ax;
    short   ay;
    short   az;
    short   zero;
    int     AngleY;
    int     AngleX;
    int	    direction;
};

例えば机の上に水平に寝かせた状態だと、液晶背面方向が重力方向だから
az = -1000 前後に、direction が 5 になります。
SENSORDATA の最後の値はこのように、大まかな端末の向きをそのまま表して いるようです。
いるようです。
AngleX/AngleY はおそらく極座標か何かだと思いますが未調査。


関連エントリ
・HTC Touch Diamond のボタン部分とタッチセンサー

HTC Touch Diamond の画面の下、ボタンのあたりは一枚板になっています。
だけどボタン部分は押し込むことができて、ちょうど iPod のクリック＆ホイール
みたいにカチッと反応するボタンが埋まっています。

この部分、アプリによっては押し込まなくても操作可能です。
カメラだとオートフォーカスの半押しができるし、Opera でカーソルのあたりを
丸くなぞるとズームできるし、その仕組みが不思議でした。
どうやらボタンの上、板の部分全体がタッチセンサーになっているようです。

液晶画面の方はこれまでのタッチパネルと同じ感圧式で、スタイラスが使えるし
ある程度圧力をかけないと反応しません。

ボタン側の方は iPhone/iPod touch のように指で触れるだけで反応するし、
スタイラスに反応しないため静電容量式だと思われます。

クリックボタンが押しにくくなるだけなのに、わざわざ一枚板になっている理由も
これでわかります。

PS3 のワイヤレスキーパッドみたいに、気がつかないところで使われている
タッチセンサーはこれからも増えそうですね。

タッチの情報を取得すれば、ズーム操作と重なるかもしれないけど
触れるだけで反応できるカーソルキーとか、
触れた場合と押し込んだ場合で動作が変わるボタンとか作れるかもしれません。
使いやすいかどうかは別として。


Touch Diamond には加速センサーが入っています。
3軸のセンサーのようで、Wii Remote 同様に重力加速度で傾きがわかります。
この情報にアクセスする方法を解析された方はいらっしゃるようで、
サンプルプログラムなどもおいてありました。

・Scott's Weblog

タッチセンサー情報が見れたのもこのプログラムのおかげです。