いつものように Folding@Home のアイコンを選んでそのままおいといたら
v1.2 への更新確認画面で止まったままでした。
たぶん 1WU くらい余裕で処理できる時間です。大失敗。

二度目の更新 v1.2 で Folding@Home もさらに改良されました。
・Folding@home for PLAYSTATIONR3バージョン 1.2

特にリモートプレイへの対応は、以前 こちらの記事 で「強く希望」と
書いておきつつ、後から「やっぱり無理だよなと」思っていたので驚き。
早速試してみました。

リモートプレイを使うと、PSP でシミュレーション進行状況をモニタ
できるようになります。

家庭内でリモートプレイを使って PSP をサブモニタにしてもいいんで
しょうが、この機能が本領を発揮するのはおそらくインターネット
経由でのモニタリングでしょう。

出先でも進行状態を確認したり、シミュレーションを止めたり、
レスポンス速度を必要としないので相性がいいかもしれません。

リモートプレイの接続方法はいくつかあります。

・インターネット経由で接続する
・家庭内で接続する
　　・PS3直接接続
　　・無線ルータ経由

今回は「家庭内で接続する」だけ実験しています。

リモートプレイでどれくらいシミュレーション速度が遅くなるか見てみます。
本体だけで描画時 0.0728sec/frame くらいのデータが、
リモートプレイで 0.0796/frame ほどです。
この数値は起動直後の値なのであまり厳密ではないですが、
リモートプレイの方が必ず数値が大きく(遅く)なるようです。

ただし、1.2 で追加されたスクリーンセーバー解除直後は
リモートプレイ時でも 0.0732 くらいとそこそこ速い速度でした。
スクリーンセーバーのロゴ画面自体も通信で PSP に送られていますが、
圧縮負荷が低くあまり負担をかけないのかもしれません。
ちなみに本体だけだと、スクリーンセーバー解除直後はさらに速いです。
(0.0708 くらい)

リモートプレイで Folding@Home を起動し、そのまま PSP を切断しても
Folding@Home は動き続けています。PS3 側はリモートプレイ待機画面の
ままとなっており、PSP で再接続するとすぐシミュレーション画面を
見ることができます。

この待機状態でも画面の生成は行われているようで、シミュレーション
速度はリモートプレイ通信中と変わりませんでした。

リモートプレイ時でも、スクリーンセーバーが起動していれば
そこそこの速度になりそうです。
速度優先なら本体だけ＋スクリーンセーバー時がやっぱり速いですね。
テストはすべてノーマルモードで行っています。

WindowsMobile のキーカスタマイズソフト em1key が
遠藤諭の東京カレー日記で紹介されました。

・Advanced W-ZERO3 [es]で親指シフト

Advanced W-ZERO3[es] で親指シフト入力するために
oyayubiwm を使ってます。
しかもかなりカスタマイズされている!

DirectX10 対応 GPU は表面上機能的な差が無いので、ハードの違いを
意識することがあまりなくなりました。

ATI(AMD) の RADEON HD2900XT を最初に使った印象がまさにそうで、
対応機能をチェックしたり、それぞれ個別に専用のシェーダーを用意
したりする必要も無さそうです。

これまで GeForce8800GTS/GTX 周りの Shader 実行速度を調べて
きました。やっぱり RADEON の結果も気になるでしょう。

実は RADEON のデータも取ってあります。
でも実時間よりもどうも遅い数値が出てるようで、いまいち信頼に
欠けるのです。

テストでプログラムは Query の TIMESTAMP を使っているのですが、
2倍の値が返ってきているように見えます。または Frequency が
半分なのかもしれません。プログラムの問題だとは思うのですが
まだ原因がよくわかっていません。
Catalyst 7.8 に上げても同じでした。

もう1点、使っているテスト PC の電源が足りないようです。
RADEON HD2900XT は本来、PCI-E 用の 8pin + 6pin の電源を使います。
マニュアルには一応 6pin + 6pin でも動作すると書かれていたので、
GeForce8800GTS/GTX と同じように 6pin + 6pin で動かしていました。

ただこれだと HD2900XT 本来の性能を発揮できず、動作クロックが
抑えられてしまうようです。

・測定された実行時間はおそらく 2倍の値(半分で実時間)になっている。
・電源が足りずに動作クロックが抑えられた状態になっている。

よって上記2点の理由により、測定値は絶対的な指標として他の
GPU との比較ができず、相対的に遅くなる条件や傾向の判断用の
データとなる点ご了承ください。

まずは先日の GTX と同じ、[loop] の方が高速になる unroll/loop
展開テストです。temporary register 数の増加がどれくらい実行
速度に影響を与えているか、その判断にもなるかと思います。
使用したドライバは Catalyst 7.8 です。

  loop回数 [unroll] [loop] temp reg
      40     1225    1014      5
      60     2550    1400      7
      80     3340    1780     12
     100     8100    2160     15
     120     9600    2550     17
     140    11000    2950     18
     160    12500    3340     18
     180    13960    3710     18
     200    15436    4092     18

・縦 時間 (縦軸は半分の値と思ってください)
・横 ループ回数

テンポラリレジスタが増えると遅くなる傾向は GeForce8800 と
同じです。80(12)～100回(15) に大きな隔たりができています。
このあたりでおそらくレジスタ数と動作スレッド数のバランスが
崩壊しています。18固定後の負荷上昇率が意外に小さいので、
ループ処理自体の動作効率は良いようです。

100回以上は一定の上昇率なので、このケースではテンポラリ
レジスタ数 15以上はほぼ同じ負荷となっているようです。
ネイティブコード変換でぜんぜん違うプログラムに置き換わっている
のかもしれません。

テンポラリレジスタ数増加に対する耐性が弱く、比較的低い位置
で負荷が上昇するものの、シェーダー自体の実行効率は良いので
ループ回数が極端に増えれば良い結果がでそうです。
本来比較できない今のデータのままでも、場合によっては
GeForce の結果を追い越すかもしれません。
本来高速な条件では速度が伸びないけど、遅い条件でも割と耐える
感じです。

次に出力レジスタ(ラスタライザの補間パラメータ数)数と動作速度の
関係は下記のとおりです。内部の最適化 (VLIW化?) の影響なのか、
別のところに要因があるせいなのかわかりません。

・縦 時間 (縦軸は半分の値と思ってください)
・横 出力レジスタ数

9～10まで一気に上昇するものの11でなぜか下がります。
11～15の数値はかなり速くなっており、出力レジスタ数の影響が
もともと無いのか、それとも意味が無いと思って最適化されたのか
もしれません。

Catalyst 7.8 にしたら今まで動いていたプログラムで動かなく
なったものがあるので 7.7 に戻しました。
安定したデータが取れるのはもうちょっと先になるかもしれません。
まずは電源を・・

W-ZERO3/EM・ONE 用ソフト、ctrlswapmini や em1key の
　・既知の不具合
　・報告をいただいた不具合情報
　・現在寄せられている要望
等を登録した BTS を公開しました。現在試験運用です。
閲覧だけなら「ゲストログイン」ボタンで入ることができます。

・BTS flatlib-mantis

Shader.jp さんからの情報ですが
・ゲーム開発者のための技術説明会 「Gamefest Japan 2007」 開催

CEDEC から Meltdown が消えたなと思っていたら、独自に
Gamefest Japan を行うみたいですね。
二日間にわたって開催されて結構内容も幅広いようです。
9月は忙しくなりそうです。

・ゲーム開発のための技術説明会 Gamefest Japan 2007 開催　ゲーム制作技術情報を日本で初めて広く一般へ公開
こちらにも書いてあるように Gamefest はもともと開発者限定の
クローズドなイベントだったので、それが広く一般に公開された形です。
ターゲットはやはり開発者で、マルチプラットフォーム化等の推進が
狙いとのことです。

そういえばゲームは、Wii/DS 等ユーザー層の拡大がここ最近のテーマでした。
もしかしたら MS は XNA 関連を中心にして、ユーザーだけでなく
開発の一般への浸透化や、開発者の層の拡大もある程度視野に入れて
いるのかもしれません。