4

したがって、glGenerateMipMapは優れています。私はいくつかのことについて疑問に思っています：

  • テクスチャ イメージが glTexSubImage2D を介して変更されたとします。glGenerateMipMapへの別の呼び出しは、十分/必要/不要ですか?
  • エンドユーザーがオンザフライで「ミップマップを有効/無効にする」ことができると仮定すると、もちろん GL_TEXTURE_MIN_FILTER はミップマップに応じて設定する必要があります。ただし、以前に生成されたミップマップは GPU VRAM に残りますよね? -- それらを削除するようにドライバーに「ヒント」を与えることはできますか? 元のテクスチャ イメージを再アップロードする必要がありますか (ただし、現在は min-filtering が mipmap に設定されていません)、以前に生成された不要なミップマップを含むメモリをクリアする必要がありますか?

背景 - 上記の質問に対するより多くの洞察を必要とする他のユースケースの中でも、「アプリによって消費されるおよその GPU VRAM を追跡」したいと思います (スケーラブルな任意のテクスチャ/頂点ストリーミングなど、あらゆる種類の理由から) ) --- アプリによって満たされた GL バッファだけでなく、アップロードされたテクスチャも追跡することによって (確かに、それは単なる概算ですが、十分です)。ミップマップを追跡することも必要であるため、それらをクリアする方法、または現在の世代の GL 実装によっていつクリアされるかを知ることは非常に役立ちます。

4

1 に答える 1

4

テクスチャ イメージが glTexSubImage2D を介して変更されたと仮定すると、glGenerateMipMap への別の呼び出しは十分か、必要か、不要か?

アップロードされたベース レベルをミップマップに正しく反映させたい場合は、はい。glGenerateMipmapsこれは 1 回限りの操作であり、テクスチャ上で切り替えるスイッチではありません。

ただし、以前に生成されたミップマップは GPU VRAM に残りますよね? -- それらを削除するようにドライバーに「ヒント」を与えることはできますか?

気にしないでください。そのようにドライバーにメモリの割り当てを解除するように指示することは、常に悪い考えです。実際、同じミップマップ レベルに対して glTexImage* を複数回呼び出すことは (キューブマップの面をアップロードする場合を除き)、悪い考えです。

この理由をより明確に説明するために、比較的新しい OpenGL 関数を考えてみましょうglTexStorage2D。この関数を使用すると、テクスチャのストレージが不変になります。それはあなたが言うミップマップの数を永遠に持っています（もちろん削除するまで）。

なんで？さて、ARB_texture_storage 拡張から:

4: これらのエントリ ポイントを使用すると、メタデータ (形式とサイズ) が不変になりますか?

解決済み: はい。

DISCUSSION: メタデータが変更できないことを知っていることの利点は、テクスチャ仕様の呼び出しごとに TEXTURE_IMMUTABLE_FORMAT フラグをチェックする余分なコストをおそらく上回るでしょう。

ARB はこれに利点があると考えています。実際、ARB_texture_viewはそれなしではおそらく不可能 (または少なくとも非常に非効率的) です。明らかに、それが彼らが人々に使ってほしいものです。

ユーザーがそのスイッチを切り替えて実際にメモリを回復できるようにしたい場合は、適切に実行してください。古いオブジェクトと同じ内容を持つ新しいテクスチャ オブジェクトを作成します。

いずれにせよ、OpenGL にはミップマップ レイヤーの割り当てを解除する方法がないため、問題にはなりません。

于 2012-10-22T07:09:44.637 に答える