Archives

08 November 2006 の記事

http://ch09144.kitaguni.tv/e310975.html の続き
GPU でもプログラミング言語が走るようになって怒涛の勢いで進化しています。
ですが、PC でいう x86 や組み込み機器でいう ARM やゲームコンソールでいう
PowerPC のようにバイナリレベルで何らかの共通化が行われているわけではありません。
(もちろん ARM や PowerPC は結果そうなっただけなのですが)

nVIDIA の GPU や ATI(AMD) の GPU では、ほぼ同じシェーダーの機能を使うことが
できるものの、内部のバイトコードは全く別物だと考えられます。

HLSL で書かれたシェーダープログラムは、vsa, psa, fxc や D3DX によって
Direct3D の仕様として決められた仮想 GPU のバイトコードに変換されます。

このバイトコードは D3D のアセンブラ命令とそのまま対応しており、D3D の仕様
そのものでもありました。

ビデオカードのドライバは、D3D のバイトコードを受け取ってから実行前にそれぞれ
のネイティブのバイトコードへ変換が行われます。

もしかしたらほとんど D3D の仕様とそのまま同一なのかもしれませんし、メーカー
ごとにもっと大胆な最適化が行われていて非常に異なったコードに変換されている
のかもしれません。

ですが HLSL のコンパイラは D3D の命令への変換だけ考えればよく、最適化もこの
共通コードに対して行われます。


この仕様のおかげでドライバは独自の最適化を行うことができて、かつ命令セット
アーキテクチャ ISA にとらわれずに機能の向上が図れるのだと考えられます。


そう考えると .NET Framework に搭載されている CLR はいわば、CPU のための
デバイスドライバなのかもしれません。

CLI という統一された仕様の MSIL のバイトコード上ですべての処理を考えておけ
ばよく、実際にプログラムが走るときはデバイスドライバが勝手にネイティブのコード
に最適化を行います。CPU 毎の差を吸収できるので、GPU のように ISA レベルの
互換性にとらわれずに性能の強化を図れる・・のかもしれません。


ZERO3[es]のバッテリーメーターの減りが早くなってきたのでリフレッシュして
みました。いったんバッテリーを完全に空にしてからフル充電して、これを2回
くらいやっとけば元に戻るはずです。


バッテリーを空にするために試したのがネットのストリームラジオの連続再生です。
iPAQ のときは CF アダプタに LAN ケーブルつないで、よくデスクサイドの
プレイヤーとして使ってました。

[es] の場合は PHS 接続なので、最初は 24Kbps あたりからおそるおそる実験
開始です。使ったソフトはGSPlayer、回線はデータ定額 (4x 最大128Kbps)。

24Kbps は結構余裕で、48Kbps も OK。予想以上に結構いい感じです。

64Kbps も窓際など回線状態が安定している場所でじっとしていれば大丈夫でした。
64Kbps は MP3 のモノラルなので、音質的にはステレオだと 128Kbps 相当だから
もう十分です。

96Kbps のステレオもサーバーや回線状態によってはたまに途切れたりするものの、
条件さえ安定していればなんとかいけそうな感触です。


ブラウザ使ってるとあんまり速い印象は無いのですが、レイテンシを無視できる
ストリーム再生だとそれなりにスループットが出てるみたいです。少々意外でした。

年末には W-OAM 対応の W-SIM が出るそうなので、これだと速度は 204Kbps まで
出ます。非常に楽しみになってきました。

これ
http://www.willcom-inc.com/ja/lineup/rx/420al/index.html