ハーフ/クォーター テクスチャ ディメンション バリアント
レンダー ターゲットではないテクスチャで、テクスチャのディメンションを小さくします。
解釈
テクスチャを小さくすると占有するメモリが少なくなるため、消費するメモリ帯域幅が減少し、GPU のテクスチャ キャッシュでの負荷も減少します。 ただし、ディテールを低下させると、特に、3-D シーンで厳密に表示される場合や、拡大して表示される場合にはイメージ品質が低下することがあります。
このバリアントによりパフォーマンスが大幅に向上する場合は、アプリケーションで使用しているメモリ帯域幅が多すぎる、テクスチャ キャッシュを非効率に使用している、またはその両方の原因が考えられます。 また、テクスチャが、使用できる GPU メモリよりも多くのメモリを占有していることも考えられますが、これはテクスチャがシステム メモリへページングされる原因になります。
アプリケーションで使用するメモリ帯域幅が多すぎる、またはテクスチャ キャッシュを非効率に使用している場合は、該当するテクスチャに対して MIP マップを有効にすることを考慮した後で、テクスチャのサイズを減らすことを考慮してください。 テクスチャを小さくした場合と同様に、MIP マップされたテクスチャで消費するメモリ帯域幅は少なくなります (ただし占有する GPU メモリは多くなります)。また、キャッシュの使用率は向上しますが、テクスチャのディテールは低下しません。 メモリの使用率が向上しても、テクスチャがシステム メモリへページングされない場合は、MIP マップを推奨します。
テクスチャが通常よりも多くの GUP メモリを占有している場合は、該当するテクスチャの圧縮を考慮した後で、テクスチャのサイズを小さくすることを考慮してください。 テクスチャを小さくした場合と同様に、圧縮したテクスチャは占有するメモリが少なくなり、システム メモリへページングされる必要が少なくなりますが、色の忠実性は低下します。 圧縮は、すべてのテクスチャに適しているわけではなく、テクスチャの内容によって決まります (たとえば、小さい領域に多数の色のバリエーションがある場合です)。ただし多くのテクスチャでは、サイズを小さくするよりも全体のイメージ品質は低下せずに保持されます。
解説
ソース テクスチャを作成する ID3D11Device::CreateTexture2D への呼び出しがあるたびに、テクスチャのディメンションは減少します。 テクスチャのディメンションは、具体的には pDesc で渡される D3D11_TEXTURE2D_DESC オブジェクトが、レンダリングで使用されるテクスチャを記述するときに減少します。つまり、
BindFlags メンバーは D3D11_BIND_SHADER_RESOURCE フラグを設定するだけです。
MiscFlags メンバーは、D3D11_RESOURCE_MISC_TILE_POOL フラグまたは D3D11_RESOURCE_MISC_TILED フラグを設定しません (タイル型のリソースはリサイズされません)。
テクスチャの形式は、D3D11_FORMAT_SUPPORT_RENDER_TARGET で定義されているとおりにレンダー ターゲットとしてサポートされます。これは、テクスチャ サイズを小さくするときに必要です。 BC1、BC2、および BC3 の形式もサポートされていますが、これらの形式はレンダー ターゲットとしてはサポートされていません。
アプリケーションによって初期データが提供されている場合は、このバリアントはテクスチャを作成する前に、テクスチャ データを適切なサイズへ拡張します。 初期データが BC1、BC2、BC3 などのブロック圧縮形式で提供されている場合は、初期データは、小さいテクスチャの作成に使用される前に、デコード、拡張、および再エンコードされます。 (ブロックベースの圧縮の特性は、特別なデコード - スケール - エンコードのプロセスによりほぼ必ず、エンコードされていないテクスチャのスケール バージョンから、ブロック圧縮テクスチャが生成される場合に比べて、イメージ品質の低下が生じることです)。
テクスチャに対して MIP マップが有効になっている場合、バリアントはそれに応じて MIP レベルの値を減らします。半分のサイズにスケールするときはレベルを 1 小さくし、4 分の 1 のサイズにスケールするときはレベルを 2 小さくします。
例
このバリアントは、CreateTexture2D への呼び出しを行う前に、実行時にテクスチャをリサイズします。 実行コードについては、このアプローチは推奨されません。フルサイズのテクスチャはより多くのディスク容量を使用し、追加のステップによってアプリケーションのロード時間が長くなることがあるためです (特に、圧縮されたテクスチャでは、エンコード用に大量のコンピューティング リソースが必要です)。 代わりに、イメージ エディタ、またはビルド パイプラインの一部であるイメージ プロセッサを使用して、テクスチャをオフラインでリサイズすることを推奨しています。 これらのアプローチではディスク容量の要件が減り、アプリケーションのランタイム オーバーヘッドが排除され、処理時間に余裕があるため、テクスチャを縮小または圧縮しつつ最高のイメージ品質を保持することができます。