1

エンジンの OpenGL ストレス テストに関する情報を取得するために計測器を使用しています。

長い期間を経て、上位 3 つの関数 (OpenGL ES Analyzer Instrument の API 統計を使用) は次のとおりです。

  1. EAGLContext_presentRenderBuffer (654,827,246)
  2. glBufferData (16,128,155)
  3. glDrawElements (11,555,768)

EAGLContext_presentRenderBuffer が非常に高いのはなぜですか? 私の推測では、CPU 使用率が非常に低いため、このタイミングには vsync を待機する CPU でのストールに費やされた時間も含まれています。

あれは正しいですか？そうでない場合、この関数の高コストを説明できるものは他にありますか?

4

1 に答える 1

2

私の経験では、これの大部分は、iOS デバイスで使用されるタイル ベースの遅延レンダラーの「遅延」部分に由来します。シーンのレンダリングをセットアップするとき、GPU は必要になる直前まで多くのドロー コールを延期します。

多くの場合、これは、OpenGL ES の描画呼び出しが CPU で計測されると非常に高速に見えることを意味しますが、シーンから読み取ったり表示したりする最後の要素には多くの時間がかかるようです。最後の呼び出しは、すべてのレンダリングが完了するまでブロックされます。これは、完成した画像を画面に表示するために true である必要があるためです。

残念ながら、OpenGL ES シーンのどのステージが最も遅いかを正確に評価できないため、レンダリングのプロファイリングが難しくなる可能性があります。ここで、OpenGL ES ドライバー インストゥルメントを使用して、ジオメトリまたはフィル レートが制限されているかどうかを判断し、パイプラインにダミー要素を配置してボトルネックを特定しようとしました。

OpenGL ES 用の Time Profiler に相当するものはまだありません。見たい場合は機能リクエストを提出することをお勧めします。私はそうするだろうと知っています。

于 2012-12-18T04:52:14.320 に答える