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

●タッチパッドのところに iPhone が埋まってるやつ

iPhone / iPod touch を使っていると、マウス代わりにこれでそのまま PC操作
できたらいいんじゃないかな、と思うことがあります。
タッチパッドの感触はなめらかでレスポンスも速いし、マルチタッチもわかりやすく、
スクロールなどの操作も心地よく動いてくれるからです。
(実際に iPhone をタッチパッド代わりにできるアプリもあるようです)

本当にそれを実現しようとしたのかどうかわかりませんが、
SHARP メビウス PC-NJ70A の見た目はまさにそれ。
センサーの仕組みはともかくマルチタッチ対応のパッドに液晶画面もついていて
独自のアプリも動くという。なんか埋まってます。

そのメビウスがようやく手元に届いたので使ってみました。

現実はそう甘くはないようです。


●光センサー液晶パッドのモード

・マウス操作モード
・タッチ操作モード


●マウスモード



通常はマウスモードで、ノートパソコンの一般的なタッチパッドとして機能します。
特徴的なのは以下の点

・表面がつるつる
・パームレストと一体型
・サイズ大きい、幅が広い
・ボタンが 3つあるけど 2ボタンマウス相当
・マルチタッチ
・多少のビジュアルエフェクトがある

つるつるなのはおそらく光学式センサーの光を通す必要があるため。
光が透過しさえすれば透明な素材で全体を覆ってしまっても構わないのでしょう。

ボタンは残念なことに 2ボタンでした。
VAIO type P は中ボタンがついていて 3ボタン。
液晶パッドの真ん中のボタンは「マウス操作」と「タッチ操作」の切り替えです。

マルチタッチの活用として二本指スクロールがあります。
EeePC 901 等と同じです。

液晶パッドの画面には、タッチ位置に遅れてついてくる光のカーソル演出があります。
この辺は設定で変更できるようです。


●タッチ操作モード



真ん中ボタンでタッチ操作モードに切り替えると、液晶パッドにメニューが出てきます。

ここでタッチを活用した独自のアプリケーションを走らせることが出来るようです。
マウスカーソルを使うウィンドウズアプリと違って、こちらは直接触って操作
できるのが特徴。

しかも光学センサー液晶パッドは他の方式と違い

・マルチタッチ対応 (何点でも？)
・静電容量式のように指が触れただけで反応する
・ペン操作もできる

等と利点も多数あります。
しかしながら画面の呼び出しや表示切り替えは決して速いとはいえず
なめらかなアニメーション演出も期待できません。

例えば電子ブックリーダーでは本のタイトル一覧が表示されるのに、タッチ操作では
上下にスクロールできません。マウスの左右ボタンで上下のページ切り替えだと
気がつくのに若干時間を要しました。(一応二本指スクロールは出来るけど描画が
ついてこない)

アプリケーションの作り込みの甘さや描画速度の遅さ、反応の悪さなど、可能性の
あるセンサーやデバイスをまだまだ使いこなせていないようにみえます。

サブ画面用に描画アクセラレータが乗っていないのか、メインメモリからの描画
転送がボトルネックなのかはまだわかりません。

センサー自体は大変ユニークで、例えば「エンターテイメント」に入っている
ピアノのアプリはマルチタッチを実感できます。
とりあえず指 4本のタッチ座標が取れているのは確認できました。

HP TouchSmart PC IQ800 のマルチタッチは 2点までだったので、今後 SDK が公開
されたり Windows7 用ドライバが出てくれば、さまざまな活用が考えられます。
今後に期待ですが、「iPhone / iPod touch が埋まっている」の域まで達するには
まだまだかかりそうです。

なおタッチ操作モードではマウスカーソルが動かないので PC の操作ができません。
外付けのマウスをつないでおけばタッチモードでも普通に使えました。


●まとめ

ネットブックなど多くのノートパソコンがあふれる中で、普通じゃない機能を持った
PC であることは確かです。
実用性よりもまずはこの点をおもしろいと思えるかどうかが評価の境目となるでしょう。
これからしばらく実際に持ち歩いて使いつつ、まずは普通の PC としてセットアップ
してみます。


関連エントリ
・メビウス PC-NJ70A 画面解像度とタッチ
・Windows7 とマルチタッチ / HP TouchSmart PC IQ800

久しぶりの歩数計関連です。
やっぱり買ってしまいました。カロリズム

・TANITA カロリズム CALORISM


ここ最近加速度センサーの普及によって歩数計がちょっとしたブームです。
例えば一般的に

(1) つける場所を選ばない

　2D または 3D の加速度センサーによって向きの制限が無くなりました。
　腰にクリップで留めなくてもいいんです。
　胸ポケットでも鞄の中でも OK

(2) 時計内蔵で自動記録

　毎日 0時に自動でカウンタをリセット。
　１～２週間分の記録が残るので、面倒な操作なしに毎日の歩数がわかります。

(3) その他

　消費カロリー表示、歩いた総時間の表示、歩数を入れておくと距離の算出、
　などはたいてい基本機能としてついてます。

新製品の出るペースが速いし種類も多いし機能も豊富でつい気になってしまいます。
ただ安価なものだと加速センサーではなく振り子スイッチ式のものがある点に注意。
振り子式のシンプルなものの方が良い場合もありますが、気楽に使えるのは
加速度センサータイプの方です。


●ハドソン てくてくエンジェル

他にもゲーム風の機能がついているものも多数あります。
特に以前紹介した「てくてくエンジェル」は機能的に侮れません。

・てくてくエンジェル DS日記 まじめレビュー

例えば
・120日間のログ保存
・乗り物に乗っている間の誤計測を遮断するスリープ機能
・毎日の記録とは別に測れる、区間計測機能
・リセット時間を変更できる昼夜のシフト機能

など、他の歩数計についていないのが不思議なくらい作り込んであります。
残念ながら欠点もあって、数日使わないでいるとえんじぇるが逃げてしまい
ゲーム＆計測が終わってしまうこと。
ただのツールじゃないのであたりまえですが使ってるとよく遭遇します。
あとは省電力のためボタンを押すまで液晶画面が消えていることでしょうか。
未使用だとバッテリーは結構持ちます。


●コナミ e-walkeylife 2

その後使っていたのはコナミの歩数計 e-walkeylife2 (健身計画２)

・e-walkeylife 2

こちらは加速センサータイプながら腰への取り付け推奨です。
しっかりしたクリップやストラップなどがついており、気楽に鞄に入れたりとかは
できません。
特徴は USB コネクタ内蔵で、PC や TV 用の健身計画２があればデータを
転送できるというもの。別売りなので結局使いませんでした。

もう一つの特徴は歩きと走りを区別してカウントできることです。
それぞれ別カウントし、かつ消費カロリーなども別計算です。
走っても良い歩数計って実はあまりないんです。
たいていは歩行のみ計測で走行時は誤計測する可能性があります。
または本気で走るなら Nike+ とかジョギング用。


●TANITA カロリズム AM-120

そして

・TANITA カロリズム

最近出たカロリズムはもはや単なる歩数計ではなく「活動量計」を名乗っています。
まず取り付ける場所が違います。
腰じゃないと計測できなかった昔の万歩計とは完全に別物。
「上半身につけてください」だそうです。

なぜなら

(1) 上半身も含めた動きを検知して、歩行以外の運動も測定
　　歩かなくても 1日の総消費カロリーがわかる

(2) 1時間毎の活動量を記録。
　　1日単位ではないので、何時頃激しく動いたのかよくわかる。

1時間単位の運動量はわかりやすいグラフ表示です。PRO TREK の気圧計みたいな。
ちゃんと 24個メモリがあるので夜型でも昼夜逆転でも大丈夫。

時間単位の詳細なグラフが残るのは一週間分。
さらに週単位で 7日分の活動量をグラフで一覧可能です。これは 12週間遡れます。

歩行計測の枠を飛び出そうとしています。
少々値段が高めですが、出勤時間、外出時間などが一目でわかるグラフは非常に
おもしろいし、、少々怖くもあります。

その他歩数計としての基本機能は押さえています。

初期設定時に体脂肪率を入れないといけないのが少々変わってるところでしょうか。
そのおかげか基礎代謝表示があるので、基礎代謝＋消費カロリーがわかるのは
ユニークです。何カロリーまで食べても大丈夫、という目安になりますね。


本体はスリムなスティック型ですが、表示も大きく見やすいものです。
CR2032 x2 個使う代わりに電池寿命は 9ヶ月と比較的長め。
長時間センサーが反応しない状態になると液晶を消してスリープ状態になるようです。
賢いのは振動を検知して自動で起動すること。
ボタンを押す必要はありません。


本来非常に高機能なはずなのに、どうにかしてシンプルかつ単純にまとめようと
苦労したあとが見えます。
それゆえ時間グラフと総活動量表示以外は比較的普通なのです。
歩数、消費カロリー、時刻、距離＆時間、エクササイズ単位やメッツなど。

モード切替は表示の切り替えだけ。
6画面あるけど表示の違いが少なくて慣れるまでちょっと見分けづらい。
メモリボタンで記録を遡れますが、1ボタンしかないので一周するまで戻れません。
当日の画面に戻らないと「週ログ←→日ログ」の切り替えが出来ないのも不便です。
週ログで間違ってメモリボタンを押してしまうと特に。

無理してボタン数を減らすよりも、てくてくエンジェルみたいに
　カーソル＋決定
とかメニュー式の方がずっとわかりやすい気がします。

リセット時間の変更が無いので、夜型かつ１日単位できっちり歩数を計測したい人は
時計をずらしておく必要があります。でも従来の歩数計と違って時間単位のグラフが
あるので、そこまでこだわらなくても十分楽しめます。

やっぱりというか区間計測機能は無いです。
カウンタの強制リセットはありますがその日の記録も消えます。

時計は時刻のみでカレンダー無し。

マニアックに見てくと、可能な操作も少なく表示画面数も少なく少々物足りない
ところがあります。

でも一目ですぐわかる時間毎のグラフはやっぱり楽しいし、その日の行動を
思い出すにも役立ちます。
Nike+ の記録はもっと詳細ですが、PC に接続しないと見れないし常時測定している
わけじゃないのでなあまり手軽とはいえませんでした。

１日あたりの歩数を増やしていこうとか、ノルマを守ろうとか、目的を達成しようとか
そういう従来の歩数計のモチベーションとは少々質が違います。
自分の毎日の行動が記録に残ってること。
それだけで興味があるし、総活動量なので歩数だけを気にしなくても良いわけです。
身につけていてもプレッシャーがずっと少ないのです。

でも…仕事してるのに、座ってずっとキーボードをたたいていてもマウスをクリック
していても、さっぱり活動量は増えません。
キータイプを消費カロリーに変換するアルゴリズムが必要です！


関連エントリ
・てくてくエンジェル DS日記 まじめレビュー

HTC E30HT の 3D caps 情報を提供していただきました。
nekomantle さんありがとうございました。

・Direct3D Mobile DeviceCaps 一覧

E30HT は 3D アクセラレータに対応していないようです。
スペックを調べてみると、同じ Touch Pro でも HT-01A/X05HT とは相違点が目立ちます。

・HTC Touch Pro E30HT
・HTC Touch Pro HT-01A
・HTC Touch Pro X05HT

通信方式の違いから使用しているチップが異なっており、
搭載されている 3D 機能も互換性がないのかもしれません。

・モバイルライフ応援日記 伊藤浩一 au初のスマートフォン「E30HT」開封レビュー（第104回）
　＞図12　起動画面。ユーザーインタフェースには「Touch FLO 3D」ではなく
　＞「Touch FLO」が搭載されています

上の記事によると Touch FLO 3D ではなく Touch FLO に変更されているとのこと。
この辺も関係がありそうです。

なお Qualcomm MSM7500 自体は 3D アクセラレータを持っています。

・西川善司の3Dゲームファンのための「東京ゲームショウ2007」グラフィックス講座


問題なのは、同じ Touch Diamond や Touch Pro 系、また同じ機種名でも互換性が
ないということです。
以前作成した d3dmclock も Touch Diamond / Touch Pro 系で動作すると書きましたが、
このデータを見る限り一概には言えなくなりました。
きちんと 3D を扱えるデバイスが少ないとか バグ とか、
WindowsMobile で 3D は何かとたいへんです。


関連エントリ
・HTC Touch Diamond で Direct3DMobile その(10) d3dmclock v1.10 3Dクロック 更新
・HTC Touch Diamond で Direct3DMobile その(9) d3dmclock v1.00 3D クロック

VisualC++ 2010 beta ではラムダ式が使えます。
無名の関数を inline で宣言することが可能で、関数オブジェクトのように
取り扱いできます。

・Download Visual Studio 2010 Beta
・Examples of Lambda Expressions

変数で受け取る場合は auto や template を使った汎用の入れ物が必要です。

auto f0= []( int x, int y ){ return x * y; };
std::tr1::function<int(int,int)> f1= f0;

lambda 式は無名の型宣言に相当するので、同等の型を明示的に宣言することが
できません。
名前をつけるだけなら下記の定義は出来ますが、これも f0 が有効な範囲のみです。

typedef decltype(f0) lambda_type2;
lambda_type2 f2= f0;

全く中身が同じ lambda 式を定義しても別の型と見なされるようです。

auto	f2= []( int a, int b ){ return	a * b; };
auto	f3= []( int a, int b ){ return	a * b; };
decltype(f2)*	fp2= &f3;  // error

上記の例はエラーです。
そのため定義内容を知らない外部から直接参照する手段がありません。

実際に使ってみると単純な関数ポインタでは無いことがわかります。

・lambda 式に応じて無名のクロージャー用クラスが定義される
・メンバとしてキャプチャした変数のコピーまたは参照が格納される
・クロージャークラスのメンバ関数として呼び出される。

確認してみます。

int v= 0;
auto  f4= []( int a, int b ){ return  a * b; };
auto  f5= [&]( int a, int b ){ return  a * b + v; };
auto  f6= [=]( int a, int b ){ return  a * b + v; };

sizeof(f4) == 1
sizeof(f5) == 8 // x64
sizeof(f6) == 4

sizeof(f4) が 1 なのは実質的にサイズが無いことを意味しています。
sizeof(f5) と sizeof(f6) はどちらも v を参照していますが、たまたま x64 で
コンパイルしていたので異なるサイズになりました。
ポインタ(参照)である証拠で x86 だと 4 になります。

auto	f4= []( int a, int b ){ return a * b; };
f4.operator()( 2, 10 );

operator() の呼び出しが出来ます。

int	v;
auto	f5= [&]( int a, int b ){ return a * b + v; };
int	r0= f5.v; // cannot access private member
int	r1= f5.w; // is not a member

直接アクセスはエラー。変数名はそのままメンバになってます。

lambda 式の定義が返す値はその場でキャプチャされたクロージャーそのものであるということ。
クロージャー未使用でも空の構造体が定義されること。
実行する関数はクロージャー型と静的に関連づけられており、そのために型は常にユニークとなること。
lambda 式の呼び出しは静的なものであってポインタでは無いということ
等がわかります。

実際に出力コードも追いかけて確認。

きちんとインライン展開されているし、これで定義を知らない外部からは直接アクセス
できない理由もわかりました。
外部関数呼び出しのようにインライン出来ない場合は std::tr1::function のような
関数オブジェクトが必要になるわけです。

struct func_base_2 {
    virtual int  operator()( int a, int b )= 0;
};

template<typename T>
struct func_impl_2 : public func_base_2 {
    T  exf;
    func_impl_2( T lambda_f ) : exf( lambda_f ) {}
    int	operator()( int a, int b )
    {
        return  exf( a, b );
    }
};

struct func_2 {
    func_base_2*   ptr;
    template<typename T>
    func_2( const T&& lambda_f )
    {
        ptr= new func_impl_2<T>( lambda_f );
    }
    template<typename T>
    func_2( T& lambda_f )
    {
        ptr= new func_impl_2<T&>( lambda_f );
    }
    int	operator()( int a, int b )
    {
        return	(*ptr)( a, b );
    }
    ～
};


    func_2    f7( []( int x, int y ){ return x*x + y*y; } );
    int   mm= f7( 3, 9 );

この場合の f7 は callback として持ち出せます。
使えるのはクロージャーが作られた関数スコープの中のみです。


関連エントリ
・VisualStudio 2010 beta1

VisualStudio 2010 beta1 を使ってみました。
環境は Windows7 RC + Windows SDK for Windows 7 RC。

とりあえずコンパイラオプションを見ると x64 に arch オプションが増えていることがわかります。
「 /arch:AVX 」すでに intel AVX に対応している様子。

実際にコンパイルすると C5 命令が見えます。
浮動小数演算部分でちょうど SSE/SSE2 命令が AVX で置き換わっている形です。
実行するとやっぱり Illegal Instruction。

float	af= 1.3f;

C5 FA 10 05 C3 51 0E 00 vmovss      xmm0,dword ptr [__real@3fa66666 (13FD5CE2Ch)]  
C5 FA 11 44 24 74    vmovss      dword ptr [af],xmm0 

直接 AVX 命令を使うには immintrin.h を include する必要があるようです。
immintrin.h には AVX の 256bit 長のデータ型 __m256 が宣言されていました。

他に追加されたオプションは auto の扱い方です。
VC++ 2010 は auto や decltype といった宣言で型をコンパイラに判断させることができます。
キーワードの意味が変わったので /Zc:auto- で無効にできるようです。

・MSDN auto Keyword

VC++ 2010 はこのように新しい言語仕様を取り入れていて、面白い機能がいろいろ
増えています。
たとえば lambda 式が使えるようになってること。

auto f_mul= []( int a, int b ) ->int { return a * b; };

宣言した無名関数をオブジェクトとして受け取れます。楽しい！
[] は capture の宣言で、クロージャーへ変数を渡す手段を記述するようです。
コピー [=] と参照 [&]、または変数個別に指定できます。
返値の型は return 文で類推しますが引数のあとの -> でも指定できます。

・MSDN Lambda Expressions in C++

auto は型を自動で判別する変数宣言で、型そのものを受け取るなら decltype() が使えます。

&& 宣言は右辺値参照。代入可能な左辺値ではなく、値としての右辺値を
参照で取れるというもの。

・Rvalue Reference Declarator: &&

実際に定数値でも参照可能となります。
この宣言は const でないので書き換えもできました。

int&& dd= 3;
dd++;

disassemble して生成コードを見ると、無名の auto 変数へ代入してからアドレスを
取っています。
どうやらこれが本来束縛されていないテンポラリで、右辺値参照によってこのような
無名領域へのアクセスが可能になるようです。
加算もその領域に対して行われています。

実際どのように使えばどんな効果があるのか、下記ページをかなり参考にさせて
いただきました。

・ntnekの日記 和訳：Rvalue References: C++0x Features in VC10, Part 2

特に効率化は期待できるようです。
例えば C++ では一時オブジェクトが何度も生成破棄されることがありますが、
受け取った引数がすでにコピーされた一時オブジェクト(右辺値)とわかっているなら
そのまま再利用してもかまわないというわけです。
コピー元のオリジナルなら左辺値。

右辺値参照の宣言は、一時領域へのアクセス手段を手に入れると同時にこのような区別も可能になります。

非常に面白いです。
今日は本来の作業の目的を忘れてずっと VisualStudio 2010 。

久しぶりに影を扱ったのでメモです。

Direct3D 10 以降、ShaderModel 4.0 以降はハードウエアシャドウマップが当たり前に
使えるようになっているので比較的簡単になりました。
Direct3D8 ～ Direct3D9、ShaderModel 1.0 ～ 3.0 までは NVIDIA GeForce
独自の拡張機能でした。ハードウエアシャドウマップは

・DepthBuffer を直接参照するため他にバッファを用意することがないこと
・通常のサンプリングと違い、比較した結果の Bool 値 1.0 or 0.0 を返すこと
・比較結果をバイリニア補間するため、追加コストなしにハードウエアでフィルタリング可能なこと

等の利点があります。
ShaderModel 2.0 以降なら同等の機能をシェーダーで記述することができます。
旧 RADEON 向けシェーダーでは必須となりますが、追加バッファが必要でバイリニア
用サンプリングのコストがゼロにならないので完全に同じとはいえませんでした。

Direct3D 10 では標準機能の一部になったので、ShaderModel 4.0 に対応した
RADEON HD 2900XT 以降はハードウエアシャドウマップが使えます。
下位の ShaderModel でも利用可能で、RADEON HD 2900XT では
ShaderModel 3.0 を使っても GeForce 向けシェーダーがそのまま動作しました。
最初試したときは感動。

ShaderModel 4.0 以降は値を比較しながらサンプリングできる汎用機能として用意されて
いるので、GeForce 用、RADEON 用とシェーダーやプログラムを分ける必要がなくなりました。

バッファの作成

// depth buffer 用リソースの作成
CD3D11_TEXTURE2D_DESC	ddesc(
		DXGI_FORMAT_R24G8_TYPELESS,
		width,
		height,
		1,	// array
		1,	// mip
		D3D11_BIND_SHADER_RESOURCE | D3D11_BIND_DEPTH_STENCIL,
		D3D11_USAGE_DEFAULT,
		0,	// cpu
		1,	// sample count
		0,	// quality
		0	// misc
		);

iDevice->CreateTexture2D( &ddesc, NULL, &iShadowDepth );


// Depth Buffer 用 View の作成
// レンダリング時はこちら
CD3D11_DEPTH_STENCIL_VIEW_DESC	dsdesc(
		D3D11_DSV_DIMENSION_TEXTURE2D,
		DXGI_FORMAT_D24_UNORM_S8_UINT,
		0,	// mipSlice
		0,	// firstArraySlice
		1,	// arraySize
		0	// flags
		);

iDevice->CreateDepthStencilView( iShadowDepth, &dsdesc, &iShadowDepthView );

// Shader Resource 用 View の作成
// サンプリング時はこちら
CD3D11_SHADER_RESOURCE_VIEW_DESC	sdesc(
		D3D11_SRV_DIMENSION_TEXTURE2D,
		DXGI_FORMAT_R24_UNORM_X8_TYPELESS,
		0,	// mostDetailedMip
		1,	// mipLevels
		0,	// firstArraySlice
		1	// arraySize
		);

iDevice->CreateShaderResourceView( iShadowDepth, &sdesc, &iShadowView );

使用している CD3D11_TEXTURE2D_DESC や CD3D11_DEPTH_STENCIL_VIEW_DESC
等は DirectX SDK March 2009 以降使えるようになった新機能です。
各種構造体を初期化してくれるヘルパーで、D3D11.h で定義されています。
ヘッダを見て発見しました。

サンプラーの作成

CD3D11_SAMPLER_DESC	desc( D3D11_DEFAULT );

desc.AddressU= D3D11_TEXTURE_ADDRESS_CLAMP;
desc.AddressV= D3D11_TEXTURE_ADDRESS_CLAMP;
desc.AddressW= D3D11_TEXTURE_ADDRESS_CLAMP;

desc.Filter= D3D11_FILTER_COMPARISON_MIN_MAG_LINEAR_MIP_POINT;
desc.ComparisonFunc= D3D11_COMPARISON_LESS;

iDevice->CreateSamplerState( &desc, &iShadowSampler );

比較結果のフィルタリングなので、D3D11_FILTER_COMPARISON_～ と
COMPARISON 付きのフィルタを指定します。
CD3D11_SAMPLER_DESC に渡している D3D11_DEFAULT は、デフォルト値で構造体を
初期化することを意味しています。

クリアと RenderTarget の設定

void __fastcall
ShadowBuffer::Clear( ID3D11DeviceContext* iContext )
{
	iContext->ClearDepthStencilView( iShadowDepthView,
		D3D11_CLEAR_DEPTH|D3D11_CLEAR_STENCIL, DVF(1), 0 );
}

void __fastcall
ShadowBuffer::SetRenderTarget( ID3D11DeviceContext* iContext )
{
	ID3D11RenderTargetView*	irtv= NULL;
	iContext->OMSetRenderTargets( 1, &irtv, iShadowDepthView );

	CD3D11_VIEWPORT	view( DVF(0), DVF(0), ShadowWidth, ShadowHeight );
	iContext->RSSetViewports( 1, &view );
}

ShadowBuffer にレンダリングする場合の前処理です。
OMSetRenderTargets() では DepthBuffer のみ指定します。
RenderTarget が NULL の場合書き込みが行われません。

リソースの設定

void __fastcall
ShadowBuffer::SetResources( ID3D11DeviceContext* iContext )
{
	iContext->PSSetShaderResources( SHADOW_REGISTER_ID, 1, &iShadowView );
	iContext->PSSetSamplers( SHADOW_REGISTER_ID, 1, &iShadowSampler );
}

作成した ShadowBuffer を用いて影描画する場合の前設定です。
シェーダーとのバインドを簡略化するために、ShadowBuffer 用のレジスタ番号を
決めうちにしています。

シェーダー

struct VS_INPUT {
	float3	vPos	: POSITION;
	float3	vNormal	: NORMAL;
	float2	vTex0	: TEXCOORD;
#if CF_WEIGHT
	float4	vWeight	: WEIGHT;
	uint4	vIndex	: INDEX;
#endif
};

struct VS_OUTPUT {
	float4	vPos	: SV_Position;
	float2	vTex0	: TEXCOORD;
};

VS_OUTPUT vmain( VS_INPUT idata )
{
	VS_OUTPUT	odata;
	float4x4	world;

#if CF_WEIGHT
	world=  World[idata.vIndex.x] * idata.vWeight.x;
	world+= World[idata.vIndex.y] * idata.vWeight.y;
	world+= World[idata.vIndex.z] * idata.vWeight.z;
	world+= World[idata.vIndex.w] * idata.vWeight.w;
#else
	world= World[0];
#endif

	float4	wpos= mul( float4( idata.vPos.xyz, 1 ), world );
	odata.vPos= mul( wpos, PV );
	odata.vTex0= idata.vTex0;

	return	odata;
}

typedef VS_OUTPUT	PS_INPUT;

Texture2D	tex0		: register( t0 );
SamplerState	sample0		: register( s0 );

float pmain( PS_INPUT idata ) : SV_Target
{
#if CF_ALPHA1BIT
	float	alpha= tex0.Sample( sample0, idata.vTex0.xy ).w;
	if( alpha < 0.8f ){
		clip( -1 );
	}
#endif
	return	0;
}

ShadowBuffer を生成する場合は特別なことが何もありません。
カラーを書かないので不要に見えますが、テクスチャの Alpah 抜きに対応する場合は
テクスチャも読み込まなければならなくなります。

今回は特別なことを何もしてないので大丈夫ですが、影の合成を効率化しようと
凝ったことをし出すとテクスチャの扱いが結構負担になってきます。
パス毎にフィルタリングや Mip 指定、uv の計算等を厳密にあわせておかないと、
ちょっとしたレンダーステートの差がテクスチャの隙間を生み出してしまうからです。
例えば DepthBuffer の事前生成など。

描画用シェーダー

struct VS_INPUT {
	float3	vPos	: POSITION;
	float3	vNormal	: NORMAL;
	float2	vTex0	: TEXCOORD;
#if CF_WEIGHT
	float4	vWeight	: WEIGHT;
	uint4	vIndex	: INDEX;
#endif
};

struct VS_OUTPUT {
	float4	vPos	: SV_Position;
	float3	vNormal	: NORMAL;
	float2	vTex0	: TEXCOORD;
	float4	vShadow	: SHADOW;
};

VS_OUTPUT vmain( VS_INPUT idata )
{
	VS_OUTPUT	odata;
	float4x4	world;

#if CF_WEIGHT
	world=  World[idata.vIndex.x] * idata.vWeight.x;
	world+= World[idata.vIndex.y] * idata.vWeight.y;
	world+= World[idata.vIndex.z] * idata.vWeight.z;
	world+= World[idata.vIndex.w] * idata.vWeight.w;
#else
	world= World[0];
#endif

	float4	wpos= mul( float4( idata.vPos.xyz, 1 ), world );
	odata.vPos= mul( wpos, PV );
	odata.vNormal.xyz= mul( idata.vNormal, (float3x3)world );
	odata.vTex0= idata.vTex0;

	odata.vShadow= mul( wpos, ShadowMatrix );

	return	odata;
}

typedef VS_OUTPUT	PS_INPUT;

Texture2D	tex0		: register( t0 );
SamplerState	sample0		: register( s0 );

Texture2D		shadowTex0	: register( t8 );
SamplerComparisonState	shadowSample0	: register( s8 );

float4 pmain( PS_INPUT idata ) : SV_Target
{
	float3	diffuse= Ambient.xyz;
	float3	specular= float3( 0, 0, 0 );
	float4	color= float4( 0, 0, 0, 0 );

	float3	sh_uv= idata.vShadow.xyz;
	sh_uv.xyz/= idata.vShadow.w;
	sh_uv.x=  sh_uv.x * 0.5f + 0.5f;
	sh_uv.y= -sh_uv.y * 0.5f + 0.5f;
	sh_uv.z-= 0.000004f; // 適当

	float	shdepth= shadowTex0.SampleCmpLevelZero( shadowSample0, sh_uv.xy, sh_uv.z );
//	float	shdepth= shadow_pcf( sh_uv );
	lightMask= saturate( shdepth + 0.0f );

	float3	normal= normalize( idata.vNormal.xyz );
	diffuse.xyz+= saturate( dot( normal, _LightDir ) ) * Diffuse.xyz * lightMask;
	specular.xyz+= pow( saturate( dot( normal,
		normalize(idata.vEyeVec + _LightDir ) )), Specular.w )
				* Specular.xyz * lightMask;

	float4	texcol= tex0.Sample( sample0, idata.vTex0.xy );
	color.xyz+= texcol.xyz * diffuse.xyz + specular.xyz;
	color.w= texcol.w * Ambient.w;

#if CF_ALPHA1BIT
	if( color.w < 0.8f ){
		clip( -1 );
	}
#endif
	return	color;
}

VertexShader では描画用の Matrix と影用の Matrix、2つの座標系へ変換します。
実際の PixelShader は非常に長いので光源演算を大幅に削りました。

影のサンプリングは SampleCmpLevelZero() を使っています。
Depth を読み込み、指定した z 値と比較した結果をフィルタリングして返すので、
対応する光源に対して影の中かどうかわかります。
影用 uv への変換は効率化するなら Matrix に埋め込んでおくことができます。
埋め込むと影を落とすときと完全に同じ Matrix にならないことが難点。

基本的な描画手順

// Shadow Buffer の作成
ShadowBuffer->Clear( iContext );
ShadowBuffer->SetRenderTarget( iContext );
iContext->OMSetDepthStencilState( iDSS_ZEnable, 0 );

　// shadow レンダリング用 matrix の設定など
　// shadow buffer 生成のシェーダーで描画


// 影をサンプリングしながらレンダリング
　// 本来の RenderTarget の設定
　// レンダリング用 matrix の設定
ShadowBuffer->SetResources();

　// 描画用シェーダーで描画

影、不透明、半透明 といった順番になります。
DepthBuffer の事前生成を行う場合や、複数の光源の影を落とす場合は描画パスが増加していきます。
alpha 抜きを使う場合は半透明と同じように、さらに別グループに分類した方が良いかもしれません。

関連エントリ
・DirectX SDK March 2009
・Direct3D 10 DXGI_FORMAT の機能対応一覧
・D3D10/DX10 D3D10_FILTER の新機能
・D3D10/DX10 RADEON HD2900XT

SHARP メビウスのモニターに当選してしまいました。

募集がすぐ終わったとか倍率高いとか新しいセンサーを使っているとか、
ちょうどその話をしていた直後だったので目を疑いました。
なにせ「募集時点ではスペックや詳細が未発表だったので、自分はもっと小型の
デバイスを期待してた・・」とかその場で興味なさそうに発言してた本人が
当たってしまったのだから尚更です。

すでに発売されているようですが、モニター自体は来週以降なので少々待たされます。

・SHARP Mebius PC-NJ70A

スペック的にはほぼ一般的な Atom N270 PC です。
特徴的なのは独自のタッチパッド。
液晶画面がついているだけでなくセンサーも兼ねた代物で、画素一つ一つが光を
読み取っているようです。
この新しいデバイス＆センサーは使ってみたいところです。

もう1つ興味あるのは、タッチパッド部の液晶も結構解像度が高いこと。
854x480 ドットというと初代 EeePC 701 とほぼ同じ広さな訳ですから
この中でデスクトップやらブラウザやら普通に動かしていたことになります。
タッチパネル部のサブ画面をウィンドウズでどこまで自由に使えるかわかりませんが、
画面を広くするためのひとつの方法かもしれません。

思い返すと初めて買ったノート PC がSHARP メビウス ワイド PC-W100 でした。
メビウスワイドの画面は偶然にも同じ 1024x600 ドットです。

ネットブックが出てから 1024x600 ドットはごく普通のありふれたサイズに
なりましたが、13年前の当時は大変珍しいものだったのです。
横をのばしたというよりも 1024x768 から縦を削ってキーボードを圧迫せずに
本体サイズを小さくしようとしたもの。

当時のスペックをあらためて見ると Windows95 で RAM は 16MByte に HDD 1GByte。
CPU も Pentium 133MHz。さすがに 13年の年月を感じます。
これでも当時は DirectX3～5 を入れて Direct3D の RampDriver でプログラムを書いていました。

メビウスワイドから今まで、この間に使ってきたノート PC は
1024x600～1024x768 が圧倒的に多かったことに気がつきます。
記憶容量も演算速度もバス速度も描画速度も著しく向上しているはずなのに、
意外なほど長期間にわたって小型ノート PC の解像度が変化しませんでした。

もちろん最近は LOOX U の 1280x800 や VAIO type P の 1600x768 のように、
より詳細な液晶画面を搭載するものも出てきています。

PC-NJ70A を見て思ったのは、高解像度化に消極的なメインの液晶画面の代わりに
サブモニタを増やしてマルチ画面化するのも小型ノートパソコンの方向の 1つとして
ありなのかもしれないということ。
CPU が Multi core 化するように。

あとはサブ画面をどこまで自由に使えるか。
もしかしたら Windows SideShow でしょうか。
無理かもしれないけど理想はデスクトップの延長として使えることです。
Windows7 だと multi touch API が整備されているので、もしドライバがあるなら
すぐにでも使いたいところです。
現在 Multitouch 対応 PC として HP TouchSmart PC IQ800 を触っていますが
外周にセンサーを配置した光学式で 2点まで同時に識別することができます。
PC-NJ70A ではもっと自由に点を取れたらいいですね。

期待点まとめ
・タッチパッドとして
・画面の拡張、サブ画面として
・マルチタッチ対応センサー付きモニタとして
・別の入力手段として、位置的に親指シフトキーを配置できたりするかも


関連エントリ
・Windows7 とマルチタッチ / HP TouchSmart PC IQ800

DXGI1.1 のアダプタ列挙を試します。

●EeePC901-X で実行した場合 (Windows7 RC x86)

// EeePC 901-X
[Mobile Intel(R) 945 Express Chipset Family (Microsoft Corporation - WDDM 1.0)]
   vmem:0MB sysmem:64MB shmem:192MB
   flag=0 

945 内蔵 GPU が列挙できています。
実際に Direct3D10 / 11 デバイスを作るとエラーなので、ドライバがまだ D3D10 Level9
に対応していないことがわかります。


●デスクトップ PC で実行した場合 (Windows7 RC x64)

// Desktop PC
[ATI Radeon HD 4800 Series ]
   vmem:504MB sysmem:0MB shmem:2811MB
   flag=0 
  (Direct3D11)
   *HARDWARE  = 10.1 (a100)
[ATI Radeon HD 4670]
   vmem:504MB sysmem:0MB shmem:2811MB
   flag=0 
  (Direct3D11)
   *HARDWARE  = 10.1 (a100)

2枚差したビデオカードが両方とも列挙されています。
それぞれ 10.1 でデバイスの作成ができます。


●リモートデスクトップ経由で実行した場合

[Mobile Intel(R) 945 Express Chipset Family (Microsoft Corporation - WDDM 1.0)]
   vmem:0MB sysmem:64MB shmem:192MB
   flag=1 REMOTE
[ATI Radeon HD 4800 Series ]
   vmem:504MB sysmem:0MB shmem:2811MB
   flag=0 
  (Direct3D11)
   *HARDWARE  = 10.1 (a100)
[ATI Radeon HD 4670]
   vmem:504MB sysmem:0MB shmem:2811MB
   flag=0 
  (Direct3D11)
   *HARDWARE  = 10.1 (a100)

EeePC 901 からデスクトップ PC に接続しています。

予想通り両方のマシン、すべてのアダプタが見えていることがわかります。
EeePC の 945 では DXGI_ADAPTER_DESC1 の Flags に DXGI_ADAPTER_FLAG_REMOTE bit が立っており、このデバイスを区別することが可能です。
プログラム自体はホスト側のデスクトップ PC で走っているので、プログラムから見れば
クライアントである EeePC の方がリモートです。

もし Remote のアダプタが Command Remoting に対応していれば
ネットワークを経由していてもクライアント側の PC でリアルタイムに
レンダリングすることが可能となります。

ちなみに DXGI1.0 で列挙するとホスト側の最初のアダプタ "RADEON HD4850" しか
見えませんでした。


● Feature

各アダプタの詳細を調べると下記の通り。
いわば Direct3D11 における caps です。

[DEFAULT]
  (Direct3D11)
   *HARDWARE  = 10.1 (a100)
     feature threading  DriverConcurrentCreates=0
     feature threading  DriverCommandLists=0
     feature d3d10_x ComputeShaders_Plus_RawAndStructuredBuffers_Via_Shader_4_x=0
     feature doubles  DoublePrecisionFloatShaderOps=0
   *REFERENCE = 11.0 (b000)
     feature threading  DriverConcurrentCreates=0
     feature threading  DriverCommandLists=0
     feature d3d10_x ComputeShaders_Plus_RawAndStructuredBuffers_Via_Shader_4_x=1
     feature doubles  DoublePrecisionFloatShaderOps=1
   *WARP      = 10.1 (a100)
     feature threading  DriverConcurrentCreates=0
     feature threading  DriverCommandLists=0
     feature d3d10_x ComputeShaders_Plus_RawAndStructuredBuffers_Via_Shader_4_x=0
     feature doubles  DoublePrecisionFloatShaderOps=0

[ATI Radeon HD 4800 Series ] (V:4098 D:37954 S:84021250 R:0)
   luid:000097b2 00000000
   vmem:504MB sysmem:0MB shmem:2811MB
   flag=0 
  (Direct3D11)
   *HARDWARE  = 10.1 (a100)
     feature threading  DriverConcurrentCreates=0
     feature threading  DriverCommandLists=0
     feature d3d10_x ComputeShaders_Plus_RawAndStructuredBuffers_Via_Shader_4_x=0
     feature doubles  DoublePrecisionFloatShaderOps=0

[ATI Radeon HD 4670] (V:4098 D:38032 S:625086466 R:0)
   luid:0000b18e 00000000
   vmem:504MB sysmem:0MB shmem:2811MB
   flag=0 
  (Direct3D11)
   *HARDWARE  = 10.1 (a100)
     feature threading  DriverConcurrentCreates=0
     feature threading  DriverCommandLists=0
     feature d3d10_x ComputeShaders_Plus_RawAndStructuredBuffers_Via_Shader_4_x=0
     feature doubles  DoublePrecisionFloatShaderOps=0

以前 DirectX SDK Nov2008 時点で調べた結果はこちら。
ほとんどのオプションは 0 のままですが、よく見ると REFERENCE で
DoublePrecisionFloatShaderOps が 1 になっていました。
REFERENCE を使えばシェーダーの double 演算命令もテストできるようになったということです。

同記事 でも触れていますが ComputeShader 4.0/4.1 については November の時点ですでに対応していますね。


関連エントリ
・Direct3D DXGI とマルチ GPU (アダプタ)
・Windows7 リモートデスクトップと Direct3D
・Direct3D11/DirectX11 (4) FeatureLevel と旧 GPU の互換性、テクスチャ形式など

PC を入れ替えて複数のビデオカードを同時に使えるようになりました。
対応マザーとそれなりの電源が必要です。
いろいろ試しています。

マルチ GPU といっても SLI や CrossFire のことではなく、
それぞれ独立した GPU として使います。

例えば GeForce と RADEON の 2枚差しで、それぞれにモニタをつないで
マルチモニタのように使用することができます。

・GeForce GTX260 → モニタ1
・RADEON HD4670 → モニタ2

GeForce は モニタ1 の描画を行い、RADEON は モニタ2 へ出力を行っています。
Windows から使っている分には 1枚のビデオカードに複数モニタをつないだ状態と
何も変わりません。
広いデスクトップとして使用可能で双方にまたがったウィンドウも配置できます。


ここまでは理解できますが Direct3D を使った場合はどうなるでしょうか。
D3D10CreateDevice / D3D11CreateDevice 時に PC につながっている任意のアダプタ
(GPU)を与えることが可能です。
どちらの GPU でも同じように使えるし、どちらのモニタにも描画することができました。
行き来もできるし中間に配置しても動いています。

このあたりをコントロールするのが DXGI で、非常に柔軟な使い方が可能となっています。

・IDXGIAdapter = GPU
・IDXGIOutput = モニタ

現在利用可能なアダプタとモニタは

IDXGIFactory::EnumAdapters()
IDXGIAdapter::EnumOutputs()

で列挙可能です。モニタに接続されていないアダプタも描画に使うことができます。
DXGI1.1 ではこれにさらに Command Remoting が加わります。
リモートデスクトップでアクセスしている場合に、ホストとクライアントどちらの
アダプタでレンダリングするか選択できるわけです。


●サンプルで確認

DirectX SDK 付属の Direct3D 11 のサンプルプログラムを起動するとウィンドウに
アダプタ名 (GPU名) が表示されています。
モニタ間 (アダプタ間) を行き来するとアダプタ名が切り替わるので違いがよくわかります。
プログラム的にはわざわざアダプタを切り替える必要は無いのですが、
DXUT では敢えてこのような仕様になっているようです。(理由は後述)


●プログラムで確認

実際にプログラムを書いて任意のアダプタで動かしてみました。

・RADEON HD4850 → モニタ1
・RADEON HD4670 → モニタ2

IDXGIFactory::EnumAdapters() でアダプタを列挙して、任意のアダプタを使って
デバイスを作成します。

// 列挙
IDXGIAdapter1*	iAdapter= NULL;
IDXGIFactory1*	iFactory= NULL;
CreateDXGIFactory1( __uuidof(IDXGIFactory1), reinterpret_cast( &iFactory ) );
for( unsigned int index= 0 ;; index++ ){
	HRESULT	ret= iFactory->EnumAdapters1( index, &iAdapter );
	if( ret == DXGI_ERROR_NOT_FOUND ){
		break;
	}
	// ～ アダプタの選択
	// iAdapter->Release();
}
iFactory->Release();


// 作成
HRESULT	hr= D3D11CreateDeviceAndSwapChain(
		iAdapter,
		iAdapter ? D3D_DRIVER_TYPE_UNKNOWN : DriverType,
		NULL,	// software
		D3D11_CREATE_DEVICE_DEBUG,// flags
		NULL,	// featurelevels
		0,	// featurelevels
		D3D11_SDK_VERSION,
		&SwapChainDesc,
		&iSwapChain,
		&iDevice,
		&FeatureLevel,
		&iContext
	);

アダプタは IDXGIFactory::EnumAdapters() で列挙したハードウエアアダプタ、
もしくは IDXGIFactory::CreateSoftwareAdapter() で作成したソフトウエアアダプタです。
すでに TYPE を特定できるので、DriverType には D3D_DRIVER_TYPE_UNKNOWN を
与えなければなりません。(最初ここではまりました)

結果

RADEON HD4850 → モニタ1  : 257fps
RADEON HD4850 → モニタ2  : 205fps

RADEON HD4670 → モニタ1  : 140fps
RADEON HD4670 → モニタ2  : 164fps

HD4850 ではモニタ1 の方が高速、HD4670 ではモニタ2 の方が高速です。
アダプタから直接出力した方が速く、予想通りの結果といえます。
同時にたとえ直結されていなくても、モニタ2 の描画も HD4850 が行った方が速いこともわかります。

DirectX SDK 付属サンプルの DXUT がウィンドウの位置を監視して、モニタに応じて
デバイスを作り直しているのは少しでも高速に動作するためだと考えられます。

昔はビデオカードを何度も何度も差し直して開発していました。
GeForce と RADEON の挙動を同時に確認できるなんて、大変便利になったものです。
上のテストの最中、途中で GeForce GTX260(192sp) から HD4850 に差し直したのは
本日非常に暑かったからです。


関連エントリ
・Windows7 リモートデスクトップと Direct3D

Windows7 RC と同時に WindowsSDK の RC 版も出ています。

・Microsoft Windows SDK for Windows 7 and .NET Framework 3.5 SP1: RC
・Microsoft Windows SDK for Windows 7 and .NET Framework 3.5 SP1: RC (ISO)

BETA 時点からタッチ周りの API など変更されているところがあるので要注意です。
たとえば WM_TOUCHDOWN, WM_TOUCHUP, WM_TOUCHMOVE 等は無くなり
WM_TOUCH に統一されているようです。

マニュアルも更新されています。
以前 User Interface の下にあった Touch 関連が Windows Touch
という新項目にまとめられています。このあたり力が入ってます。

・MSDN Windows Touch

Direct3D11 関連も DirectX SDK March 2009 より新しいものが含まれていました。
ただし d3d11.lib などの lib 名に _beta がついていないので include の順番に
注意した方が良さそうです。
Vista で使う場合は DXSDK の方を。


関連エントリ
・Windows7 Multitouch API その(2) WM_GESTURE 系
・Windows7 Multitouch API
・DirectX SDK March 2009

Windows7 RC を入れた type P はAero がそれなりに動いているので印象が変わりました。
現在透明感 off で使用しています。

・個人設定→ウィンドウの色→「透明感を有効にする」のチェックを外す

半透明ではないもののウィンドウの重なりがハードウエア描画なので速いです。
たとえばウィンドウ移動とか最小化のアニメーションとかそこそこスムーズに
できますし(たまにかくつくけど)、タスクバーにマウスカーソルを乗せると
ウィンドウの縮小イメージもポップアップで出ます。
ウィンドウの中の描画速度は変わらないけど、操作の印象は良くなりました。

たまに背景の描画が追いつかないのか真っ黒に崩れることがあります。
フレームバッファが消えてしまった状態ですが、以前から同じ症状があった気がするので
また違う問題かもしれません。


Aero が動くということは D3D も動くようになったということ。
GMA500 がどの Feature Level まで対応しているのか Direct3D11 で試してみました。
結果は残念ながら FEATURE_LEVEL_9_1 ～ 3 も未対応。
ハードウエアでは動作しませんでした。

Direct3D11 サンプルや一部のアプリケーションが動くのは、ソフトウエアレンダラ
WARP Device を呼び出しているからです。
D3D11CreateDevice～() の D3D_DRIVER_TYPE_HARDWARE でエラーが出た場合、
D3D_DRIVER_TYPE_WARP できちんと作り直しているアプリは動きます。
D3D11 サンプルが動いて D3D10 が動かないのはおそらくアプリが WARP に対応していないから。
D3D10 LEVEL_9_1 ～ に対応していないということは Direct2D を使う場合もおそらく
CPU レンダラになります。
ハードウエア対応は今後に期待。現状未対応でもとりあえず動くのは WARP のおかげです。

●結論
GPU は Direct3D 9 3.0 まで対応しているものの、
現状では Direct3D10/11 の下位モードの Level9 でも動作せず。
WARP なら動く。


関連エントリ
・VAIO Type P の Windows7 RC は Aero が有効

コンパイル時間

(1) Atom Z540    11分44秒 (704秒)
(2) Core i7 920      37秒

(1) 詳細
Atom Z540 1.86GHz 1core 2threads
RAM 2GB, SSD 64GB (VAIO type P), AC電源
Windows7 RC x86, Aero ON
VC2008 cl /MP4 (4thread指定)

(2) 詳細
Core i7 920 2.66GHz 4core 8threads
RAM 6GB, HDD 1TB
Windows7 RC x64
VC2008 cl /MP10 (10thread指定)

実行したのはライブラリのコンパイルでコマンドラインから /MP スイッチ付き。
x86 debug, x86 release, x64 debug, x64 release の 4種を全部作成。
同じファイルを何度も読む＋コンパイル自体数回実行したので
RAM が多ければソースはキャッシュに乗ってる状態です。
ただし同時に 8 file 未満のコンパイルが行われることもあるので CPU は 100% 埋まっていません。
スレッドがすべて埋まる条件なら core 数の多い Core i7 とはもっと速度差が開くと思います。
おそらくもっと速いでしょう。

仮に Atom が 4core で、ストレージとバスの影響を無視して 4倍速になると仮定しても 176 秒。
さらに Atom が同じ 2.66GHz で動いたとしても 123 秒。
多めに見積もってもまだ 3.3 倍開きがあります。

超多忙が和らいだので VAIO type P に Windows7 RC を入れてみました。
BETA と同様クリーンインストールです。ドライバはほぼ自動で入ります。
一つだけ不明なデバイスがありましたが、おそらく Fn キー周りと思われます。


(1) 準備
　Windows7 RC x86 DVD
　USB 接続の DVD ドライブ
　VAIO typeP のプリインストール Vista から取り出しておいたドライバフォルダ
　　　C:\Windows\drivers の下

(2) インストール
　外付けドライブから起動したあと 64GB SSD を全部消してクリーンインストールです。

(3) ネットワーク設定を行い自動更新します
　推奨にもチェック。ドライバが入ります。

(4) 不明なドライバを入れます
　デバイスマネージャーを開いて不明なデバイスのドライバを検索
　(1) で保存しておいたフォルダを指定すれば勝手に入ります。

(5) Wireless LAN ドライバの入れ替え
　そのままでも無線 LAN ドライバが入りますが 150Mbps 接続だったので入れ替えました。
　300Mbps 接続になりました。
　デバイスマネージャーからネットワークアダプター
　　→ Atheros～ の上で右ボタンからドライバーソフトウエアの更新
　　→ コンピュータを参照して～を選択
　　→ 自動検索だとすでに最新といわれるので、下の
　　　　「コンピューター上のデバイスドライバーの一覧から選択します」を選ぶ
　　→ ディスクの使用ボタン → 参照
　　→ (1) で保存したフォルダから 「Wireless LAN Driver (Atheros)」を選択して OK
　　→ そのまま次へ、でドライバが入る

(6) エクスペリエンスインデックスの計測
　いろいろ設定する前に「コンピューター」のプロパティから
　Windows エクスペリエンスインデックスの評価を実行しておきます。
　少々時間がかかりましたが、評価が終わったら Aero Glass が有効になっていました。

プロセッサ　         1.2  (Z540)
メモリ               4.1
グラフィックス(Aero) 2.9
グラフィックス(Game) 2.4
ハードディスク       5.9  (SSD 64GB)

(7) 画面の輝度調整

　BETA 同様下記ソフトで代用。ボリューム調整は何もしなくてもできます。
・backlightwin 1.00


● Windows7 RC 描画

ドライバの不具合が無くなったのか DWM も動いており、起動時のエラーダイアログも無くなっています。
これで動作確認のために Vista を残しておかなくてもよくなりそうです。
Aero Glass も動くようになりました。Vista 上で使うより多少ましに見えます。
透明感の設定を外すと少々軽くなります。

Direct3D11 サンプルもいつもの MultithreadRendering11 は一応動きました。
動作は 0.14fps、リファレンスと間違えるほど重いです。
Feature Level が 10.1 なので調べるとソフトウエアレンダラの WARP Device が使われていました。
Direct3D9 はきちんと GPU で動いています。
この辺はあとでもう少し詳しく調べてみます。


● Windows7 RC 全般

スタートメニューの個人用フォルダーが Vista 同様の個人フォルダに戻りました。
ライブラリはメニューとして分離しています。個人的にはこれが一番うれしい変更です。
BETA ではタスクバーに desktop のツールバーを置いて代用してました。

その代わり多用していた新規作成のショートカットが W から X に変更されてしまいました。
これ今までも何度も変更されているのであきらめています。

マイコンピュータのプロパティ(システム) にこんな表示が
「Pen and Touch: No Pen or Touch Input is available for this Display」


関連エントリ
・VAIO type P Windows7 beta とバックライト調整など
・Windows ノート PC の backlight の明るさ変更方法