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

PowerVR SGX を採用した Intel US15W の GMA500 は、こちらで調べたように
正直あまり速くないという印象です。
その考えられる要因は次の通り

・シェーダーユニット (USSE) の数が少ない (2個)
・1 ALU あたり 32bit float x1 演算
・公称のピーク性能を達成できるのは 1 ALU で 8bit x 4(ARGB) のレガシーなカラーを扱った場合のみ
・フィルレートは 3D 時の内部 Z オクルージョンカリングを含めたもので実際のバスは細い

シェーダーユニット USSE あたり 1ALU との明確な記述はありませんが、その参考に
なりそうなのが頂点性能です。Transform Only でも頂点あたりに必要な clock 数が
かなり多いことから、1clock あたりの演算能力がかなり低いことがわかります。
(詳細は 前回)

転送能力は 2pix x 200MHz = 400Mpix/sec
Z/stencil 不要なので 64bit x 200MHz = 1.6GB/sec

ちなみに USSE は汎用的な Unified Shader なので、Video/Image 処理にも使われる
(または利用できる) と書かれています。
他に Video Decode Unit が搭載されているので本当に使われているのかどうかは
わかりません。GMA950 系よりは汎用的なのは確かなので、描画以外でも恩恵を
受けられるメリットはあるかもしれません。
もしくは PowerVR がライセンスしている Video Decode 機能自体も USSE の
Video/Image processing に依存している可能性があります。

追記: シェーダーユニットが 2個というのは UnifiedShader 世代のスカラー換算なので、
　ShaderModel 3.0 世代でいえば 0.5 個分ということです。3.0 世代 GPU は複数の
　ALU を搭載していたものが多かったのでそれを考慮すればもっと少ない。


●Windows Aero / Aero Glass と相性が悪い

Windows の Aero / Aero Glass においては ShaderModel 2.0 (PiselShader 2.0) を
利用して Window 描画を行います。そのため、特に PixelShader2.0 以上を使うと
pixel 性能が極端に下がることが致命的だと考えられます。

GMA500 が Windows Aero / Aero Glass と相性が悪い原因

　(1) PixelShader 2.0 以降では Pixel 処理能力が 1/4 以下となる
　　　8bit x4 SIMD mode が使えない、1ALU で済んでいたカラー演算が 32bit float
　　　演算となるため 4ALU 必要となる。

　(2) 半透明の重ね合わせは PowerVR 独自の On Chip Z Occlusion をスポイルする。
　　　おそらく Aero / Aero Glass など Window GUI に必要なのは、
　　　賢く速度を稼ぐ描画ではなく力業の転送能力なのだと考えられます。

根本的な原因はおそらく (1) の方で、(1) の方が処理負担に対する割合が高いと
考えられます。(2) の方が大きな原因であれば、Aero Glass → Aero 不透明に
切り替えることで改善できるはずです。


●PowerVR SGX の性能がわかりそうな資料(1)

前回調べておきながら、取り上げるのを忘れていた資料に OMAP があります。
OMAP は SGX を搭載しています。

・TEXAS INSTRUMENTS OMAP3530

PowerVR SGX といっても様々なグレードがあるため一概に比較はできませんが、
資料を読むといろいろと興味深いデータが含まれています。

OMAP3530
＞ 10MPoly/sec

GMA500 は 13.3MPoly/sec なので若干遅い程度。

さらに上記ページから落とせる下記の資料が参考になります。
　・OMAP35x 2D/3D Graphics Accelerator Reference Guide-TRM Ch 13 (Rev. B) (spruff6b.pdf, 199 KB)

＞ 8 parallel depth/stencil test per clock

チップ内部の pixel 処理能力が 8pixel/clock であることを意味しています。
tile 単位のラスタライズ(以下 SGX の処理内容の予想)

(1) depth/stencil 8pixel/clock (OMAP3530の場合)
　　　すべての Primitive をラスタライズして depth/stencil だけ先に test
　　　Pixel Shader はせず Texture も読まない

(2) deferred pixel shading、(1) を通過した pxiel のみ描画する。
　　　Z が最前面の pixel だけ PixelShader の実行、Texture のフェッチを行う

(3) (2) の出力を最大 2pixel/clock (GMA500の場合) で出力する

(1) は PC の GPU でもよく使用する depth のみの前レンダリング似ています。
GPU の多くはカラー無しの depth/stencil のみの出力では 2倍ほどの pixel レートで
描画できるようになっています。


●PowerVR SGX の性能がわかりそうな資料(2)

ルネサスの SH-Navi3 のニュースリリース

SH7776 CPU 533MHz, 4.27GB/sec, PVR SGX ?MHz
　・RENESAS 業界初、車載情報端末向けに画像認識処理機能内蔵のデュアルコアSoC「SH7776」（SH-Navi3）を製品
　MBX から SGX でポリゴン性能が 2倍

SH7770 CPU 400MHz, PVR MBX 100MHz
　・カーナビに最適な2D/3Dグラフィックスエンジンを業界で初めて内蔵し、さらに、次世代カーナビに必要な機能を1チップにした「SH7770」を製品化

SH7774 CPU 600MHz, PVR MBX MBX 300MHz
　・カーナビ向けSoCで、世界で初めて画像認識処理機能を搭載した「SH7774」を製品化
　SH7770 の3倍


● Intel GMA500 と ShaderModel

実際に Atom Z500 + US15W の Intel GMA500 を搭載した PC を手に入れたので
軽く試しました。

　・ShaderModel3.0 まで

対応している ShaderModel は 3.0 まで。
アーキテクチャ的には Unified Shader で 4.1 (D3D10.1) まで出来そうに見えますが
(wikipedia Intel GMA にも 4.1 と書かれていますが)
ドライバが対応しているのは 3.0 まででした。
VertexShader も PixelShader もハードウエアです。

D3D10CreateDevice1() がエラーになるのは当然としても、少々問題なのは
D3D11CreateDevice() までエラーを返してくること。
本来なら D3D_FUEATURE_LEVEL_9_3 あたりを返してきて欲しいところです。

これが原因で GMA950 なら D3D11 API に移行できるのに、GMA500 では
ShaderModel3.0 でも D3D11 API に移行することが出来ません。
もちろん WARP なら可能です。


● Intel GMA500 と Aero Glass

WindowsVista では Aero / Aero Glass に切り替えられました。
やはり重いです。Aero Glass を切って Aero にすると多少軽くなります。
以下手順。

　◎ Aero Glass に切り替える ---- (A)
　　デスクトップのカスタマイズ→個人設定→ウィンドウの色とデザイン→
　　　　配色「Windows Aero」を選ぶ

　かなり処理落ちしているようで、ウィンドウ操作などがマウスカーソルについて
　こなかったりします。
　下記の設定で半透明を無効にすると、同じ Aero でも若干速くなります。


　◎ Aero の半透明を無効にする ---- (B)
　　デスクトップのカスタマイズ→個人設定→ウィンドウの色とデザイン→
　　　　ウィンドウの色とデザイン→透明感を有効にするのチェックを外す

　半透明を切るだけで結構軽くなりました。半透明というよりも、ぼかしフィルタ
　などのシェーダーコードの実行がボトルネックになっているのかもしれません。

先にパフォーマンスのチェックを全部外しておいてから Aero にすると、もう少しだけ
軽い設定の Aero になります。


　◎ 出来るだけ軽い Aero にする方法

　(1)スタートメニュー→コンピュータの右ボタンメニューでプロパティ
　　　　→システムの詳細設定→パフォーマンス→設定→チェックボックスを全部外す

　(2) ここで強制的に BASIC に戻される

　(3) (A) の設定で再び Aero Glass に切り替えてから、(B) の設定で半透明を無効にする。

見た目は Vista Basic と変わりませんが、上のウィンドウを動かしても重なった下の
ウィンドウに再描画が発生せず、ハードウエアによるアクセラレートが効いている
ことがわかります。

Windows の描画モード

XP
  Luna                    ハードウエア
  Classic                 ハードウエア

Vista
  Aero Glass (透明感 ON)  WDDM ハードウエア 3D描画
  Aero 不透明/Standard    WDDM ハードウエア 3D描画
  Vista Basic             CPU 描画
  Windows Classic         CPU 描画

Windows7
  Aero Glass (透明感 ON)  WDDM ハードウエア 3D描画
  Aero 不透明/Standard    WDDM ハードウエア 3D描画
  Basic                   ドライバが対応していればハードウエア

Windows7 では Aero を有効にすることが出来ませんでした。
ドライバにまだ問題があるのかもしれません。


参考資料
・IntelR Atom Processor for Mobile Internet Devices Technical Documents
　　・IntelR System Controller Hub (IntelR SCH) datasheet (PDF)
　　・IntelR System Controller Hub (IntelR SCH) specification update (PDF)

・Imagination Intel
　　・IntelR CE 3100 (PDF)


関連エントリ
・Intel GMA500 の機能と性能と Aero

ARM 一色といって良いほど ARM が幅をきかせているように、
3D プロセッサも PowerVR 一色になりそうな勢いでした。
そんな中 Qualcomm は ATI (AMD) を貫き通すようです。

・Qualcomm、AMDからハンドヘルド向け事業を買収
・AMD、ハンドヘルド・チップ事業をクアルコムに売却

ちょうど最近なにかと苦労してたのがこの GPU。
Direct3DMobile ではなく OpenGLES だったりとか、他のドライバや API でもっと
きちんと使えば、もっとパワーのある描画性能を見せてくれるのかもしれません。

PowerVR 系も SGX が増えてくるので、そろそろ Shader を搭載した次の世代の
GPU も期待したいところ。


関連エントリ
・HTC Touch Diamond で Direct3DMobile その(11) 問題まとめその他
・HTC Touch Diamond で Direct3DMobile その(10) d3dmclock v1.10 3Dクロック 更新
・HTC Touch Diamond で Direct3DMobile その(9) d3dmclock v1.00 3D クロック
・HTC Touch Diamond で Direct3DMobile その(8) ノーマルマップの解説
・HTC Touch Diamond で Direct3DMobile その(7) ノーマルマップを表示する
・HTC Touch Diamond で Direct3DMobile その(6) 頂点性能続き
・HTC Touch Diamond で Direct3DMobile その(5)
・HTC Touch Diamond で Direct3DMobile その(4) 高速化
・HTC Touch Diamond で Direct3DMobile その(3) 実際の頂点性能
・HTC Touch Diamond で Direct3DMobile を使う。その (2)
・HTC Touch Diamond で Direct3DMobile を使う。ハードウエアアクセラレータ

Windows7 beta の PC でリモートデスクトップを使ってみました。

接続時に、リモートデスクトップの オプション → エクスペリエンス から
パフォーマンスのオプション画面でとりあえず全部チェックを入れておきます。
これで普通に Aero Glass が出ています。


↑LOOX U50 (Win7βクライアント) から EeePC901(Win7β) に接続

リモートデスクトップを使うためには、あらかじめホスト側の設定が必要です。
　コントロールパネル → システム → リモートの設定 →
　　リモートデスクトップを実行しているコンピュータからの接続を許可するを選ぶ

Vista が相手だと Aero Glass になりません。

Aero Glass
○　Win7β Client → Win7β Server
×　Win7β Client → VistaSP1 Server
×　VistaSP1 Client → Win7β Server

どの PC もローカルで Aero Glass が動くだけのスペックがあります。
(LooxU50 は Atom ではなく A110 の古いタイプです)

Aero Glass が出るなら Direct3D はどうだろう、ということで試しました。
あっさり動きました。



↑LOOX U50 (Win7βクライアント) から EeePC901(Win7β) に接続

ところが Vista でも動きました。



↑LOOX U50 (Win7βクライアント) から Desktop PC (VistaSP1) に接続

Aero は出ていませんが D3D アプリは動いています。
自分が知らなかっただけで Vista ですでに対応していたのかもしれません。

動作するアプリケーションはサーバー(ホスト)側の GPU に依存しています。
下記の通り認識されているデバイスが異なります。

HAL(sw vp): RDPDD Chained DD　(チップセット内蔵 GMA950 EeePC901 Win7)
HARDWARE: RDPDD Chained DD　　(GeForce GTX260 Desktop Vista)

サーバーが EeePC の場合 GeometryShader を使った D3D10 アプリは動きませんが、
GTX260 の Vista では動きます。よってサーバー側の GPU でレンダリングした結果の
画像を RDP で転送しているのだと考えられます。
もともと Vista 同士でも D3D アプリが動作していたのかもしれません。


Windows7 ではさらに、Direct3D のコマンドレベルのリモート描画に対応しているようです。
以前 masafumi さんのところで紹介されていた DXGI 1.1 beta のドキュメントによると、
Windows7 の DXGI1.1 だと RDP7 によって Remote PC の Adapter を取得できるとのこと。

・DXGI 1.1のドキュメント

詳しいドキュメント(White Paper)がこちらにありました。

・Microsoft Developer White Papers: PDC08
　より一番下の 「Direct3D 10.1 Command Remoting 」

Command Remoting の違いは下記の通り

・Vista
　サーバーの GPU でレンダリングした結果を bitmap でクライアントに転送。

・Windows7 DXGI1.1 対応アプリ
　描画コマンドを送ってアプリではクライアント側でレンダリングできる
　ただし既存の(未対応) Direct3D10.1 アプリはビットマップ転送

よって最初に紹介したキャプチャなど、現在描画されている Direct3D の画面はただの Vista の機能でした。

Command Remoting を使うには対応したアプリケーションを作成し、Windows7 上で
走らせる必要があります。
Full Screen Mode が使えないなど若干制限があり、また実際は通信帯域を考慮した
描画コマンドの最適化が必要となるようです。

コマンドレベルの転送＋クライアントレンダリングによって帯域を減らせるので、
リモートで走らせているアプリケーションでも描画レスポンスが向上すると思われます。
また未対応だったり不要なものは従来通り bitmap 転送なので、サーバーとクライアントで
レンダリング処理を分散させるなど応用できるかもしれません。

残念ながら 10.1 なので D3D11 アプリは当分未対応だと思われます。
WARP といい、とりあえず Windows の描画に必要な 10.1 が 1つの目標になっているようです。

HTC Touch Diamond の Direct3D Mobile を使い Texture に直接レンダリングしようと
思ったらエラー。cpas を見たら対応していないことに気がつきました。
テクスチャに対して BackBuffer からのコピーは出来たので、必要ならフレーム
バッファをコピーしながら使うことになります。
ちょっと昔の GPU といった感じです。

IDirect3DMobileTexture* iTexture0;
CreateTexture( 512, 512, ..., &iTexture0 )
IDirect3DMobileSurface* iSurface0;
iTexture0->GetSurfaceLevel( 0, &iSurface0 );
～
RECT rect;
rect.left= 0;
rect.top= 0;
rect.right= 480;
rect.bottom= 480;
CopyRects( iBackBuffer, &rect, 1, iSurface0, NULL );

●現在までにわかっている問題点

HTC TouchDiamond (Qualcomm MSM7201A 内蔵 ati core 用 d3dm_ati.dll) で
Direct3DMobile を使用した場合に遭遇した各種症状です。
Emulator の Reference Driver では問題がないので、何らかのバグの可能性が高いと
思われます。

・640x480 window mode/full screen でレンダリングできない
　639x480 や 640x479 以下なら大丈夫

・HW T＆L の光源が World space ではなく Local space で適用されてしまう

・XYZ_RHW 形式の頂点でレンダリングすると RHW の値が座標値にも影響を与えてしまう
　rhw = 1 以外で screen 座標を正しく与えることが出来ない。

・XYZ_RHW 形式(Transform済み頂点)と、そうでない頂点の混在が出来ない。
　RHW 無し頂点が出なくなる。

・D3DMTSS_TEXCOORDINDEX が無視される。常に Stage に一致した頂点 uv を参照する。
　仕様かもしれません。

・D3DMFVF_TEXCOORDFIXED が指定できない。常に頂点 uv は FLOAT とみなされる。

・Texture の mipmap ありなしと D3DMTSS_MIPFILTER の設定を厳密に合わせないと
　テクスチャが真っ白になる。
　存在しない miplevel へのアクセスが all 255 になるのかと思ったけど違うようです。

・ZWRITEENABLE を FALSE にできない。症状未確認。

・TextureStage でテクスチャを使用していない描画とテクスチャを使用している描画が
　混在しているときに Texture が表示されないことがある。

　厳密な発生条件は未検証です。他にも複数の描画で、上書きしているはずの
　TextureStage の設定が相互に影響し合っていることがあります。
　d3dmclock でも、オプションによって Texture が不要なケースなのにテクスチャを
　読み込んで演算で無視するなどやってます。

その他危なそうなものは避けて使っているので他にもあるかもしれません。


関連エントリ
・HTC Touch Diamond で Direct3DMobile その(10) d3dmclock v1.10 3Dクロック 更新
・HTC Touch Diamond で Direct3DMobile その(9) d3dmclock v1.00 3D クロック
・HTC Touch Diamond で Direct3DMobile その(8) ノーマルマップの解説
・HTC Touch Diamond で Direct3DMobile その(7) ノーマルマップを表示する
・HTC Touch Diamond で Direct3DMobile その(6) 頂点性能続き
・HTC Touch Diamond で Direct3DMobile その(5)
・HTC Touch Diamond で Direct3DMobile その(4) 高速化
・HTC Touch Diamond で Direct3DMobile その(3) 実際の頂点性能
・HTC Touch Diamond で Direct3DMobile を使う。その (2)
・HTC Touch Diamond で Direct3DMobile を使う。ハードウエアアクセラレータ

設定等をもう少し説明してみます。(→前回)



ダウンロードはこちら
・bumptest v1.00

スマートフォン HTC Touch Diamond は Qualcomm MSM7201A 内蔵の
3D アクセラレータを搭載しており ATI の GPU core となっています。

Direct3DMobile は PC でいう DirectX8 のサブセットですが、機能自体は
DirectX7 世代相当で固定パイプラインのみ。シェーダーは使えません。

caps を調べるとハードウエアアクセラレータとして認識していることがわかります。

D3DMDEVCAPS_HWTRANSFORMANDLIGHT
D3DMDEVCAPS_HWRASTERIZATION
D3DMDEVCAPS_NATIVEFLOAT

また使用できるマルチテクスチャは 2枚で TextureStage 数も 2段です。
無理矢理シェーダーにたとえれば ShaderModel 1.0 でピクセル単位に

・テクスチャ命令 x2
・演算命令 x2

を実行できるということ。DirectX7 世代のレジスタコンバイナそのままです。
TextureStage で使用できる演算として D3DMTEXOPCAPS_DOTPRODUCT3 が有効に
なっていたのでこれを使用します。


TextureStage には外部から与えられる定数がありません。
試しに D3DMRS_DIFFUSEMATERIALSOURCE を使って頂点カラーの代わりに Material
からパラメータを取れないか試しましたがだめでした。
これはライティングユニットへの入力時にのみ機能するようです。

外部から定数を渡すことが出来ればすぐにでもオブジェクトスペースの
ノーマルマップでテストできるのですがあきらめます。
パラメータは頂点カラーとして渡すことにします。
どうせ頂点を経由するなら最初からタンジェントスペースにします。

頂点の光源計算はもともと CPU で行っていました。
このときオブジェクトスペースに変換した光源ベクトルを使いますが、ここで
DotProduct せずにベクトルをそのままカラー値として出力します。

まずは D3DMTEXOPCAPS_DOTPRODUCT3 のベクトルフォーマットを確認します。
いくつかのカラー値を通してみてどのような復号が行われているか推測。
マニュアルには符号付きとだけ書かれており明確ではありませんでしたが、
やはりシェーダー同様 _bx2 相当 ( (x-0.5)*2 ) でした。


モデルデータの頂点にはオブジェクトスペースからタンジェントスペースへの変換
マトリクスを埋め込んでおきます。
1軸は法線と共有するため +2 vect。CrossProduct するなら +1 のみ。
データの生成と export は昔 3ds Max 用に作った自作プラグインを使用しています。

WorldSpace (GlobalSpace)
　　　→ ObjectSpace (LocalSpace)
　　　　　　　→ TangentSpace (TextureSpace)

元の光源ベクトルは WorldSpace に配置されているため、頂点法線も WorldMatrix
(3x3) で変換してから演算する必要があります。
一般的に光源の数より頂点の方が多いので、CPU 演算の手抜きライトの場合は光源の方を
WorldMatrix(3x3) の逆行列で ObjectSpace に変換した方が演算量が減ります。
同じようにノーマルマップからサンプリングした法線を適用するため、
光源ベクトルを TangentSpace まで逆変換します。

頂点単位のライティングの代わりに、オブジェクトスペースへ変換した光源ベクトルを
タンジェントスペースへ変換する演算を追加します。変換 matrix (3x3)をかけるだけ。
結果を 0～1.0 に収まるよう _bx2 の逆変換で格納します。
固定小数演算なのでビットシフト等で最適化します。

vect3 tslightdir;
TangentMatrix.Transformation( tslightdir, oslightdir );
colorr= ((tslightdir.x+ FIXED16(1.0f))* 255)>>17;
colorg= ((tslightdir.y+ FIXED16(1.0f))* 255)>>17;
colorb= ((tslightdir.z+ FIXED16(1.0f))* 255)>>17;

シェーダーがあれば VertexShader でやっているところです。
またノーマルマップ生成ツールによって座標系が異なってることがあるので
軸の符号などは合わせます。

テクスチャステージでは読み込んだノーマルマップの値と頂点から出力した上記の
光源ベクトルを DotProduct します。

一段目はノーマルマップで光源演算。

SetTexture( 0, iTexture0 );
SetTextureStageState( 0, D3DMTSS_COLORARG1, D3DMTA_TEXTURE );
SetTextureStageState( 0, D3DMTSS_COLORARG2, D3DMTA_DIFFUSE );
SetTextureStageState( 0, D3DMTSS_RESULTARG, D3DMTA_CURRENT );
SetTextureStageState( 0, D3DMTSS_COLOROP, D3DMTOP_DOTPRODUCT3 );
SetTextureStageState( 0, D3DMTSS_ALPHAOP, D3DMTOP_DISABLE );
SetTextureStageState( 0, D3DMTSS_TEXCOORDINDEX, 0|D3DMTSS_TCI_PASSTHRU );

二段目はカラーマップの合成。

SetTexture( 1, iTexture1 );
SetTextureStageState( 1, D3DMTSS_COLORARG1, D3DMTA_TEXTURE );
SetTextureStageState( 1, D3DMTSS_COLORARG2, D3DMTA_CURRENT );
SetTextureStageState( 1, D3DMTSS_RESULTARG, D3DMTA_CURRENT );
SetTextureStageState( 1, D3DMTSS_COLOROP, D3DMTOP_MODULATE );
SetTextureStageState( 1, D3DMTSS_ALPHAOP, D3DMTOP_DISABLE );
SetTextureStageState( 1, D3DMTSS_TEXCOORDINDEX, 0|D3DMTSS_TCI_PASSTHRU );

まだ ALPHA があいています。
PowerVR だと適用可能なオペレーションの種類がもっと多いのでいろいろ出来るでしょう。


関連エントリ
・HTC Touch Diamond で Direct3DMobile その(7) ノーマルマップを表示する
・HTC Touch Diamond で Direct3DMobile その(6) 頂点性能続き
・HTC Touch Diamond で Direct3DMobile その(5)
・HTC Touch Diamond で Direct3DMobile その(4) 高速化
・HTC Touch Diamond で Direct3DMobile その(3) 実際の頂点性能
・HTC Touch Diamond で Direct3DMobile を使う。その (2)
・HTC Touch Diamond で Direct3DMobile を使う。ハードウエアアクセラレータ

Touch Diamond でノーマルマップの表示が出来ました。



だいたい 22～24fps くらい。
さすがにピクセル単位のライティングは、ローポリでもきれいに出ます。
やっとハードウエアアクセラレータらしい表示が出るようになりました。


↑カラーマップだけ


↑ノーマルマップだけ


↑両方適用

テクスチャは PC 用 Direct3D のサンプルを使用しています。
本当はレリーフマップ用のデータですが、ただのノーマルマップとしてだけ使っています。
これが PC のシェーダーだったら本当はレイキャストで視差も出るし影も落ちるのですが。


この WindowsMobile 用のプログラムは下記から落として試せるようにしました。

ダウンロード
・bumptest v1.00


●動作を確認したもの

◎ハードウエアアクセラレータが有効なもの

　・HTC Touch Diamond (EMOBILE S21HT 他)
　　　Qualcomm MSM7201A 内蔵 ATI core
　　　Touch Diamond はハードウエアアクセラレータで高速に動作します。
　　　おそらく Touch Pro もいける。

◎ハードウエアアクセラレータが無効だけど動くもの

　・HTC Touch Dual (EMONSTER lite S12HT 等)
　　　CPU のリファレンスラスタライザで起動します。
　　　非常に低速ですが画面はきちんと出ます。

◎動作しないもの

　・SHARP EM・ONEα S01SH2
　　　CPU ラスタライザですが XScale ドライバ D3DMXSC50PB です。
　　　マルチテクスチャ＆マルチ UV 未対応なため起動しません。

各端末の 3D 機能について詳しくはこちらを参照してください。

http://hp.vector.co.jp/authors/VA004474/wince/d3dmcapslist.html


●解説など

頂点が遅い＆ハードウエアライティングが遅いので、ピクセルライティングを
試してみました。思ったよりきれいに出ました。
これならローポリでも違和感なく表示できそうです。
ただしその分テクスチャが増えます。

タンジェントスペースの計算は CPU で行っています。
前回調べた結果の通り、CPU ですべて頂点変換を行ったとしてもその割合は
たいしたことありません。
よって CPU 側で少々凝った計算をしても全体へはさほど影響しないとの判断です。

ただ何度も述べてるように、rhw バグがあるため CPU だけで全部の計算を行うと
テクスチャのゆがみが見えてしまいます。
そこで次のようにします。

(1) 動的に CPU で頂点バッファを生成する
　　　ライティングやタンジェントスペースの計算はここで行う。
　　　頂点カラーを求める。
　　　座標は素通りさせる。

(2) 座標変換は Direct3D Mobile に任せる
　　　ここではライティングせずに座標変換のみ。

これで rhw バグを回避できますし、Direct3D Mobile の重いライティングを使わずにすみます。

済むはずでした。

rhw バグは根が深いようです。
フォントの表示など 3D 変換が不要な頂点には最初からスクリーンスペースの座標を
与えると簡単ですが、この場合頂点は XYZRHW 形式になります。
モデルの方は Direct3D Mobile に任せるため RHW の無い XYZ です。

この両方の頂点形式のデータを交互に描画すると、XYZ 形式のモデルが表示されなくなるようです。
仕方なくフォントも 2D 変換の Projection を通して描画するように変更。

その他トラブル
・ZWRITEENABLE を FALSE にすると表示が崩れるので ON 固定に。
・TextureStage の TEXCOORDINDEX が効いてない気がするので頂点側を MultiUV に変更。
・MipFilter を有効にすると MipMap が強制される。MipMap 無しのテクスチャが含まれていると真っ白になる。


問題が多く低速な頂点に比べると、ピクセル側は比較的問題が少なく素直に動いている気がします。
使用可能なテクスチャ形式が少ないことが少々難点です。
16bit フォーマットを選ばざるを得ないので、結局 565 になってしまいます。

22～24 fps くらいしか出てませんが、Touch Diamond の d3dm_ati.dll だとなぜか
空のデータでも最大 28fps 程度にしかならないので、これでも軽い方なのです。


関連エントリ
・HTC Touch Diamond で Direct3DMobile その(6) 頂点性能続き
・HTC Touch Diamond で Direct3DMobile その(5)
・HTC Touch Diamond で Direct3DMobile その(4) 高速化
・HTC Touch Diamond で Direct3DMobile その(3) 実際の頂点性能
・HTC Touch Diamond で Direct3DMobile を使う。その (2)
・HTC Touch Diamond で Direct3DMobile を使う。ハードウエアアクセラレータ

Touch Diamond で Direct3DMobile を使った描画の続きです。
CPU 側の各処理の測定時間になります。

頂点数 ポリゴン数  頂点計算時間  1frame合計    cpuv/v   total/v  total/t
   401       760           700       40000      1.75     99.75    52.63
  1679      3120          2800       46000      1.67     27.40    14.74
  5039      9660          8500       90000      1.69     17.86     9.32
 10199     19800         17000      160000      1.67     15.69     8.08
 22799     44700         38000      348000      1.67     15.26     7.85
                          usec        usec

CPU で行う頂点の変換自体は float よりも固定小数の方が 5～6 倍ほど高速でした。
それでも描画速度向上がわずかだったのは、全体の処理時間からみたら
たいしたことがなかったからです。
全体の処理時間のうち頂点計算の割合は 10% 程度。
残りは全部 Present() が占めます。

カメラ位置を変えてポリゴン自体の描画面積が変わっても、動作速度にはほとんど
変動がありませんでした。
よって kick したあとの実際の描画処理では、頂点数に比例して増加するなんらかの
重い処理が CPU で行われていると予想できます。
あとはレンダーステートの組み合わせなど軽くなる条件を探していくしかなさそうです。

iPhone/iPod touch の実際の描画性能がどのくらいなのか気になるところです。


関連エントリ
・HTC Touch Diamond で Direct3DMobile その(5)
・HTC Touch Diamond で Direct3DMobile その(4) 高速化
・HTC Touch Diamond で Direct3DMobile その(3) 実際の頂点性能
・HTC Touch Diamond で Direct3DMobile を使う。その (2)
・HTC Touch Diamond で Direct3DMobile を使う。ハードウエアアクセラレータ

時間が無くてほとんど触っていませんが、、結果速くなりませんでした。
CPU 処理の方が有利と結論づけるにはまだ検証が足りないようです。

光源ありの場合は不要なものを大幅に省けるので相対的に速度が出ます。
逆に軽いデータでもピーク性能が全く伸びません。
少々触っただけでは何ともいえないので、時間があるときに詳しく測定して
原因を特定する必要がありそうです。

rhw の問題も回避手段が見つからないので、その(3) の結果を受け入れた方が
良いのかもしれません。

・ FIXED のテクスチャ頂点の問題

頂点形式を固定少数 D3DMFVF_TEXCOORDFIXED(0) にした場合に uv 値がおかしい、
テクスチャが出なくなるという問題がありました。

調べたところ FIXED 指定は無視され内部では常に float でアクセスしているようです。
FVF に何を指定しようが float 値を書き込むとうまくいきます。
やはりセットアップエンジンへは float で値が渡っているのでしょうか。
頂点も演算だけ FIXED で行い、バッファへは float で書き込んでみるのもありかも
しれません。

・ rhw の問題

D3DMFVF_XYZRHW_FLOAT や D3DMFVF_XYZRHW_FIXED の rhw に 1.0 以外の値を
書き込むと、ポリゴン自体の描画位置がずれてしまう問題があります。
こちらは特に触っていないので進展は無いです。


関連エントリ
・HTC Touch Diamond で Direct3DMobile その(4) 高速化
・HTC Touch Diamond で Direct3DMobile その(3) 実際の頂点性能
・HTC Touch Diamond で Direct3DMobile を使う。その (2)
・HTC Touch Diamond で Direct3DMobile を使う。ハードウエアアクセラレータ

速くなりました。光源入りで 4つ表示して 23.2fps。
その(2) の時は 1つで 18.5fps しか出ていなかったデータです。


TouchDiamond (Qualcomm MSM7201A) Direct3DMobile

● 前回 調べた結果から

数値を見る限り 30fps でフレーム 10000頂点くらいがいいところでしょうか。
しかもデータ側の頂点数ではなく実演算の頂点数です。
ポリゴン数だとがんばって 3000～4000ポリゴン相当くらい。

さらに裏面や画面外など、描画してないけど計算してしまったポリゴンも含むので
実際に使うと予想以上に少なく感じるはずです。
頂点がかなり足を引っ張る形になります。
(API 呼び出しのオーバーヘッドとかフィル周りはまだ未調査です)
Dreamcast とか PSP クラス とかとても無理で、おそらく DS 未満。

光源を入れるとさらに 2.5 倍ほど重くなるようです。

いろいろ考えた結果、caps が HWTRANSFORMANDLIGHT を返してくるのはたぶん嘘では
ないかと。頂点はおそらく CPU 計算です。


試しに CPU だけで頂点の変換を行ってみたところ、同等以上の速度で描画することができました。
しかも FPU (VFP) が乗ってない CPU で float 演算しているのにこの速度。
caps が NATIVEFLOAT を返してくるので D3DM も CPU で float 演算している可能性が
あります。

固定少数でためしたら、float よりちょっとだけ速くなりました。
これが 最初にのせた 23.2fps の結果となります。

最適化とかほとんど考慮していないのに、それなりに速いのには理由があります。

　・クリッピングしていない
　・頂点バッファ単位で変換しているので共有頂点は一度しか計算していない
　・光源計算は必要最小限で不要なものを省いている

よって実際に使える状態まで機能を入れるともっと負担が多くなるはずです。


●ここまでの結論

　Touch Diamond で D3DM を使う場合
　・CPU で自前で頂点演算をやる
　・CPU 内で完結するものは固定小数演算

自前で書けば、プログラマブルシェーダーのように必要最小限な処理に最適化できます。
ライティングなども実用的な速度で動作すると思います。


●問題点

実際に CPU で頂点演算をしてみると、いくつか問題が出てきました。

・rhw の挙動がおかしい

　自分でスクリーンスペースまで変換した場合、変換後の頂点の rhw の挙動が
　どうもおかしい。狙った通りの結果になりません。
　これがだめだとパースペクティブコレクションが効かないので少々致命的です。

・Fixed 形式の頂点だと Texture の uv が出ない

　負の uv 値でおかしなテクスチャの値になる。原因調査中


関連エントリ
・HTC Touch Diamond で Direct3DMobile その(3) 実際の頂点性能
・HTC Touch Diamond で Direct3DMobile を使う。その (2)
・HTC Touch Diamond で Direct3DMobile を使う。ハードウエアアクセラレータ

HTC Touch Diamond の 3D アクセラレータの速度テストです。
Qualcomm MSM7201A 内蔵 ATI core

時間がないので軽く調査、厳密なテストではないです。
頂点性能だけ見たかったので TriangleStrip で見えるか見えないかぎりぎりの
極小ポリゴン描画を並べたもの。ほとんど 1pixel 以下です。
単一バッファで一度だけ DrawPrimitive() しています。


●低負荷と思われるフォーマットでどれだけ頂点処理できるか

テクスチャ無し、ライティング無し、頂点カラーのみ

FVF = D3DMFVF_XYZ_FLOAT|D3DMFVF_DIFFUSE
struct { // 16byte
	float	x, y, z;
	DWORD	color;
};

頂点数  解像度  頂点形式     速度
 16384   VGA    xyz col     17.0fps   58msec
 32768   VGA    xyz col      9.6fps  103msec
 49152   VGA    xyz col      7.8fps  128msec
 65536   VGA    xyz col      5.7fps  176msec

おおざっぱに 16K 頂点が 40msec とすると、どんなにがんばっても最高 40万頂点/sec
程度しか出ない計算に。
ボトルネックが、頂点補充が追いつかないのか演算なのかは不明。


●ピーク速度に近づきたいために頂点カラーも無くしてみる

FVF = D3DMFVF_XYZ_FLOAT
struct { // 12byte
	float	x, y, z;
};

頂点数  解像度  頂点形式     速度
 16384   VGA    xyz         17.4fps   57msec
 32768   VGA    xyz          9.9fps  100msec
 49152   VGA    xyz          8.0fps  125msec
 65536   VGA    xyz          5.8fps  172msec

頂点カラーの影響は 16K 頂点あたり 1msec くらい。
65536頂点時に 38万頂点/sec


●解像度変更

頂点数  解像度  頂点形式     速度
 16384   VGA    xyz         17.4fps   57msec
 16384   HVGA   xyz         15.7fps   63msec
 16384   QVGA   xyz         22.5fps   44msec
 65536   VGA    xyz          5.8fps  172msec
 65536   HVGA   xyz          9.2fps  108msec
 65536   QVGA   xyz         11.2fps   88msec

フィルの影響も調べるために解像度も変えてテスト。
ポリゴン描画以外はクリアと Flip (COPY) だけなのに解像度の影響がかなりあります。
頂点数の増加によって解像度の影響をより強く受けているので、極小ポリゴンとは
いえそれなりにフィルを消費していることがわかります。

VGA = 639x480 (なぜ 639 なのかはこちら)
HVGA = 480x320 (iPhone/iPod touch や Android G1 がこれ)
QVGA = 320x240


●Memory Pool の違い

頂点数  解像度  頂点形式  Pool          速度
 65536   VGA    xyz       videomem      5.8fps 172msec
 65536   VGA    xyz       systemmem     5.8fps 172msec

caps ではどちらにも配置可能。特に差は無し。
速度が同じなのか、最初から同じメモリなのか、内部で Pool を無視して同一処理して
いるのかは不明。


●Index かどうか

もともと TriangleStrip だし頂点キャッシュが(もしあったとしても)有効なケース
ではないので、アクセスすべきメモリが増えた分だけ遅くなるはず。

頂点数  解像度  頂点形式  Index                   速度
 65536   VGA    xyz       DrawPrimitive           5.8fps 172msec
 65536   VGA    xyz       DrawIndexedPrimitive    5.8fps 173msec

結果、誤差の範囲でほとんど差は出ていません。


●浮動小数と固定少数の違い

頂点形式を FIXED にしても全く差がなかったです。
もともと caps が NATIVEFLOAT を返してくるし HW T&L 入ってるので Float だと
思いますが、どちらにせよ頂点バッファを作った時点で効率よい形式に
変換されていると考えられます。


● Texture つき

一番実用に近いと思われる頂点形式でテストです。
これが使い物になれば何とでもなる。

FVF=	D3DMFVF_XYZ_FLOAT|D3DMFVF_TEX1
	|D3DMFVF_TEXCOORDSIZE2(0)|D3DMFVF_TEXCOORDFLOAT(0)
struct _VTYPE {
	float	x, y, z;
	float	tu, tv;
};

頂点数  解像度  頂点形式       速度
 16384   VGA    xyz tex       16.8fps   59msec
 32768   VGA    xyz tex        9.6fps  104msec
 49152   VGA    xyz tex        7.6fps  131msec
 65536   VGA    xyz tex        5.3fps  190msec
  1000   QVGA   xyz tex       28.5fps   35msec
  1000   VGA    xyz tex       28.0fps   35msec
  5000   VGA    xyz tex       27.4fps   36msec
 10000   VGA    xyz tex       25.8fps   38msec
 20000   VGA    xyz tex       15.9fps   62msec

頂点の負担を見ることが目的なので、結果に大きな影響が出ないように Texture は
1pixel しか読み込んでいません。

ずっと気になっていたのが、必ず 29fps くらいで頭打ちになること。
設定はどれも D3DMPRESENT_INTERVAL_IMMEDIATE です。
これを D3DMPRESENT_INTERVAL_ONE にしてもなぜか同じ。


● Texture + Color つき

かなり使われることが多いフォーマットです。
これが使えればテクスチャを減らせます。

FVF=	D3DMFVF_XYZ_FLOAT|D3DMFVF_DIFFUSE|D3DMFVF_TEX1
	|D3DMFVF_TEXCOORDSIZE2(0)|D3DMFVF_TEXCOORDFLOAT(0)
struct _VTYPE {
	float	x, y, z;
	DWORD	color;
	float	tu, tv;
};

頂点数  解像度  頂点形式       速度
 16384   VGA    xyz col tex   16.6fps   60msec
 32768   VGA    xyz col tex    9.2fps  108msec
 49152   VGA    xyz col tex    6.9fps  145msec
 65536   VGA    xyz col tex    5.2fps  193msec
 10000   VGA    xyz col tex   25.8fps   38msec
 20000   VGA    xyz col tex   15.9fps   63msec

実用的な頂点処理能力としては、フレームあたり 1万ポリゴンくらいが限界といったところです。
ただし単一バッファで一回の描画でこの数値です。
実際は多数の DrawPrimitive() を呼び出すことになるので速度は落ちるはずです。


また前回やった通りライティングはかなり遅いのでテストしてません。
●光源処理あり 2008/01/07 3:02 追記

せっかくなので本当にどれだけ遅いのか光源もテストしてみました。
ハードウエア光源を使うだけで頂点が 2.5倍以上重くなっています。
これは純粋に演算量の増加によるものでしょう。

FVF = D3DMFVF_XYZ_FLOAT|D3DMFVF_NORMAL
struct { // 16byte
	float	x, y, z;
	float	nx, ny, nz;
};

◎平行光源 x1、スペキュラ無し
頂点数  解像度  頂点形式    光源                      速度
 16384   VGA    xyz normal  Dir x1  Diffuse           7.0fps  143msec
 32768   VGA    xyz normal  Dir x1  Diffuse           3.7fps  264msec
 49152   VGA    xyz normal  Dir x1  Diffuse           2.7fps  371msec
 65536   VGA    xyz normal  Dir x1  Diffuse           2.0fps  497msec

◎平行光源 x2、スペキュラ無し
頂点数  解像度  頂点形式    光源                      速度
 16384   VGA    xyz normal  Dir x2  Diffuse           6.9fps  144msec
 32768   VGA    xyz normal  Dir x2  Diffuse           3.7fps  275msec
 49152   VGA    xyz normal  Dir x2  Diffuse           2.6fps  380msec
 65536   VGA    xyz normal  Dir x2  Diffuse           1.9fps  512msec

◎平行光源 x1、スペキュラあり Power=10
頂点数  解像度  頂点形式    光源                      速度
 16384   VGA    xyz normal  Dir x1  Diffuse+Specular  6.1fps  165msec
 32768   VGA    xyz normal  Dir x1  Diffuse+Specular  3.2fps  310msec
 49152   VGA    xyz normal  Dir x1  Diffuse+Specular  2.3fps  440msec

◎平行光源 x2、スペキュラあり Power=10
頂点数  解像度  頂点形式    光源                      速度
 16384   VGA    xyz normal  Dir x2  Diffuse+Specular  6.0fps  165msec
 32768   VGA    xyz normal  Dir x2  Diffuse+Specular  3.2fps  311msec

●TriangleList の負荷 2008/01/07 9:30 追記

TriangleStrip で描画していた全く同じ頂点配列＋ポリゴンを、Index で
TriangleList に展開したものです。
Index の数が (vertices-2)*3 に増えた分だけメモリアクセスが増えますが、
キャッシュがある一般的な GPU だと速度が落ちません。

頂点数  解像度  頂点形式 描画API      PrimitiveType   速度
 32768   VGA    xyz    DrawPrimitive  TriangleStrip  10.1fps   99msec
 32768   VGA    xyz    DrawIndexedPri TriangleStrip  10.0fps  100msec
 32768   VGA    xyz    DrawIndexedPri TriangleList    4.0fps  248msec

プログラムが間違っていなければ頂点キャッシュ無し確定。
おそらく演算が 3倍になってると思われます。


問題はむしろフィルの方なので、あとはピクセルがどれくらい出るかどうか。

・IT Media QUALCOMM、MSM7201A上で動作するAndroidのデモを公開
上のページには PSP に近いくらいと書かれていますが、現状とてもそこまで
出せそうにないです。


関連エントリ
・HTC Touch Diamond で Direct3DMobile を使う。その (2)
・HTC Touch Diamond で Direct3DMobile を使う。ハードウエアアクセラレータ

前回は板を描画するだけで力尽きたので、もうちょっとだけテスト。
16bit 565 なのでマッハバンドが目立ちます。




401頂点、760ポリゴン、平行光源×1(Diffuseのみ)、
Texture 1枚、256x256xR5G6B5 (mip無し、バイリニアフィルタ)
1頂点 32byte (xyz normal texuv float)

TouchDiamond S21HT   VGA  639x480  ATI  d3dm_ati.dll      18.5  fps
EMONSTER lite S12HT  QVGA 320x240  REF  d3dmref.dll        0.25 fps
EM・ONE S01SH        WVGA 800x480  XSC  D3DMXSc50PB.dll    4.3  fps

Touch Diamond は光源なしだとテクスチャ付きでも 30fps 出てました。
LightEnable を TRUE にしただけで 18.5fps へ。
SpecularEnable ではあまり変わらないけどローポリの頂点単位だと見た目がきつい。

他の端末でも走らせてみましたが、解像度が違うのであんまり参考にならないかも。
Reference Driver は遅いです。

Touch Diamond の光源処理には少々問題があります。
World だけの回転でなぜか光源も一緒に動いてしまうこと。
法線用の Matrix の設定が間違っているのか少々バグっぽい挙動です。

・Qualcomm MSM7201

上記ページによると 頂点性能 4M triangle/sec、フィルレート 133M pixel/sec。
1/30sec で frame 13万頂点。おそらくライティング無し、最小頂点形式のピーク値。

フィルは VGA (640x480) の場合全部転送と見なして 14画面分に相当します。
ただし GPU の処理能力なのかバス能力の上限なのかはわかりません。
おおざっぱに 読み出し 16bit texture + 16bit depth 、書き込み 16bit color
+ 16bit depth で 133MHz といったところでしょうか。

4M Triangle/sec というと、スペック上の数値だけなら Dreamcast クラスに見えます。
VGA 解像度や 16bit 565 フレームバッファも同じ。
でも数値だけなのでもちろん無理。

しかもバス帯域を効率よく使う PowerVR に比べるとフィルで不利だし、caps 一覧を
見る限り DXT 圧縮テクスチャがないのも PVR よりバスを圧迫しそう。

実際 D3DM 経由でどの程度パフォーマンス出せるかまだわからないですが、現状
オーバーヘッドもかなり多そうです。
CPU も FPU 無しだし、解像度も高いし、iPhone/iPod touch 比ではかなり不利だと
思われます。


関連エントリ
・HTC Touch Diamond で Direct3DMobile を使う。ハードウエアアクセラレータ

やっと HTC Touch Diamond で Direct3DMobile が動くようになりました。
ハードウエアアクセラレータがきいていて、一応 VGA のフルスクリーンで
28～29fps くらい出ています。
かなり苦労しました。



caps を見ると Touch Pro なども同じかもしれません。


●苦労話

とにかく Touch Diamond では Direct3DM が全く動かなくて驚きました。
昔作ったプログラムも全滅で、WindowsMobile6 SDK のサンプルもだめ。
プログラムは動作するものの全く描画されないという症状。

caps はそれらしい値が取れていて、しかもハードウエアアクセラレータが有効との
魅力的な値を返してきます。
実際に d3dm_ati.dll が読み込まれているところまでは確認できます。

それでも画面は変わらず Clear() で埋めたカラーすら画面には現れてこないという。
D3DMPRESENT_PARAMETERS の組み合わせをいくら変えてもだめ。
画面の回転方向を変えてもだめ。

API 呼び出しは矛盾する設定をするとエラーになるので、一応動作しているようにも
見えます。

ちなみに d3dmref.dll も無いのでリファレンスラスタライザも使えません。
何とか d3dm_ati.dll が動く条件を見つけるしかなさそうです。

とりあえず Present() が悪いのかレンダリングそのものが走っていないのかだけ確認
してみます。

BeginScene();
Clear();
EndScene();
Present();

GetBackBuffer();
CopyRect(); // BackBuffer → ImageSurface
ImageSurface->LockRect()
// 読み出し
ImageSurface->UnlockRect()

こんな感じで BackBuffer の値を読み出してみると、一応カラーが書き込まれている
ことがわかりました。
Present() が失敗してるだけでレンダリングそのものは動いています。
でも Present() はエラーを返さず、Device も Lost していません。

BackBuffer には書き込まれていることがわかったので、Lock して読み出して
自分で Window に描画すれば (力業だけど) 描画できるのではないかと思いつきました。

フレームバッファの値を直接読み出して CPU で DIB に変換。CompatibleBitmap に
描画してからウィンドウにコピー。
最終的には R5G6B5 サーフェースの値がそのまま DIB として利用できることが
わかったので、転送や変換を減らして下記の通りです。

  ～
iDevice->Present( NULL, NULL, NULL, NULL );

IDirect3DMobileSurface*	iBack= NULL;
iDevice->GetBackBuffer( 0, &iBack );
iDevice->CopyRects( iBack, NULL, 0, iSurface, NULL );
iBack->Release();

D3DMLOCKED_RECT	lock;
iSurface->LockRect( &lock, NULL, D3DMLOCK_READONLY );
SetDIBitsToDevice( hDC, 0, 0, Width, Height, 0, 0, 0, Height,
		lock.pBits, &BitmapHead, DIB_RGB_COLORS );
iSurface->UnlockRect();

一応これで VGA (640x480) フルスクリーンでの Direct3DM の描画に成功しました。
でもかなり遅いです。上の最適化した状態で目測 5fps 程度。

この方法は FullScreen でも Windowed どちらでも動作しますが、最終的には
Bitmap 化するためウィンドウの中に描画しています。
転送を減らすため、試しに QVGA 240x320 くらいにフレームバッファを縮小してみます。

FullScreen の場合デバイスの解像度と一致していないとハングアップするので
Windowed = TRUE に。QVGA だとこの方法でも 15fps くらいになりました。

ふとこの状態で Lock ＆ Copy をやめてみると、DIB を通さなくてもちゃんと
描画されていて、しかも 30fps 近く出ていることを発見！
ハードウエアアクセラレータ効いています。

その後いろいろためした結果、なんと「640x480 のレンダリングだけ」失敗することが
わかりました。
例えば 1pixel 減らして 480 x 639 や 478x640 にすると描画できます。

FullScreen (Windowed = FALSE) の場合デバイスの解像度と一致していないと
エラーで落ちるので、WindowMode (Windowed = TRUE) が必須となります。


●結論

・解像度を 480x640 より小さくする (480x639 or 479x640 など)
・小さくするために必ず WindowMode にする

の条件さえ満たせば Touch Diamond でも Direct3D でポリゴン描画できます。

SDK のサンプルなど、多くのプログラムは GetSystemMetrics( SM_CXSCREEN )、
GetSystemMetrics( SM_CYSCREEN ) を使ってデバイスの解像度でレンダリング
しようとしています。これが原因でした。

わかってしまえば簡単なんだけど、、、途中何度挫折しかけたことか。
リファレンスラスタライザが使えていたらすぐあきらめていたかも。