限られたVRAMで大規模なテクスチャ配列を扱うのはどれくらいうまくいくのですか

Question

私のゲームエンジンは大部分のテクスチャ配列を割り当てて、その描画の大部分（すべてではないにしても）をまとめることができます。この配列は、割り振られていないほど大きくなることがあります。その点では、テクスチャ配列を（連続的に）分割することになります。

glGetError:Out of memoryを受け取ってそこからスケールを戻すまで境界線を押し込むのは悪い設計ですか？

私のアプリケーションは、GTTメモリにスワップする必要があるVRAMの巨大なチャンクを割り当てているので、かわいいですか？同様に、他のOS操作を扱う際に、多くの個々のテクスチャではなく、グラフィックスドライバがいくつかの大きなテクスチャ配列を操作することはあまり理想的ではありませんか？

Answer 1

ドライバが大きなテクスチャ配列をどれだけうまく扱うかを評価するのは難しいです。異なるドライバーの行動は大きく異なる可能性があります。

テクスチャ配列を使用すると、ドローコールの回数を減らすことでパフォーマンスを向上させることができますが、これは主な目標ではありません。ドローコールの削減はモバイルプラットフォームではいくらか重要ですが、そこにも数十もの問題はありません。私はあなたの懸念と正確に何を最適化しようとしているのか分かりませんが、GPUベンダーのプロファイリングツールを使用して最適化を行うことをお勧めします。

Is it bad design to push the boundaries until receiving a glGetError:Out of memory and scale back from there?

これは、データがGPUに動的にロードされるときに通常行われる処理です。エラーが受信されると、古いデータをアンロードして新しいデータをロードする必要があります。

Is my application a jerk because it's allocating huge chunks of VRAM, which may require swapping into GTT memory?

は、データがGTTにスワップされたかどうか（ドライバがまったくGTTをサポートしている場合）を確認する方法はありません。ドライバはそれを単独で処理し、OpenGL APIからのアクセスはありません。 NVidiaのGPUを使用している場合は、Nsightのようなプロファイリングツールを使用する必要があります。

しかし、1つの巨大なテクスチャ配列を持つことを計画している場合は、VRAM全体に収まる必要があります。部分的にVRAMとGTTに配置することはできません。私はGTTに全く頼ることをお勧めしません。

これをバインドすると、シェーダで選択が行われるため、どのレイヤが使用され、どのレイヤが使用されないかは、ドライバが事前に知ることができないため、VRAMに収まる必要があります。

テクスチャ配列と3dtextureは概念的に異なりますが、ハードウェアレベルでは非常によく似ていますが、最初のものは2次元で、2番目のものは3次元でのフィルタリングを使用しています。

私はしばらくの間、大きな3Dテクスチャで遊んでいました。私はGeForce 1070（それは6GBを持っています）で実験しました。そして、それは〜1GBの非常に良いテクスチャを扱います。私が読み込める最大のテクスチャは約3GB（2048x2048x7 **）でしたが、しばしばエラーが発生します。テクスチャに適合する大量のフリーVRAMが必要であるにもかかわらず、そのような大きなチャンクを割り当てることができない理由はさまざまです。だから、絶対に必要でない限り、VRAMの合計サイズに匹敵するテクスチャを割り当てることはお勧めしません。