android dev phone1 で OpenGLES の速度評価 （２）

今日も速度評価しました。

テクスチャ張ったり、ライティング（平行光源１つ）してみたり、頂点カラー入力してみたり。

昨日もチラッと書きましたら、テクスチャ張ったり、頂点カラー入れたりすると、２０％、３０％と、速度が落ちていきます。これは妥当なところでしょう。しかし、ライティングを行うと、２分の１～３分の１に速度が落ちるのです。

これは、ちょっと速度が落ちすぎです。原因を探ろうと色々やってみた結果、どうも、buffer object　と関係がありそうです。

OpenGLES には、buffer object と呼ぶ、GPU側で管理される頂点メモリがあります（　DirectXでいう　VertexBuffer　）。これを使用するとメモリの転送が減り、ディスプレイリストの構築も軽くなるため、大幅な速度向上が見込めるものであり、G1のアクセラレータも対応しています。（OpenGLES1.0の仕様には入っていませんので拡張APIとして実装されています。）

ただし、buffer objectを使うということは、座標変換やライティング計算をジオメトリエンジンがすべて処理できなければいけません。ですが、携帯向けのプアなハードでは処理できないものもあり、一部をCPUで処理しなければいけなかったりします。例えば、スポットライトの減衰計算が仕様を満たせないとか、ライトの個数が４個以上はCPUで処理するとか、ハードにバグがあった場合とか、、、

今回、速度測定をしてみて、buffer object を使うことで大幅に早くなることは確認できたのですが、ライティングを行うとあまり変わりませんでした。平行光源１個だけだというのに。現状のドライバは、CPUで何らかの処理をしているのでしょうか。光源処理がすべてCPUなのでしょうか。

残念ながら、1M polygon / sec を超えるのは、テクスチャ＆頂点カラーを使ってもよいが、read-only buffer object を使った場合だけのようです。光源処理をした場合は、buffer object を使ったメリットがなくなってしまい、最大でも、400k　が限界でしょうか。

話は変わるけど、G1　の OpenGLES って、MatrixPalette　は実装されているのに、VertexBlend　が見当たらないなあ。確かサポートしていたはずだけど。さらに、1.1 の仕様書からも削除されてる気がする。動かそうと思ってたけど、まあいいか。他にも試したいことは色々あるけど、速度評価はそろそろ終了。