頂点シェーダ後のOpenGL三角形の縮退？

Question

これを参照してください。question：

巨大なメッシュのレンダリング速度を改善する方法はいくつかあります。私は次の実装を試しました：

1. 最適化や量子化なしでメッシュをレンダリングするだけです。
2. 私はメッシュをCPUの前処理ステップとして量子化し、実行時にLODレベル（=量子化レベル）を切り替えることにしました。私は頂点データ全体を提出し、Drawcall（numberOfNotDegeneratedIndices）でレンダリングします。 - > 0より速く
3. 私の今の考え：Vertex-Shader（すべての頂点データが計算とダイナミックLODスイッチングのために存在する）で量子化全体を行います。三角形の縮退は、頂点処理ステップの後に自動的に起こるはずです。 Drawcall（numberOfAllIndices） - >（0）よりも実際には高速ではない

比較されるメソッド：頂点データの提出量は常に同じです。 VSコール：（0）==（2）>（1）

私は量子化とその結果の三角形の退化にもかかわらず、方法（2）が（0）よりも速くならないのだろうかと思いましたか？

これはなぜこれが好きなのか、そしてGPUのボトルネックがどこにあるのかという詳細な情報を得たいと思います。

Answer 1

フレームバッファのサイズを1x1のような不条理なサイズに変更しようとしましたが、ボトルネックが実際に頂点処理であることを確認しましたか？

スクリーンショットなど何も表示されていない場合、レンダリングしようとしている「巨大な」メッシュがどのように見えるかを推測する必要があります。巨大なメッシュが大量のオーバードローにつながる多くのシナリオを考えることができます。その時点で実際にバインドされ、異なるLODを使用するとほとんど差が生じません。

多くの（潜在的に目に見えない）サブピクセルの三角形を描くと面白いことに、ラスタライズのパフォーマンスのボトルネックも発生します。カバレッジルールを満たしていないため、シェーディングでは決して生き残ることはできませんが、ラスタライズ段階まで十分に小さなプリミティブを取得すると、頂点処理とは無関係のペナルティを支払うことになります。 LODはその問題を解決するためにはうまくいくので、ここで問題になることはまずありません。