6

非常に大きい (そして GPU RAM をいっぱいにする) オブジェクトの表示のパフォーマンスを改善する試みで、ある程度軽い計算を行った後、頂点データを 16 バイトの頂点から 4 バイトに圧縮する機能があることを発見しました。頂点 (データは、概念的には、頂点 ID からの x と y の位置を意味する、わずかに変換された高さマップと見なすことができるため)、Z 座標を、たとえば 30 ビットに密にパックして、カラー パレット インデックス。とにかくその考えです。私の質問はコーディネートのパッキングではなく、カラーのパッキングです。

カラー パレットは、モデルをロードする C++ コードによって選択されます。シェーダーもロードするため、現在、カラー ルックアップ コードを switch ステートメントとして記述しようとしています。

int colourIndex = (compressedVertex & Mask) >> bitOffset;
switch (colourIndex)
{
case 0: return vec4(....);
case 1: return vec4(....);
case 2: return vec4(....);
case 3: return vec4(....);
}

モデルの色数が 4 よりも多い場合、高さの精度を少し犠牲にして、より多くのカラー パレットを (とにかくある程度までは) 収めることができます。私の測定では、switch ステートメントを使用して 4 色のパレットをバインドすることは、4 ピクセルの 1D テクスチャをバインドし、サンプラーを使用してそれから読み取るよりも遅くないことが示されています。

これまでに 32 色までスケールアップしましたが、少なくともテクスチャを使用するのと同じくらい高速に見えます。

スイッチの使用をやめ、ルックアップ テーブルにテクスチャの使用を開始するのに適した時期はいつですか? それが私が開発しているアプリケーションに役立つ場合、OpenGl 3.3 の最小要件が既に適用されています。データがカードに保存されると、変更されることはありません。ケースステートメントを 256 個まで上げることはできますか? 1024? 32768? どこが限界？

(先制応答: はい、実験を続け、試行錯誤と補間を使用して、1 枚の最新のカードで機能する値を選択できます。しかし、ベスト プラクティスとは何か、および他の誰かが似たようなことを試して、実際にうまくいくことを知っていますか?)

4

1 に答える 1

2

シェーダーでの分岐はできるだけ避けています。私のアドバイスは、ルックアップを行うためにテクスチャを使用することです。

あなたが尋ねる：

ケースステートメントを 256 個まで上げることはできますか? 1024? 32768? どこが限界？

そしてあなたは言う：

これまでに 32 色までスケールアップしましたが、少なくともテクスチャを使用するのと同じくらい高速に見えます。

OpenGL は、テクスチャの検索に適しています。それを行うように設計されています。巨大な switch case ステートメント用に設計されていません。そして、コメンテーターが言うように、それは全面的にうまく機能しません. 64x64 ピクセルのテクスチャでは 4096 回のルックアップが可能であり、長い目で見れば、より多くのルックアップよりも高速になると思います。

于 2014-12-09T09:54:39.940 に答える