月別アーカイブ: 2007年7月

EM・ONE 3DBoxゲームにさらに追加

3D Box のゲームコンテンツに、さらに 8本のソフトが追加されています。
「どこでも英会話」 2の1 ~ 2の8 です。

(前回 EM・ONE 3D Box のゲーム)
これで合計全部で18本。かなりボリュームがあります。
ダウンロードとインストールだけでも結構な量。

アイコンの数がすごいことになりました。

どこでも英会話の赤いアイコンだけで 16個もあります。

EMOBILE EM・ONE スーパー大容量バッテリー

EMONE 用に大容量バッテリーを購入してみました。
Mugen Power 3400mAh バッテリ EM・ONE
容量は標準バッテリーの 2.8倍だそうです。
本体からはみ出す大きさで、バッテリーカバーごと交換します。
まずは気になる重さを調べてみました。すべて実測値です。

  ●3400mAh MP超大容量バッテリー
  ・81g MPバッテリー単体
  ・12g MP交換用バッテリーカバー
  ——————
  合計 93g

  ●1200mAh 標準バッテリー(本体付属)
  ・29g 標準バッテリー
  ・5g  標準のバッテリーカバー
  ——————
  合計 33g

よって、バッテリー交換で 60g 増える計算になります。
実測でもちょうど 60g の増加になりました。

  ●本体の重さ実測 (miniSDカード、標準スタイラス込み)
  ・242g 標準バッテリー時
  ・302g 3400mAh MP超大容量バッテリー取り付け時

次に取り付けによってどれくらい本体が大きくなるか
厚みを調べてみました。

  ●3400mAh MP超大容量バッテリーの厚み
  ・12mm 3400mAh MP超大容量バッテリー本体の厚み
  ・8mm 取り付け時の増加分の厚み

  ●1200mAh 標準バッテリーの厚み
  ・4mm 標準バッテリーの厚み

バッテリー単体では 3倍の厚さがあります。
ケースの増分は 8mm で、まとめると次のようになりました。

 19mm、242g 標準バッテリー
  ↓
 27mm、302g 3400mAh MP超大容量バッテリー

6G HDD 内蔵の Zaurus SL-C3200 の重さがカタログ値で

  SL-C3200 厚さ 25mm、298g

なので、これを超えています。
iPAQ h3630 + PCカードジャケットに比べたら小さいもんです。

  h3630 + PCカードジャケット 厚さ 3cm、327g

Direct3D10 shaderとリソースとsampler

シェーダーはテクスチャを読み込むことができます。
1pixel の描画のために 5枚以上のテクスチャを読み込んだり、
16~64回もサンプリングしたり、といった使い方も珍しくなくなりました。
読み込むテクスチャの指定の仕方もシェーダーの進化とともに変化してきました。

Direct3D9 や D3D8 の ShaderModel1.0 は TextureStage が中心です。
これは DirectX6~7 から引き継いだ考え方で、各ステージに対して
Texture と Sampler (RenderState) を設定します。
そのため Texture Slot 番号、Sampler 番号、Texture Stage の各番号は
一致します。

同じテクスチャを何度も回読みたければ、複数の Stage にテクスチャを
設定する必要がありました。また使用できるステージ数も GeForce3/4 では
最大4ステージまででした。(RADEON 8500系は 6)

ShaderModel2.0 になると TextureStage が分離されます。
これによって演算のためにステージを消費し、読み込めるテクスチャ数が
減ることもなくなりました。
また同一テクスチャを何度も texld できるので、登録個数上限が 8個だと
してもテクスチャ読み込みの回数には上限がなくなりました。
(命令スロットの制限はあります)

Direct3D10 ではさらに分離が進んで、Texture と Sampler が完全に独立
しました。
Shader 内で任意の Sampler と ShaderResource を組み合わせることが
可能なのはもちろん、Sampler を使わずに ShaderResource から直接値を
読み込むことまでできます。

API 上一度に登録可能な Sampler の State 数も 16 slot、ShaderResource
(Texture や Buffer) も 128 slot と増加しています。

さらに Shader は統合されています。VertexShader、GeometryShader、
PixelShader どのシェーダーでも同じように Texture の読み込みが可能
なので、API もそれぞれ 3セットあります。
一度の Draw で設定可能な ShaderResource は 128×3 にもなります。

VSSetSamplers()
VSSetShaderReousrces()
GSSetSamplers()
GSSetShaderReousrces()
PSSetSamplers()
PSSetShaderReousrces()

これらの API は ID3D10Effect を使っている分には全く意識することがなく、
内部で面倒なこともやってくれるので非常に簡単です。

自前で Shader 管理を行うならば、同じ Sampler や ShaderResource で
あっても VS, GS, PS それぞれことなる slot で参照している可能性があるので
別々の設定を行わなければなりません。
D3D9 まででも Constant Register のマッピングは VS と PS で個別管理なので
一緒なのですが、、Effect が便利で頼りすぎていたのかもしれません。

といっても、今のところ PixleShader 以外では、Sampler を使ってイメージ
Texture を大量に読み込むような用途はそう頻繁には無いのかもしれません。

D3D10/DX10 シェーダーと64bit浮動少数

GPU も G9x (GeForce8xの次世代) では float64 にも対応するのでは
ないか、との話です。
GPUサーバーの時代を開くNVIDIAの「Tesla」
もともと ShaderModel1.0 の PixelShader は 9~12bit 整数演算で、
D3D10 の表記でいえば SNORM に相当します。固定少数値
-1.0~+1.0 にMapされていたわけです。
VertexShader は 32bit float でした。

ShaderModel2.0 になって ATI(AMD) RADEON は 9700 シリーズで 24bit float を
導入し、これが X800 系まで続きます。
ShaderModel2.0 で出遅れた nVIDIA の方は GeForceFX で 32bit float を
先行実現しましたが、実際は 16bit half float とのハイブリッドで、
half を積極的に使わないとパフォーマンスに影響が生じるものでした。

ShaderModel3.0 になると GeForce6800~ も RADEON X1800~ も、頂点
同様の 32bit 浮動少数精度を実現します。

ここまで来てようやく PixelShader の演算精度が VertexShader に肩を
並べることができたわけで、D3D10 ShaderModel4.0 世代のユニファイド
シェーダーへ向けて準備が整ったといえます。

ちなみに ATI(AMD) は X1800 より前にも、Xbox360 向け GPU にて
先行して 32bit 浮動少数精度の PixelShader、ユニファイドシェーダー、
ストリームアウトプットなどの機能を実現していました。

さて ShaderModel4.0 で IEEE754 単精度に対応したら次は倍精度 64bit
というわけです。この流れは実は DirectX SDK の D3D10 のマニュアルを
じっくり見ているとわかります。

なにせ HLSL のリファレンスを開くと、一番最初が変数型の説明で、
その最初のページに dobule 型がしっかりと記載されています。
はじめて ShaderModel4.0 のマニュアルを読み進めていたときに、
もう倍精度も対応しているのかと驚きました。
でも試したら使えませんでした。

ID3D10EffectType や ID3D10ShaderReflectionType 等が使っている
D3D10_SHADER_VARIABLE_TYPE を見ても、32bit INT と 32bit FLOAT
しかありません。本当に 64bit float に対応するなら D3D の core
を含めてまた大幅な更新が必要となりそうです。

ちなみに cbuffer 等で double 宣言を使ったどうなるか。
実はコンパイルはきちんと通ります。でも Reflection を取ってみると
ただの 32bit の float になっていました。
ShaderModel4.0 においては half も float 扱いとなるようです。

D3D10/DX10 D3D10_FILTER その2

D3D9 までの TextureFilter は、MinFilter, MagFilter, MipFilter の
組み合わせでした。それぞれ設定可能な値は3タイプで次のようになります。
MIN : POINT, LINEAR, ANISOTROPIC
MAG : POINT, LINEAR, ANISOTROPIC
MIP : NONE, POINT, LINEAR
D3D10_FILTER では MIN, MAG, MIP の各組み合わせが個別のシンボル
(例の長いやつ)に定義されています。
だけどその定数値を良く見ると一定の法則がわかります。
D3D10_FILTER

bit0 = MIP LINEAR
bit2 = MAG LINEAR
bit4 = MIN LINEAR
bit6 = ANISOTROPIC (MIP,MAG,MIN全部 Linear のみ)
bit7 = COMPARISON
bit31 = TEXT 1BIT

実際 ANISOTROPIC 時に point sampling を組み合わせることはないので、
必要な組み合わせだけをシンボルに指定して定義したもののようです。
また MIP NONE がありません。
テクスチャが LOD を持っているかどうか、これだけで MIP の利用を決定しても
実用上特に不便しないし、実際 MIP が付いているのに切ることは稀だし、
必要なら Shader の Sample 時に Level を決め打ちできるし、
と State 側にはいらないのかもしれません。

今気が付いたけど SDK マニュアルの SampleLevel の説明が間違っているようです。
SampleLevel
中身が SampleCmpLevelZero のものになっていますね。
正しくは MipLevel の指定です。