プロフィール

Na-7

Author:Na-7
SE(システムエンジニア)として約15年間システム系ソフト会社を勤めあげ、2008年3月退社。現在、ゲーム制作会社設立を目指して活動中。


アクセスカウンター


最新記事


最新コメント


最新トラックバック


月別アーカイブ


カテゴリ


DATE: CATEGORY:スポンサー広告
上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
DATE: CATEGORY:三国志軍記開発
GamefestJapan2008Demo
GamefestJapan2008デモ実行画面
こちらにUPされている動的頂点バッファデモ実行画面。
方式を変えてもFPSは一緒?



◎前回の続き

すみませんがまた予定を変更して前回の続きです。

前回は動的頂点バッファが意外に遅くてガッカリしましたが、こちらの記事に原因らしきことが書かれてました。

「頂点変換をはじめとするシェーダーでするべき仕事もCPUでしてしまい」「CPUで頂点変換処理をした時に比べて、単純なシェーダー処理をするだけで8.5倍」

もしかしたら、前回デモのネックはCPU側で、シェーダー処理に変えればパフォーマンスが向上する、ということかも?



◎デモ実行

まずはデモプログラムをリリースビルドし、EXEを実行して数値を確認しました。

(Particles: 3,000 → 10,000)

○Draw Method: SpriteBatch
FPS:60.02 → 24.45
Bar 0 Update Avg.:0.08 → 0.25ms
Bar 0 Draw Avg.:1.21 → 3.50ms
Bar 1 Draw Avg.:0.98 → 3.20ms

○Draw Method: TransformedVertex
FPS:60.02 → 24.16
Bar 0 Update Avg.:0.08 → 0.27ms
Bar 0 Draw Avg.:2.25 → 7.26ms
Bar 1 Draw Avg.:0.28 → 1.00ms
Bar 1 FillVertex Avg.:1.47 → m4.93s
Bar 1 SetData Avg.:0.13 → 0.39ms

○Draw Method: ParameterInVertex
FPS:60.02 → 23.94
Bar 0 Update Avg.:0.08 → 0.29ms
Bar 0 Draw Avg.:1.04 → 3.53ms
Bar 1 Draw Avg.:0.37 → 1.36ms
Bar 1 FillVertex Avg.:0.15 → 0.56ms
Bar 1 SetData Avg.:0.17 → 0.62ms

う~む…。

2番目のTransformedVertexが「CPUで頂点変換処理」方式で、3番目のParameterInVertexが「単純なシェーダー処理」方式らしいのですが、どの方式もFPSは同じですね。FillVertex Avg.は8倍以上の差がありますが、これを「速度アップ」と言っているのでしょうか?

だとすると、今までFPSを計測してパフォーマンス比較していたのは「間違い」ということになります。逆に、FPSで比較するのが正しいとすれば「私のPC環境では差が出ないケースがある」ということになります。

いずれにせよ、これまでの計測方法は(比較数値または検証環境が)間違っていた可能性が高そうです。

…どうにも、参りましたねぇ(ー_ー;



◎描画処理の時間

ちょっとヘコみましたが、気を取り直して話を進めましょう。

ソースを覗いて確認すると、FillVertexは以下の時間を示すものでした。

描画方法2(TransformedVertex):
「登録されているパーティクルから4頂点を計算してバッファに格納する時間」

描画方法3(ParameterInVertex):
「登録されているパーティクルのパラメーターを4頂点に増やしてバッファに格納する時間」

これだけだど描画処理の一部にすぎないので、比較するならBar単位(FillVertex+SetData+Draw、またはBar0)で比較すべきと思いますが、それだと差は2~3倍程度ですね。

他のPC環境だと、8倍ぐらい差が出ることもあるのかなぁ?



◎結論

描画方法2と描画方法3の数値の差は2~3倍ですが、これはCPU側のみの数値です。GPU側の数値はありません。あえて言うなら、FPSがCPU+GPUの数値に該当すると思います。

気になるのはParticles:10,000のケースで、CPU側の数値は差があるのに、FPSは差がありません。これはつまり、GPU側がネックになっていて、CPU側のパフォーマンスを改善しても効果が無い、ということではないでしょうか?

だとすると、私のPC環境では3番目の方式も「実質的な効果は無い」という結論になります。(CPU側が空くので他の処理を行う余裕は出来るが、ボトルネックは解消できない)


それとパフォーマンスの計測方法ですが、以前yohさんからアドバイスを頂いた通り、GameDebugライブラリを導入した方が良さそうです。面倒な時はせめてタスクマネージャでCPU負荷をチェックして、遅延原因がCPU側かGPU側か切り分ける習慣を付けるべきですね。



◎シェーダーモデルのターゲットバージョン

私のメインPCでは、ハードウェアインスタンシングのデモが表示されません。グラボが未対応だからでしょう。(ちなみにシェーダーインスタンシングは表示されます)

できればシェーダーモデル2.0でも遊べるようにしたいのですが、グラボが毎度ネックになるようで、いい加減切り捨てたくもあります。

シェーダーモデル2.0のPC、どれくらいあるのかなぁ?
2年前に購入した目の前のPCがその1台なので、少なくなさそうな気もしますが…ただの錯覚?w



◎次回予告

高速化できるかと期待したのですが、結局またグラボがネックでガッカリな結果に終わりました。

次はインスタンシングなので、シェーダーモデルのターゲットバージョンも決めないといけませんね。

スポンサーサイト

テーマ : ゲーム製作 関連 - ジャンル : ゲーム

コメント

あ、いや、最初にGameDebugの話を持ち出されたのはHOSSIEさんだったかと。

ちなみに今こちらで開発に使っているノートPCのGPUはシェーダー2.0までっぽいです。平たい話、ノートPCだとグラフィックボードの性能は落ちるんじゃないでしょうか。

シェーダーインスタンシングだと、あらかじめモデルの中にインスタンスの個数分のコピーを作っておいて、各頂点データにインスタンス番号を振っておかないといけないんでしたっけ。Pipelineを弄ることになりますね。

こんばんわ~

>あ、いや、最初にGameDebugの話を持ち出されたのはHOSSIEさんだったかと。
そうでしたね。失礼しました(^^;

>ノートPC
確かに、ノートPCのグラボは性能低そうですね。HWインスタンシングを使うと、ノートPCの大半を切り捨てることになるかも…う~ん。

>シェーダーインスタンシング
まだ調査中ですが、そんな感じだと思います。調査が終わったら、概要をまとめてHPにUPしたいな~、などと考えています。

いつも拝見させていただいています。
vDogのIkumoです。


Intel系チップセット内蔵グラフィックスでは、バーテクスシェーダーをソフトウェアで対応しています。

パフォーマンスが出ないのはこのせいではないでしょうか。


ハードウェアインスタンシングを使用するにはSM3.0以上のグラフィックスが必要です。

デモが表示されないのは使用しているグラフィックスがSM3.0に対応していないのかもしれません。


はじめまして、Ikumoさん

ブログの動画を拝見させて頂きました。凄くレベル高いですね!ジャンプ力も!w

ブログのHNはvDogとされているようですが、もしかしてvDogはチーム名のようなものでしょうか?


>ソフトウェアで対応
ということは、GPU側で処理してるように見えても、実はCPUが処理してるということですね。XNA実行時に、Core2DuoCPUの片方の負荷が高いのは、その影響かもしれませんね。

>パフォーマンスが出ないのはこのせいではないでしょうか。
その可能性が高そうです。ありがとうございました。

>SM3.0に対応していないのかもしれません。
そうですね。私もそう思います。


コメントありがとうございました。
今後ともよろしくお願いします。

コメントの投稿


管理者にだけ表示を許可する

トラックバック


この記事にトラックバックする(FC2ブログユーザー)



copyright © ゲーム制作の舞台裏 all rights reserved.Powered by FC2ブログ
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。