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

WindowsVista の VirtualStore

Vista 使っていて Program Files にあるはずのファイルが見つからなくて焦る
ことがあります。アプリケーションのファイルダイアログからはちゃんと
Program Files の下にファイルあるように見えるのに、直接 explorer で開くと
そこには何もありません。

そんなときは C: の「ユーザー」フォルダ以下
「 <ユーザー名>\AppData\Local\VirtualStore\Program Files 」
を探すとみつかります。AppData は隠し属性のフォルダです。

アプリケーションによっては、直接インストールされたフォルダにデータを書き込む
ものがあります。これだとユーザー間で共有されてしまうし、Program Files の書き
換えを禁止して保護したいのにできないしと、UAC のもとではいろいろと不都合が
あるのでしょう。

なので Program Files 以下への書き込みは、ユーザー毎のプロファイルフォルダに
格納されるようです。

PSPで十字キーが斜めに入らない理由

いまさらだけど、PSPの十字キーが斜めに入らないので何とかならないか調べています。
なぜかというと今度 KONAMI から出るゲームをやりたいからです。

以前グラディウスポータブルを購入しましたが、やっぱり PSPの十字キーで斜め移動が
できません。4方向ジョイスティックでプレイしてる状態になってしまいます。
アナログコントローラの方がまだ操作しやすい感じでした。
http://www.konami.jp/gs/game/gra_psp/ (グラディウスポータブル)

来年1月にはさらに、
「ツインビーポータブル」、「沙羅曼蛇ポータブル」、「パロディウスポータブル」
が出てしまうので、もうちょっと何とか操作性を改善したいのです。
http://www.konami.jp/gs/game/shooting_tsp/index.html

○斜めに入りにくい理由1

十字キーのボタンは内部で1パーツですが、ボタンの間隔が他のコントローラよりも
離れているように感じます。斜めに押したときに指の面積と圧力が足りなくて片方
しか押されていないのかもしれません。

これはボタンの上に乗せる円盤状で一体型の十字キーパーツで改善できそうです。
http://www.watch.impress.co.jp/game/docs/20060710/ggl.htm
パーツだけ売っていたので手に入れてみました。

斜め方向に対して非常にボタンを押しやすくなりました。操作も軽くて指も挟まらず
痛くならないし良い感じです。でもやっぱり斜めに入らないことがあります。
自分の初期型 PSP では、右上と右下はOKなのに、左上と左下には入りません。

同じ力と押し具合でも上、左、下、左と4方向にはちゃんと入るのに、なんで斜めの
場合だけきちんと入力できないのか非常に不思議です。

○斜めに入りにくい理由2

で、ふとボタンのランドパターンに問題があるのではないかと思いつきました。
そのせいで、十字キーが斜めに倒れているとだめで、まっすぐ押さないとボタンが
押されたことにならないのではないかと。

こちらの分解記事の
http://pc.watch.impress.co.jp/docs/2004/1212/psp.htm
この写真を見ると
http://pc.watch.impress.co.jp/docs/2004/1212/psp21.jpg
十字キーのスイッチ基板はまさに垂直2分割のランドパターンになっています。
これだとボタンのラバースイッチを斜めにつぶすと、2つの接点はそれぞれ片方に
しか接しません。

まっすぐ押すと入るのに、斜めだと押されたことにならない原因はここにありそうです。

これだったら、4つの各ボタンが一体化せずに独立していたほうがまだ操作性が
良かったのではないかと思います。

原因がわかったので、斜めに押す場合はボタンを倒すイメージではなく、上から
2つのボタンを平行に押し込むイメージで操作すると比較的斜めに移動しやすく
なりました。
それでもまだ完全に自由自在な操作性を手に入れたわけではないのですが。

色違いの新型では渦巻状や、○ボタンのように十字分割のランドパターンに改良
されていたりしないのでしょうか。

http://pc.watch.impress.co.jp/docs/2004/1212/psp34.jpg
これを見るとサブ基盤になっているので、交換用パーツとか出るとうれしいです。

もしかしたら十字キーの各ボタンの下に、常に中心部でラバースイッチが押される
ように突起を設けると操作しやすくなるかも。いつかためします。

GeForce8800 注文と PS3 のモニタで悩む

やっと GeForce8800 を注文しました。(GTSだけど)
未だに旧世代の AGP で粘っていたので、Video カードだけでなく PC丸ごとの
発注となりました。最初は Vista 発売まで待つつもりだったんだけど、
品薄らしくてすぐに入手できるとは限らないので、思い切って買いました。

ちなみに今のPCについてるカードは GeForce6800GT (256MB,AGP) です。
たしか GeForce6800Ultra と GT がほぼ同時期の発売で、ShaderModel3.0 の
デビューと同時入手です。

Playstation3 も欲しかったのですが、よくよく考えたら家には PS3 がつながる
モニタが全くありません。普通の TV すらなくて、つながりそうなのは PC 用の
液晶モニタ VGA(DVI-A), DVI-D だけです。
(TV は携帯の V905SH だけで何とかなってます、、)

Xbox360 のように VGA ケーブルがあればいいんだけど PS3 には無さそうです。

Playstation3 がつながるモニタをまとめると次のようになります

○SDアナログ接続
・ビデオ端子(黄色いコネクタ) のTV
・S端子 のTV
・D2端子 のTV

○HDアナログ接続
・D3~D5 対応 TV
・コンポーネントケーブル 対応TV

○デジタル接続
・HDMI 端子付きの TV で表示
・HDMI 端子付きの液晶モニタで表示
・HDMI から DVI-D 変換して HDCP 対応の DVI 端子付きモニタで表示

参考ページ
・はじめてのPS3 Q&A

D端子/コンポーネント を VGA (DVI-A) に繋ぐには「トランスコーダ」という
色差→RGB 変換機が必要だそうです。

この場合入力信号の色フォーマットだけ置き換えるので、同期信号の周波数や解像度
などは変わりません。そのため RGB に変換しても入力信号にモニタが対応して
いなければ表示できないようです。

解像度まで自由に変換できるものはスキャンコンバータに分類されます。スキャン
コンバータはバッファリングが必要なので、ものによっては遅延が発生する可能性
があります。

もし PS3 が入手できたら、SD (ビデオ/S) 接続の場合はとりあえず安価な
スキャンコンバータか PC用キャプチャカードを使い、HD ならトランスコーダを
試してみようと思っています。

このあたりの情報は下記のページを参考にさせていただきました。

・Transcoders Info in 2ch
http://trasco.s53.xrea.com/

・液晶モニタ de 次世代ゲーム機
http://wiki.livedoor.jp/lcd_de_game/d/FrontPage

シェーダーとスレッド化

GeForce8800 になって Shader Unit のマルチスレッドがどうこうといわれるように
なったわけですが、スレッド化そのものは ATI(AMD)系だろうとかなり前から
使われているテクニックです。

この辺の話は後藤さんの記事でかなり突っ込んで紹介されています。
http://pc.watch.impress.co.jp/docs/2006/1121/kaigai320.htm

この記事で書かれている3つのスレッディングのうち「カスケード」と呼ばれている
ものは割と初期の段階から用いられています。後藤さんの説明では「メモリアクセス」
のレイテンシを隠蔽するためとなっていますが、これはもともとシェーダーの
パイプラインを埋めるのが目的です。

例えばシェーダー命令で直前の命令と依存関係が発生する場合、アウトオブオーダー
実行でない限りパイプラインの終了を待つためにストールが発生します。

dp3 r0.x, r2, c5
rsq r1.x, r0.x

この例では dp3 の d0.x の演算が完了するまで rsq は実行できません。命令上は
順番並んでいても、パイプライン化が行われているためすべての命令実行は半分以上
がオーバーラップしているからです。

仮にパイプラインステージ数が5段と仮定するとイメージ的には次のようになります。

・依存関係がない場合
dp3 F D E E W _
rsq _ F D E E W

・依存関係がある場合
dp3 F D E E W _
rsq _ F D _ _ E E W

前の命令完了を待つため数サイクル分のストール(パイプラインの空き)が生じます。
そのため動作速度を上げるには、命令を並べ替えて依存関係が発生しないように
プログラムを改良する必要があります。
(なお、この例ではレジスタの読み書きに関するストールなので、実際はバイパス化
でもうちょっと効率が上がるかもしれません)

シェーダーでは依存関係がない複数の演算が同時に大量発生するので、複数のコン
テキストを用いたスレッド化(カスケード化)でパイプラインを埋めることができます。

例えば 3スレッド(カスケード)で頂点演算する場合 V0~V2 の3頂点を同時に処理
します。

V0:dp3 F D E E W _ … (1)
V1:dp3 _ F D E E W _
V2:dp3 _ _ F D E E W _
V0:rsq _ _ _ F D E E W _ … (2)
V1:rsq _ _ _ _ F D E E W _
V2:rsq _ _ _ _ _ F D E E W _

V0,V1,V2 は依存関係が無いことがわかっているためストールは発生しません。

また V0 同士の場合でも、(1) の V0:dp3 演算のあと、(2) の V0:rsq 実行時には
すでに dp3 の演算が完了しているので、命令の並び上直接依存関係があっても見か
け上レイテンシ無しに実行することができます。
この場合特に最適化コンパイラや人間が並び替えで最適化する必要も無く効率が良い
ことがわかります。

レイテンシを考えながら書かなければならない他のハードと比べて、シェーダーの
プログラミングが便利で簡単なのはこのおかげだと思っています。

その代わり1つの実行パイプでもスレッド数分のコンテキストを保持しなければな
らず、またパイプラインが深くなればなるほどレイテンシを隠すためのスレッドが
余計に必要になることがわかります。

ShaderModel2.0 世代の GPU では、このリソース量の上限が実際の演算速度上の制限
になっていたようです。リソースが枯渇すると各スレッドの実行に必要なコンテキス
トの割り当てができず、実行できるスレッド数が減ってしまいます。

演算ユニットやパイプラインに余裕があっても、スレッドを発行できずに動作速度が
頭打ちになってしまうわけです。

昔の GPU で性能を謳う部分に「ハードウエアスレッド○○個」と書かれていたこ
とがありますが、このようにスレッド化はインオーダー実行時のレイテンシを隠す
ための機能なので、その分並列演算能力が増加するわけではありません。

スレッドが無くてもぎりぎりまで最適化したストールが発生しないコードは、
理論上は動作効率が変わらないことになります。
その分人間やコンパイラが苦労わけですが。

Cell の SPU(SPE) 命令を見て

暇なときに SPU(SPE) の命令を眺めたりしてましたが、普通の CPU ぽい命令が
かなりあって意外でした。というかレジスタが128bitでどの命令もSIMDになってる
だけでそれ以外は普通な感じです。
http://cell.scei.co.jp/

○演算は基本的に4種類
・8要素 16bit short int
・4要素 32bit int
・4要素 32bit float
・2要素 64bit double float

Intel でいえば全部 SSE で書いてるようなもの。x64 以降は fpu ではなく浮動
少数演算には常に SSE を使うらしいので割と近いのかもしれません。そういえば
VisualC++ も 2005 版になってデフォルトで SSE を使うようになってますね。

もちろん SPE は 3オペランドなので、その点は SSE 系より使いやすそうです。
レジスタも多いし。

もうひとつ意外だったのが、浮動少数演算系の命令が少なくて本当に必要最小限
であること。GPU の Shader のような至れり尽くせりのベクトル演算を期待すると
少々肩透かしを食らいます。(Shader の高度な演算も内部では複数の演算に分解
されている可能性はあります)

初期の SSE のように水平加算系の命令はなく、内積演算等でも同じようにベクトルの
並べ替えが発生するようです。4ベクトル同時演算の SIMD を活かすにはやっぱり
AoS SoA 変換も必要らしい。

GeForce8800(G80) がスカラー単位の演算ユニットに分離したのとは方向性が異なり
ます。そういえば G80 では内積などの水平系命令は演算ユニットをまたぐわけですが
どのような実装になってるんでしょう。