22. パフォーマンス

22.010 パフォーマンスについて知るべきことは?

第一に、本11章から14章までを読んでください Silicon GraphicsシステムのOpenGL 。 情報のうちのいくらかが具体的なSGIマシンであるけれども、情報のほとんどは、どのようなプラットフォームにおいてもプログラミングしているOpenGLにあてはまります。 それは、性能注意を払われたOpenGLプログラマーのために測り知れないほど貴重な読みです。

性能調整類似を考慮してください: データベースアプリケーションは、ネットワークの上のその時間を送っているデータのレコードおよび95パーセントを探すのにその時間の5パーセントを費やします。 データベース開発者は、性能を調整すると決めます。 彼は座り、注視のためのコードを見ますレコードおよび少しの簡単な変化によって、彼が時間を減らすことができるとわかる上では、それは、レコードを50パーセントより多く探すために取ります。 彼は変化を起こし、データベースをコンパイルし、それを実行します。 彼の狼狽に、ほとんどまたは目立っている性能増加が全然ありません!

何が起こりましたか? 彼が調整しはじめる前に、開発者はボトルネックを識別しませんでした。 ボトルネックがである所で、OpenGLプログラムの性能を押し上げる試行が識別する必要がある時にすることができる最も重要な事。

グラフィックスアプリケーションはいくつかの場所で縛られているかもしれません。 一般的に言って、ボトルネックは3つの一般的なカテゴリーに降ります: CPUが制限したこと、幾何学が制限したこと、および制限される満たし。

制限されたCPUは、一般用語です。 特に、それは、CPUのスピードで性能が制限されるのを意味しています。 アプリケーションは、バス帯域幅によりよりよい実施が防止されて制限されたバスでもあるかもしれません。 RAMのキャッシュサイズと量は、パフォーマンスについて役割も果たすことができます。 真実のCPU制限されたアプリケーションのために、性能はより速いCPUによって増大します。 性能を増大させる別の方法は、CPU資源へのアプリケーションの要求を減らすことです。

どれほど速く、コンピュータまたはグラフィックスハードウェアが、変化、刈り込み、点火、選択、頂点霧、/頂点基礎において実行された他のOpenGL操作などの頂点計算を実行できるかによって幾何学制限申請は束縛されます。 多くのまさしくそのローエンドグラフィックス機器のために、この処理はCPUにおいて実行されます。 このケースにおいて、CPUの間のラインが制限し、制限された幾何学はあいまいになります。 一般に、制限されたCPUは、ボトルネックがグラフィックスのために無関係なCPU処理であるのを暗示しています。

満たし制限された申込書において、どれほど速くグラフィックスハードウェアがピクセルを満たすかもしれないかによって、できるレートは制限されます。 より速く行くために、より少ないピクセルを満たすか、または簡素化し、どのようにピクセルが満たされるかための方法を見つける必要があります。従って、それらはより速いレートで満たされるかもしれません。

それは、通常、申込書が、制限される満たしであるかどうかを認識するのにまったく簡単です。 ウィンドウサイズが縮み、見てください if 上のスピード 。 もしそれがするならば、制限される満たしです。

もし制限される満たしではないならば、制限されたCPUまたは制限された幾何学です。 CPU制限について試験を受ける一方の方法は、コードを変更することです。従って、それは、繰り返し、静的で、前もって計算された場面をします。 もし性能がかなりより速いならば、CPU制限を扱っています。 場面を計算するか、または他のアプリケーション具体的な処理をするコードの部分は、性能ヒットを起こします。 コードのこの部分を調整することを中心に行う必要があります。

もしそれが、制限されたCPUではなく、満たす制限ではないならば 祝いの言葉 ! それは、制限された幾何学です。 /頂点機能 可能にしたか、または、している頂点の切断ボリュームは、性能ヒットを起こします。 頂点の数を減らすこと、または個々の頂点を処理するためにOpenGLが用いなければならない計算を減らすことによって処理している幾何学を減らす必要があります。

22.020 アプリケーションのパフォーマンス測定方法は?

アプリケーションの性能を測定するためには、システム時間を観察し、いくらかの表現をし、そして、再びシステム時間を観察してください。 2つのシステム時の違いは、どれほど長く、与えるために、アプリケーションが取ったかをあなたに示します。 ベンチマーキンググラフィックスは、いいえ ベンチマーキングから違い です どのような他の操作 コンピュータシステム でも。

多くのグラフィックスプログラマーはしばしば秒(FPS)あたりフレームを測定したい。 簡単な方法は、システム時間を観察することであり、フレームをし、再びシステム時間を観察します。 FPSはその時(1.0として故意です /elapsed_time)。 タイミングの複数フレームによってより正確な寸法を得ることができます。 例えば、もし10のフレームをするならば、FPSは(10.0であるでしょう /elapsed_time)。

秒あたりプリミティブまたは三角形を得るためには、カウンターを、表現のために個々のプリミティブが提出されるとインクリメントするためのコードに追加してください。 最初システム時間が得られる時には、このカウンターは0までリセットされる必要があります。 もしすでにほとんど完全な複雑なアプリケーションを持っているならば、再考としてこのベンチマーキング機能を追加することが難しいでしょう。 秒あたりプリミティブを測定するつもりの時には、それは、精神のベンチマーキングによってアプリケーションをデザインするのに最も良い。

秒あたり計算用のピクセルは少し難しい。 最も秒あたりピクセルを計算しやすい方法は、知られているピクセルサイズのプリミティブをする小さいベンチマークプログラムを書くことです。

GLUT 3.7は、OpenGL性能を測定することと自由にそれでダウンロードするprogs/bucciarelli/gltestと呼ばれるベンチマークで来ます標準性能評価企業も訪問できて最新の性能はいくつかのOpenGLハードウェアベンダに起因しているだけでなく、多くのベンチマークを持ち あなた 、自由にダウンロードできます

22.030 どのプリミティブが最速か?

GL_TRIANGLE_STRIPは、一般に最も多くの最適なOpenGLプリミティブタイプと認められます。 制限された幾何学でない限り、原始的なタイプが違いを生じさせないかもしれないことに気づいてください。

22.040 冗長なコールにかかる時間は?

いくつかのOpenGLインプリメンテーションが冗長な電話をできる限り安くする間、制作冗長な呼び出しは一般に悪い実行と考えられます。 確かに、安いこととしての冗長な呼び出しを期待するべきではありません。 よいアプリケーション開発者は可能な時に、それらを避けます。

22.050 (n) 個の光源をつけている状態で (n+1) 番目の光源をオンにすると、突然パフォーマンスが劇的に落ちたが、何が起きたのか?

ハードウェアにおいてけれどもサポートしたものより多いライトをつけたので、ハードウェアから グラフィックス機器サポート(n)ライト 蹴られて、ソフトウェアにおいて現在与えています。 この問題は、を除いて 少ないライトを使う と 唯一の解決策 よりよいハードウェアを買うことです。

22.060 n 個の異なるテクスチャ・マップを使用中に、(n+1) 枚目のテクスチャ・マップを使用し始めると、パフォーマンスが劇的に落ちたが、何が起きたのか?

グラフィックス機器は、専門のテクスチャーマップメモリーの制限された量を持っています。 (n)テクスチャーはテクスチャーメモリーによく納まるけれども、より以上のテクスチャーマップのために去られた部屋がありませんでした。 テクスチャーを使い(n+1)始めた時には、突然、機器はフレームのために、すべてのテクスチャー 必要なそれ を蓄えることができるわけではなく、 それは 中でコンピュータのシステムメモリーからそれらを交換する必要がありました。 個々のフレームのこれらのテクスチャーをダウンロードするために必要な追加のバス帯域幅によりパフォーマンスが殺されました。

画質の費用でより小さいテクスチャーマップを使うことを考慮してさしつかえありません

22.070 glDrawPixels()とglReadPixels()コマンドが大変遅いのはなぜか?

多くのよりハイエンドのUNIXワークステーションクラス機器でOpenGL2Dパス(その呼び出しのような)の性能が容認できる間、いくつかのインプリメンテーション(特に、ローエンド安い消費者レベルグラフィックスカード)は、決してよい2Dパス性能を持っていませんでした。 人は、それらのコストを倒すためにコーナーがこれらの機器またはデバイス・ドライバに刻みつけられたことを期待するだけで、マーケティングするそれらの時間を減少できます。 もし500ドルの下のためのグラフィックス機器を購入するならば、これが、書かれた(2000年初め)であった時に、チャンスがOpenGL2Dパス性能である 受け入れ不可能に遅い。

もしグラフィックスシステムが、きちんとした性能を持っているべきであるけれども、しないならば、性能を押し上げるために取ることができるいくつかの処置があります

第一に、すべてのglPixelTransfer()状態はそれらのデフォルト値に設定されるべきです。 また、glPixelStore()は、8に設定されるべきそのデフォルト値〈GL_PACK_ALIGNMENTおよびGL_UNPACK_ALIGNMENT(適切なものどれでも)を除いた〉に設定されるべきです。 データポインタは対応して2倍である必要があります 位置合わせされた-言葉 。

第二に、glDrawPixels()またはglReadPixels()にパラメータを試験してください。 それらはframebufferレイアウトと一致していますか? どのようにアプリケーションのためにframebufferが設定されるかについて考えてください。 例えば、もし8ビットの宛先アルファによって24ビットframebufferに与えていると知っているならば、タイプパラメータはGL_RGBAであり、フォーマットパラメータはGL_UNSIGNED_BYTEであるはずです。 もしタイプとフォーマットパラメータが、framebufferコンフィギュレーションと一致していないならば、それはたぶんあなたです それを処理している/ピクセルのため、行き当たられたパフォーマンスを被る パラメータ指定とframebufferフォーマットの間のデータを翻訳するために必要とした 。

最後に、非現実的な予想を持っていないことを確かめてください。 システムバスとメモリー帯域幅制限を知ってください。

22.080 絶対座標と相対座標とどちらを使う方が速いか?

絶対の(または「世界」)座標を使うことによって、アプリケーションはしばしばModelView行列を変更する必要がありません。 相対的な(または「反対してください」)座標を使うことによって、冗長なプリミティブまたは幾何学のデータ記憶装置を減量できます。

よい類似は、アーキテクチャ上のソフトウェアパッケージ that モデル ホテル です。 ホテルモデルは同一のほとんどという数十万の部屋を持っています。 一定の機能は個々の部屋で同一で、たぶん、個々の部屋は、同じランプまたは同じ軽いスイッチまたはドアノブを持っています。 アプリケーションは、ほんの1人のドアノブモデルを引き留めることを選び、個々のホテル部屋ドアによってドアノブを報いることが必要であるようにModelView行列を変更できます。 この方法の有利は、データ記憶装置が最小化されることです。 不利は、性能を減らすことができるModelView行列を変更するためにいくつかの電話がかけられることです。 代わりに、アプリケーションは、代わりに、それぞれ絶対座標で設定されたそれ自身によってドアノブの数百のコピーを覚えていることを選ぶことができました。 これらのドアノブすべては変化なしでModelView行列にできました。 有利は、少ない行列変化のため、増大した性能の可能性です。 不利は追加のメモリーオーバーヘッドです。 もしメモリーオーバーヘッドが手におえなくなるならば、ページングは問題になるかもしれないであろう、それは確かに、性能ヒットです。

この質問へのクリアな返答が全然ありません。 それはモデルおよびアプリケーション具体的です。 ベンチマークにどの方法がモデルまたはアプリケーションに最も良いかを決定する必要があります。

22.090 ディスプレイリストと頂点配列とどちらが速いか?

どれがより速いかがシステムからシステムに変わります

もしアプリケーションが、制限された幾何学ではないならば、ディスプレイリスト、頂点配列、または即時のモードでさえの間のすべてで性能違いを見るわけではないでしょう

22.100 三角形から三角形ストリップにするにはどうするのですか?

22.030において言及されるようにGL_TRIANGLE_STRIPは一般に最も多くの最適なプリミティブと認められます。 もし幾何学が、頂点とエッジを共有するいくつかの別個の三角形から成っているならば、性能を改善するために、データを三角形ストリップに変換したいでしょう。

別個の三角形から三角形ストリップを作成するために、隣接した三角形を見つけて、参加するために、アルゴリズムを実施する必要があります

これをするためのコードはウェブで自由に入手可能です縞パッケージは1つの解決策です