2010/02/28
Dirct3D Mobile DeviceCaps 更新
Hybrid W-ZERO3 (WS027SH) と SC-01B の d3dmcaps 情報を送っていただいたので
更新しました。
・Direct3D Mobile DeviceCaps 一覧
SHARP Hybrid W-ZORO3 (WS027SH) は Qualcomm MSM7200A を搭載しており ATI 製
GPU core によるアクセラレータが有効となっていました。
・WILLCOM HYBRID W-ZERO3
機能も TouchDiamond 等、MSM7201A 内蔵 GPU に非常によく似ていることがわかります。
CPU も同じ ARM11 だしほぼ同等の機能&性能ではないかと考えられます。
特筆すべき点としては ZERO3 系で初めて 3Dアクセラレータを搭載したということ。
Qualcomm の MSM 系は採用機種も多く珍しい存在ではありませんが、3G 機能のおかげで
ZERO3 も 3D や GPS など他のスマートフォンと同等の機能が使えるようになりました。
docomo の SC-01B は d3dmcpas を見る限りハードウエアアクセラレータが無効と
なっているようです。ところが調べてみると、搭載されている S3C6410 自体は
高機能なことがわかります。
・SAMSUNG SC-01B
3D アクセラレータが載っており、OpenGL ES 2.0 対応なのでおそらく Shader も
使えるはずです。Direct3D Mobile に対応していないのは残念ですが、OpenGL ES なら
ハードウエアアクセラレータが使えるかもしれません。
CPU 自体も ARM11 core ながら 1176ZJF なので VFP がついています。
さすがに最新の Snapdragon 等 ARM v7+GL ES 2.0 系と比較するのは酷ですが
VFP や OpenGL ES 2.0 対応など全体的に Qualcomm MSM7~ 系より上だと感じました。
S3C6410 は SmartQ5 にも使われているようです。
更新しました。
・Direct3D Mobile DeviceCaps 一覧
SHARP Hybrid W-ZORO3 (WS027SH) は Qualcomm MSM7200A を搭載しており ATI 製
GPU core によるアクセラレータが有効となっていました。
・WILLCOM HYBRID W-ZERO3
機能も TouchDiamond 等、MSM7201A 内蔵 GPU に非常によく似ていることがわかります。
CPU も同じ ARM11 だしほぼ同等の機能&性能ではないかと考えられます。
特筆すべき点としては ZERO3 系で初めて 3Dアクセラレータを搭載したということ。
Qualcomm の MSM 系は採用機種も多く珍しい存在ではありませんが、3G 機能のおかげで
ZERO3 も 3D や GPS など他のスマートフォンと同等の機能が使えるようになりました。
docomo の SC-01B は d3dmcpas を見る限りハードウエアアクセラレータが無効と
なっているようです。ところが調べてみると、搭載されている S3C6410 自体は
高機能なことがわかります。
・SAMSUNG SC-01B
3D アクセラレータが載っており、OpenGL ES 2.0 対応なのでおそらく Shader も
使えるはずです。Direct3D Mobile に対応していないのは残念ですが、OpenGL ES なら
ハードウエアアクセラレータが使えるかもしれません。
CPU 自体も ARM11 core ながら 1176ZJF なので VFP がついています。
さすがに最新の Snapdragon 等 ARM v7+GL ES 2.0 系と比較するのは酷ですが
VFP や OpenGL ES 2.0 対応など全体的に Qualcomm MSM7~ 系より上だと感じました。
S3C6410 は SmartQ5 にも使われているようです。
2010/02/20
NetWalker PC-Z1 のその後と OpenGL ES 2.0 Emulator
NetWalker は OpenGL ES 2.0 テスト機として活躍しています。
解像度が高いのでフルスクリーンだと遅いけどシェーダーもきちんと動くし、
コンパイルは遅いけど自分でビルドできるのですっかり開発用になってしまいました。
GPU だけでなく ARM Cortex-A8 のテストにも良い感じで使えます。
NetWalker に使われている Freescale i.MX515 の GPU は AMD (ATI) Z430 です。
未確認ですが、おそらく Snapdragon 系 (QSD8250等) に使われているものと同じだと
思われます。ただし CPU core は同じ ARM v7 世代ですが異なるものです。
どれも ARM v7 で OpenGL ES 2.0 対応です。
Cortex-A8 は VFP が低速なので、速度を優先する場合はたとえスカラーであっても
積極的に NEON 命令を用いる必要があります。(参考)
Scorpion の VFP/NEON の場合は、果たしてどのような特性を示すでしょうか。
ほぼ 2択となった Desktop と違い、Mobile 向け GPU はまだまだ種類が豊富です。
それぞれ GPU 毎に各社から OpenGL ES 2.0 Emulator が提供されているようです。
ARM 製, NVIDIA 製のものもありました。
・AMD OpenGL ES Emulator
・Imagination POWERVR Insider
・ARM mali Developer Center OpenGL ES 2.0 Emualtor
・NVIDIA Developer Zone Tegra 250 Developer SDK
関連エントリ
・ARM Cortex-A8 の NEON と浮動小数演算最適化
・OpenGL ES 2.0 Emulator
・Direct3D Mobile と T-01A の Snapdragon
解像度が高いのでフルスクリーンだと遅いけどシェーダーもきちんと動くし、
コンパイルは遅いけど自分でビルドできるのですっかり開発用になってしまいました。
GPU だけでなく ARM Cortex-A8 のテストにも良い感じで使えます。
NetWalker に使われている Freescale i.MX515 の GPU は AMD (ATI) Z430 です。
未確認ですが、おそらく Snapdragon 系 (QSD8250等) に使われているものと同じだと
思われます。ただし CPU core は同じ ARM v7 世代ですが異なるものです。
NetWalker iPhone 3GS Nexus One他
i.MX515 S5PC100 QSD8250 (Snapdragon)
GPU ATI Z430 PVR SGX535 ATI Z430
CPU Cortex-A8 Cortex-A8 Scorpion
どれも ARM v7 で OpenGL ES 2.0 対応です。
Cortex-A8 は VFP が低速なので、速度を優先する場合はたとえスカラーであっても
積極的に NEON 命令を用いる必要があります。(参考)
Scorpion の VFP/NEON の場合は、果たしてどのような特性を示すでしょうか。
ほぼ 2択となった Desktop と違い、Mobile 向け GPU はまだまだ種類が豊富です。
それぞれ GPU 毎に各社から OpenGL ES 2.0 Emulator が提供されているようです。
ARM 製, NVIDIA 製のものもありました。
・AMD OpenGL ES Emulator
・Imagination POWERVR Insider
・ARM mali Developer Center OpenGL ES 2.0 Emualtor
・NVIDIA Developer Zone Tegra 250 Developer SDK
関連エントリ
・ARM Cortex-A8 の NEON と浮動小数演算最適化
・OpenGL ES 2.0 Emulator
・Direct3D Mobile と T-01A の Snapdragon
2010/02/07
DirectX SDK February 2010
DirectX SDK Feb10 がリリースされました。
・DirectX SDK February 2010
前回 August 2009 で Direct3D 11 が RTM したためあまり大きな変更が無いようです。
Direct3D の core 部分はもちろん変更なし。
D3D 周りはライブラリやツール更新が中心で DLL 番号も変わっていませんでした。
SDK 付属のドキュメント(マニュアル) Windows DirectX Graphics Documentation
に至っては August 2009 のまま。
ドキュメントに Direct3D 9, 10, 11 と 3バージョン併記されている状態はいつまで
続くのでしょうか。10,11 が FueatureLevel によって Direct3D 9 仕様を取り込んだ
ため、従来であれば刷新されていてもおかしくはない状態です。
Windows7 の普及次第かもしれません。
今後 Direct3D 11 対応のツールやドライバが増えてくれることを願うばかりです。
関連エントリ
・DirectX SDK August 2009 の解説と Direct3D 11 RTM
・DirectX SDK February 2010
前回 August 2009 で Direct3D 11 が RTM したためあまり大きな変更が無いようです。
Direct3D の core 部分はもちろん変更なし。
D3D 周りはライブラリやツール更新が中心で DLL 番号も変わっていませんでした。
SDK 付属のドキュメント(マニュアル) Windows DirectX Graphics Documentation
に至っては August 2009 のまま。
ドキュメントに Direct3D 9, 10, 11 と 3バージョン併記されている状態はいつまで
続くのでしょうか。10,11 が FueatureLevel によって Direct3D 9 仕様を取り込んだ
ため、従来であれば刷新されていてもおかしくはない状態です。
Windows7 の普及次第かもしれません。
今後 Direct3D 11 対応のツールやドライバが増えてくれることを願うばかりです。
関連エントリ
・DirectX SDK August 2009 の解説と Direct3D 11 RTM
2010/01/31
OpenGL を Direct3D 互換で使う
モバイル系の API はほぼ OpenGL ES 2.0 で統一されつつあります。
Direct3D Mobile は DirectX8 ベースのサブセットで、固定機能パイプラインだけが
残されています。OpenGL ES 1.0 世代と同等、機能的には DirectX7 相当と言って
差し支えないかもしれません。
プログラマブルシェーダーの仕様を取り込んで Direct3D9 相当の仕様まで進んだのは
OpenGL ES 2.0 だけでした。WindowsCE 採用の端末でも 3D API としては
OpenGL ES 2.0 が用いられていることが多いようです。
そこで最近は OpneGL 上でも動くよう、互換性を考えて描画エンジンやライブラリを
作ることが多くなりました。普段デスクトップ PC では Direct3D を使いつつも、
モバイル系への応用を考えて OpenGL にも対応しています。
幸いなことにプログラマブルシェーダーが一般化しており、座標系や Matrix の扱い方
などはプログラマに開放されています。
もはやレガシーな入門書の通りに従う必要は無くなりました。
双方とも一番下の描画 API だけ使う分にはほとんど差がありません。どちらの API を
使おうとも動いているハードウエアは同じなので、当たり前といえば当たり前です。
Direct3D の方が経験が長いので、個人的には Direct3D 互換のまま使えた方が便利です。
これまで溜め込んだ 3D のライブラリ群やシェーダー、ツールを活用することができるからです。
逆に Direct3D での蓄積が特に無く、OpenGL 用の上位ライブラリやツール類を使う予定が
あるなら、素直に OpenGL の流儀に従った方が混乱は少ないでしょう。
● OpenGL を左手座標系で使用する方法
過去に下記のエントリで触れています。
・OpenGLES2.0 D3D座標系
基本的に何もする必要が無く、使う側でどちらか一方に定義してしまえば終わりです。
カリングの向きだけ違うので変更しています。
座標系の違いは文字コードの違いのようなもので、どちらかの流儀で統一してしまえば
混乱はありません。中途半端に混在していると、相互に変換が必要になったりと
ややこしいことになります。
● OpenGL と Direct3D の座標系の違い
OpenGL 座標系と Direct3D 座標系の違いは、左手系、右手系以外にもあります。
Clip 座標系の Z の範囲が異なります。これは VertexShader の出力値に相当します。
w の範囲はどちらも n~f なので、OpenGL では -n ~ f, Direct3D では 0 ~ f の値を
とります。Direct3D 用に作られた Projection Matrix を用いて OpenGL の VertexShader
から出力を行うと Z の範囲が狭くなっているわけです。
OpenGL 用のドライバは -w ~ w の値を期待しているので VertexShader の出力値も
あわせて補正します。
符号が異なるものの、この変換を事前に Matrix に畳み込んだのが OpenGL の
Projection Matrix といえます。
どちらも最終的には Z バッファ格納時に 0~1.0 の範囲に変換されます。
ドライバなり何らかの追加ハードウエアによって、上で追加した補正と逆の変換が行われて
いると予想できます。
OpenGL の VertexShader のあとに、変換するためのシェーダー命令がいくつか挿入されて
いるのかもしれません。仮に PostVertexShader としておきます。
Direct3D の場合は最初から 0起点で求まるので、VertexShader 後段での z 変換は
w 除算のみと単純になっています。
この違いはシャドウマップを扱うとよくわかります。
● OpenGL と Direct3D のシャドウマップ
バッファに格納された depth 値は 0~1.0 の範囲なので、ハードウエアシャドウマップも
この範囲で比較が行われます。
Vertex Shader の出力は Clip 座標であるため、その後の 0~1.0 への変換は触れない
ところにありドライバに任されています。
ところがシャドウマップ参照時に比較に用いる depth シェーダー側で用意しなければ
なりません。光源の Projection Matrix 適用後に Z 範囲を 0~1.0 に変換するわけです。
結局 PostVertexShader が Z をどう変換しているのか知っておく必要があります。
OpenGL 用の HW Shadow Map のサンプルを見ていると、Texture 座標変換 Matrix に
X,Y (u,v) だけでなく Z にも 0.5 のスケーリングと 0.5 のオフセットが加えられて
いるのがわかります。
これは Direct3D では存在しないパラメータで、PostVertexShader が行っている
補正と同じことです。実質 OpenGL でも Shadow Map 時には、Direct3D 相当の Matrix を
作っていると言えるかもしれません。
Direct3D の場合はそのまま z/w だけで 0~1.0 になるため比較的シンプルです。
●まとめ
今のところ Culling、VertexShader 出力 z 値の補正、の 2点だけで Direct3D と全く同じ
データや演算ライブラリを使っています。今後他にも変更点が出てくる可能性があります。
API の使い方とかリソースの変換も必要ですが、そのあたりは過去のエントリでも
触れています。
関連エントリ
・OpenGLES2.0 DDS テクスチャを読み込む
・OpenGLES2.0 Direct3D とのフォーマット変換
・OpenGLES 2.0 頂点フォーマットの管理
・OpenGLES2.0 の頂点
・OpenGLES2.0 D3D座標系
・OpenGLES2.0 シェーダー管理
Direct3D Mobile は DirectX8 ベースのサブセットで、固定機能パイプラインだけが
残されています。OpenGL ES 1.0 世代と同等、機能的には DirectX7 相当と言って
差し支えないかもしれません。
プログラマブルシェーダーの仕様を取り込んで Direct3D9 相当の仕様まで進んだのは
OpenGL ES 2.0 だけでした。WindowsCE 採用の端末でも 3D API としては
OpenGL ES 2.0 が用いられていることが多いようです。
そこで最近は OpneGL 上でも動くよう、互換性を考えて描画エンジンやライブラリを
作ることが多くなりました。普段デスクトップ PC では Direct3D を使いつつも、
モバイル系への応用を考えて OpenGL にも対応しています。
幸いなことにプログラマブルシェーダーが一般化しており、座標系や Matrix の扱い方
などはプログラマに開放されています。
もはやレガシーな入門書の通りに従う必要は無くなりました。
双方とも一番下の描画 API だけ使う分にはほとんど差がありません。どちらの API を
使おうとも動いているハードウエアは同じなので、当たり前といえば当たり前です。
Direct3D の方が経験が長いので、個人的には Direct3D 互換のまま使えた方が便利です。
これまで溜め込んだ 3D のライブラリ群やシェーダー、ツールを活用することができるからです。
逆に Direct3D での蓄積が特に無く、OpenGL 用の上位ライブラリやツール類を使う予定が
あるなら、素直に OpenGL の流儀に従った方が混乱は少ないでしょう。
● OpenGL を左手座標系で使用する方法
過去に下記のエントリで触れています。
・OpenGLES2.0 D3D座標系
基本的に何もする必要が無く、使う側でどちらか一方に定義してしまえば終わりです。
カリングの向きだけ違うので変更しています。
座標系の違いは文字コードの違いのようなもので、どちらかの流儀で統一してしまえば
混乱はありません。中途半端に混在していると、相互に変換が必要になったりと
ややこしいことになります。
● OpenGL と Direct3D の座標系の違い
OpenGL 座標系と Direct3D 座標系の違いは、左手系、右手系以外にもあります。
Clip 座標系の Z の範囲が異なります。これは VertexShader の出力値に相当します。
OpenGL: -w ~ w Direct3D: 0 ~ w
w の範囲はどちらも n~f なので、OpenGL では -n ~ f, Direct3D では 0 ~ f の値を
とります。Direct3D 用に作られた Projection Matrix を用いて OpenGL の VertexShader
から出力を行うと Z の範囲が狭くなっているわけです。
OpenGL 用のドライバは -w ~ w の値を期待しているので VertexShader の出力値も
あわせて補正します。
vec4 opos= vec4( POSITION.xyz, 1.0 ) * ProjectionViewWorld; opos.z= 2.0 * opos.z - opos.w; // 0~w → -w~w gl_Position= opos;
符号が異なるものの、この変換を事前に Matrix に畳み込んだのが OpenGL の
Projection Matrix といえます。
どちらも最終的には Z バッファ格納時に 0~1.0 の範囲に変換されます。
ドライバなり何らかの追加ハードウエアによって、上で追加した補正と逆の変換が行われて
いると予想できます。
OpenGL の VertexShader のあとに、変換するためのシェーダー命令がいくつか挿入されて
いるのかもしれません。仮に PostVertexShader としておきます。
Direct3D の場合は最初から 0起点で求まるので、VertexShader 後段での z 変換は
w 除算のみと単純になっています。
この違いはシャドウマップを扱うとよくわかります。
● OpenGL と Direct3D のシャドウマップ
バッファに格納された depth 値は 0~1.0 の範囲なので、ハードウエアシャドウマップも
この範囲で比較が行われます。
Vertex Shader の出力は Clip 座標であるため、その後の 0~1.0 への変換は触れない
ところにありドライバに任されています。
ところがシャドウマップ参照時に比較に用いる depth シェーダー側で用意しなければ
なりません。光源の Projection Matrix 適用後に Z 範囲を 0~1.0 に変換するわけです。
結局 PostVertexShader が Z をどう変換しているのか知っておく必要があります。
OpenGL 用の HW Shadow Map のサンプルを見ていると、Texture 座標変換 Matrix に
X,Y (u,v) だけでなく Z にも 0.5 のスケーリングと 0.5 のオフセットが加えられて
いるのがわかります。
これは Direct3D では存在しないパラメータで、PostVertexShader が行っている
補正と同じことです。実質 OpenGL でも Shadow Map 時には、Direct3D 相当の Matrix を
作っていると言えるかもしれません。
Direct3D の場合はそのまま z/w だけで 0~1.0 になるため比較的シンプルです。
●まとめ
今のところ Culling、VertexShader 出力 z 値の補正、の 2点だけで Direct3D と全く同じ
データや演算ライブラリを使っています。今後他にも変更点が出てくる可能性があります。
API の使い方とかリソースの変換も必要ですが、そのあたりは過去のエントリでも
触れています。
関連エントリ
・OpenGLES2.0 DDS テクスチャを読み込む
・OpenGLES2.0 Direct3D とのフォーマット変換
・OpenGLES 2.0 頂点フォーマットの管理
・OpenGLES2.0 の頂点
・OpenGLES2.0 D3D座標系
・OpenGLES2.0 シェーダー管理
一ヶ月遅れですが RADEON に戻したのでドライバを更新しました。
こちら と比べるとわかるとおり、Concurrent Creates 対応になっています。
Command Lists がまだなので、スレッド完全対応もあともう少しです。
他にも OpenGL 3.2 対応など機能拡張されているようです。
気がついた点としては、GeForce と同じように最初から OpenGL 3.2 の Context を
返してくること。従来は 2.x ベースでした。
ただ 3.2 の API できちんと動いていない部分があるので、API だけ 3.1 に落として
使っています。3.1 context を作っても GLSL は 1.5。
※ 2010/01/31追記: Catalyst 10.1 (2010/01版) では改善されており、RADEON 上で OpenGL 3.2 がきちんと動いています。
2枚目用に補助電源無しの GeForce が必要になったので、
DirectX 10.1 対応のGeForce GT 240 を買ってみました。
GeForce ながら 10.1 に対応していることがわかります。
Shader Model に 4.x と表記されているのは 4.1 のことです。
もっと細かい違いとか踏み込んで調べたいところですが、時間的にしばらくは無理そうです。
そうこうしているうちに Fermi も出てきそうですね。
後発は機能拡張に積極的なので Fermi 系 2世代目が出るあたりには D3D の次の
バージョンが見えてくるのかもしれません。年末あたりでしょうか。
関連エントリ
・DirectX 11 / Direct3D 11 と RADEON HD 5870 の caps
こちら と比べるとわかるとおり、Concurrent Creates 対応になっています。
RADEON HD 5850 Catalyst 9.12 Windows7 x64 Direct3D 11 Feature Level D3D_FEATURE_LEVEL_11_0 Driver Concurrent Creates Yes Driver Command Lists No Double-precision Shaders Yes Compute Shader 4.x Yes D3D_FEATURE_LEVEL_11_0 Shader Model 5.0 Geometry Shader Yes Stream Out Yes Compute Shader Yes Hull & Domain Shaders Yes Texture Resource Arrays Yes Cubemap Resource Arrays Yes BC4/BC5 Compression Yes BC6H/BC7 Compression Yes Alpha-to-coverage Yes Extended Formats (BGRA, etc.) Yes 10-bit XR High Color Format Yes
Command Lists がまだなので、スレッド完全対応もあともう少しです。
他にも OpenGL 3.2 対応など機能拡張されているようです。
気がついた点としては、GeForce と同じように最初から OpenGL 3.2 の Context を
返してくること。従来は 2.x ベースでした。
ただ 3.2 の API できちんと動いていない部分があるので、API だけ 3.1 に落として
使っています。3.1 context を作っても GLSL は 1.5。
※ 2010/01/31追記: Catalyst 10.1 (2010/01版) では改善されており、RADEON 上で OpenGL 3.2 がきちんと動いています。
2枚目用に補助電源無しの GeForce が必要になったので、
DirectX 10.1 対応のGeForce GT 240 を買ってみました。
GeForce GT 240 Driver 195.62 Windows7 x64 Direct3D 11 Feature Level D3D_FEATURE_LEVEL_10_1 Driver Concurrent Creates Yes Driver Command Lists No Double-precision Shaders No Compute Shader 4.x Yes D3D_FEATURE_LEVEL_10_1 Shader Model 4.x Geometry Shader Yes Stream Out Yes Compute Shader Optional (Yes) Hull & Domain Shaders No Texture Resource Arrays Yes Cubemap Resource Arrays Yes BC4/BC5 Compression Yes BC6H/BC7 Compression No Alpha-to-coverage Yes Extended Formats (BGRA, etc.) Optional (Yes) 10-bit XR High Color Format Optional (Yes)
GeForce ながら 10.1 に対応していることがわかります。
Shader Model に 4.x と表記されているのは 4.1 のことです。
もっと細かい違いとか踏み込んで調べたいところですが、時間的にしばらくは無理そうです。
そうこうしているうちに Fermi も出てきそうですね。
後発は機能拡張に積極的なので Fermi 系 2世代目が出るあたりには D3D の次の
バージョンが見えてくるのかもしれません。年末あたりでしょうか。
関連エントリ
・DirectX 11 / Direct3D 11 と RADEON HD 5870 の caps
| 次のページ(日付が古い方向)>>