« VRAM 容量を考える | メイン | 炎エフェクトリリースへ向けて……へのはずが »
2008年02月28日
吉里吉里 DirectX拡張:: パフォーマンスに関すること
Tweet @jin1016をフォローだいぶ前に他のことを調べていて知ったのだが、DirectX では出来るだけ API 呼び出しを抑えるようにしないと重いようだ。
どうも、DirectX の API 体系ではドライバ内でいろいろとやることがあるらしく、API を呼び出すとそれなりの CPU 時間を食われるんだとか。
そのため見た目はたいしたことないのに、やたら重いゲームも存在するとか。
で、そのゲームでは GPU よりも CPU 側が先に頭打ちになって重くなっているとか。
なるほど。
だから、昔作ったのは単に板ポリで 2D の絵を出していただけだったのに重かったのか。
確かに、その時は GPU よりも CPU が先に頭打ちになっていた。
で、結局どうすればいいのかだけど、まずマテリアルの変更は出来るだけ抑えて、頂点に入れられる情報は出来るだけ頂点に入れる。
テクスチャは出来るだけ分割せず、まとめて１枚に収め、同じテクスチャを使うものは一度に描く。
ということのようだ。
他にも、呼び出し回数が抑えられるように出来るだけいろいろと工夫した方がよいようだ。
他にポリゴン数云々よりも、フィルレートの方が重要らしく、半透明のポリゴンは出来るだけ避けた方がよいようだ。
半透明のポリゴンは、後ろから描くようにソートして重ね塗りされるので、塗る面積が大きくなる。
また、不透明のポリゴンは、手前から描くことで塗られる面積を抑えられる。
後、テクスチャの二の累乗制限だけど、この制限がなくても二の累乗にしておいた方がパフォーマンス上有利なようだ。
まあ、昔は二の累乗制限があったことや、二の累乗であればテクスチャマッピングは楽になることを考えるとこれは普通に理解できる。
また、二の累乗制限がないからといって、VRAM 上でもちゃんと指定したサイズで確保されているとは限らない。
以前、640x480 でテクスチャを確保してビデオ再生をしていた時、ストライドのサイズを見ると、幅が 768 になっていた。
つまり、512 + 256？
このことから指定したサイズよりも余分にメモリが確保されている可能性がある。
という事で、テクスチャは二の累乗にしておいた方がいい。
以上を踏まえた上での基本戦略を考える。
まず、テクスチャは確保できる最大サイズで確保しておく。
同じシーンで描画する画像は、そのテクスチャに詰め込む。
半透明かどうかで取り扱いが変わるので、半透明と不透明のものは分けておく。
シーングラフを走査した後、半透明の有無やテクスチャの相違などでソートしてから描画コマンドを発行する。
こんなところかな。
まあ、実際はいろいろと試してみてパフォーマンスが出る方法にして行こうと思う。
それと、いくつか Direct3D を使うオープンソースのライブラリがあるので、それらのソースも読んでおく。
後、同じシーンで描画する画像かどうかを事前に判別するために、シーンのはじめに使用する画像を教えてやるようにしないといけない。
教えなくても出来るけど、教えた方がより効率的に配分できるはず。
投稿者 Takenori : 2008年02月28日 17:44
comments powered by Disqus