ブロック圧縮 (Direct3D 10)
ブロック圧縮とは、テクスチャー サイズを減少させる圧縮方法です。各色 32 ビットのテクスチャーと比較すると、ブロック圧縮したテクスチャーは最大で 75% 縮小できます。メモリー フットプリントが小さいため、ブロック圧縮を使用する際、アプリケーションでは通常、パフォーマンスが向上します。
ブロック圧縮は不可逆圧縮ですが、効果的であり、パイプラインで変換およびフィルターされたすべてのテクスチャーに推奨されます。画面に直接マッピングされるテクスチャー (アイコンやテキストのような UI 要素) は、処理結果が比較的目立つので、圧縮にはあまり適していません。
ブロック圧縮されたテクスチャーは、すべての次元で 4 の倍数のサイズで作成する必要があり、パイプラインの出力として使用することはできません。
- ブロック圧縮のしくみ
- ブロック圧縮の使用
- 圧縮アルゴリズム
- Direct3D 10.1 を使用したフォーマット変換
ブロック圧縮のしくみ
ブロック圧縮は、カラー データの保存に必要なメモリーの量を減少させるための方法です。ある色を元のサイズで保存し、他の色をエンコード スキームを使用して保存することにより、その画像の保存に必要なメモリーの量を大幅に減少させることができます。圧縮されたデータはハードウェアが自動的にデコードするので、圧縮されたテクスチャーを使用しても、パフォーマンスの損失は発生しません。
圧縮がどのように行われるかについては、以下の 2 つの例を参照してください。最初の例では、圧縮されないデータを保存する際に使用されるメモリーの量について説明します。2 番目の例では、圧縮されたデータを保存する際に使用されるメモリーの量について説明します。
圧縮されないデータの保存
以下のイメージは、圧縮されていない 4×4 のテクスチャーを表しています。各色には、単一のカラー成分 (たとえば赤) が含まれ、1 バイトのメモリーに保存されているとします。
.gif "Ee415727.d3d10_block_compress_1(ja-jp,VS.85).gif")
圧縮されていないデータはメモリーに順次レイアウトされ、以下のイメージに示すように、16 バイト必要となります。
.gif "Ee415727.d3d10_block_compress_2(ja-jp,VS.85).gif")
圧縮されたデータの保存
圧縮されていないイメージがどれぐらいの量のメモリーを使用するかを理解したところで、圧縮されたイメージがどれだけ多くのメモリーを使わずに済むかを説明します。BC1 圧縮フォーマットでは、2 つの色 (各 1 バイト) と、テクスチャーにある元の色の補間に使用する 16 個の 3 ビット インデックス (48 ビットまたは 6 バイト) を格納します。
.gif "Ee415727.d3d10_block_compress_3(ja-jp,VS.85).gif")
圧縮されたデータを保存するのに必要な領域の合計は 8 バイトで、圧縮されていない例に比べて 50% のメモリーを使用せずに済んでいます。1 つ以上のカラー成分を使用する場合、使用せずに済む量はさらに多くなります。
ブロック圧縮によってかなりの量のメモリーを使用せずに済むことで、パフォーマンスの向上につなげることができます。このパフォーマンスは、画質を犠牲にして得られるものですが (色の補間による)、多くの場合、画質の低下は顕著ではありません。
次のセクションでは、Direct3D 10 を使用して、アプリケーションでブロック圧縮を簡単に使用する方法を示します。
ブロック圧縮の使用
ブロック圧縮フォーマットを指定すること以外は、圧縮されないテクスチャーと同様にブロック圧縮テクスチャーを作成します (「ファイルからのテクスチャーの作成」を参照してください)。
loadInfo.Format = DXGI_FORMAT_BC1_UNORM; D3DX10CreateTextureFromFile(...);
次に、ビューを作成して、テクスチャーをパイプラインにバインドします。ブロック圧縮されたテクスチャーはシェーダー ステージへの入力としてのみ使用できるので、ID3D10Device::CreateShaderResourceView を呼び出してシェーダー リソース ビューを作成します。
ブロック圧縮されたテクスチャーを、圧縮されていないテクスチャーを使用する場合と同様に使用します。アプリケーションがブロック圧縮データへのメモリー ポインターを取得した場合は、ミップマップのメモリー パディングを考慮する必要があります。このメモリー パディングは、宣言されたサイズが実際のサイズと異なる原因となります。
仮想サイズ対物理サイズ
メモリー ポインターを使用して、ブロック圧縮されたテクスチャーのメモリーを扱うアプリケーション コードがある場合、アプリケーション コードの変更が必要となる可能性がある重要な考慮事項が 1 つあります。ブロック圧縮アルゴリズムは 4x4 のテクセル ブロックで処理するため、ブロック圧縮されたテクスチャーはすべての次元で 4 の倍数である必要があります。これは、最初の次元が 4 で割り切れるが、さらに分割すると 4 で割り切れなくなるミップマップでは問題となります。以下の図は、各ミップマップ レベルの仮想サイズ (宣言されたサイズ) と物理サイズ (実際のサイズ) の間の領域の違いを示しています。
図形 1. 圧縮されていないミップマップ レベルと圧縮されたミップマップ レベルの比較
.gif "Ee415727.d3d10_block_compress_pad(ja-jp,VS.85).gif")
図の左側は、圧縮されていない 60×40 のテクスチャーに対して生成されるミップマップ レベル サイズを示しています。最上位レベルのサイズは、テクスチャーを生成する API 呼び出しから取得されます。後続の各レベルは、前のレベルのサイズの半分になります。圧縮されていないテクスチャーでは、仮想サイズ (宣言されたサイズ) と物理サイズ (実際のサイズ) との間で差はありません。
図の右側は、圧縮された 60×40 のテクスチャーに対して生成されるミップマップ レベル サイズを示しています。2 番目と 3 番目のレベルにはどちらも、各レベルのサイズが 4 で割り切れるように、メモリー パディングが追加されていることに注意してください。これは、アルゴリズムが 4×4 のテクセル ブロックで処理できるようにするために必要です。4×4 よりも小さいミップマップ レベルを考慮する場合、これは特に明白です。これらの非常に小さいミップマップ レベルのサイズは、テクスチャー メモリーが割り当てられる際、4 を因数とする最も近い数に切り上げられます。
サンプリング ハードウェアは仮想サイズを使用します。テクスチャーがサンプリングされる際、メモリー パディングは無視されます。4×4 よりも小さいミップマップ レベルでは、最初の 4 つのテクセルのみが 2×2 のマップに使用され、最初のテクセルのみが 1×1 のブロックで使用されます。ただし、物理サイズ (メモリー パディングを含む) を明らかにする API 構造はありません。
つまり、ブロック圧縮したデータを含む領域をコピーする際は、アライメントされたメモリー ブロックは注意して使用してください。メモリー ポインターを取得するアプリケーションでこれを実行するには、必ずそのポインターがサーフェス ピッチを使用して物理メモリー サイズを明らかにするようにします。
圧縮アルゴリズム
Direct3D のブロック圧縮方法では、圧縮されていないテクスチャー データを 4×4 のブロックに分割し、各ブロックを圧縮してから、そのデータを保存します。このため、圧縮されるテクスチャーは、テクスチャーの次元が 4 の倍数である必要があります。
図形 2. Direct3D 10 のブロック圧縮
.gif "Ee415727.d3d10_compression_1(ja-jp,VS.85).gif")
以下の図は、テクセル ブロックに分割されたテクスチャーを示しています。最初のブロックは、a ～ p のラベルがついた 16 のテクセルのレイアウトを示していますが、各ブロックには同じ構造のデータがあります。
Direct3D は圧縮スキームをいくつか実装しています。それぞれ、保存される成分数、成分ごとのビット数、および消費されるメモリー量の間で異なるトレードオフが存在します。この表を使用すると、アプリケーションに最適なデータの種類とデータ解像度で、最も効果的に機能する形式を選択するのに役立ちます。
| ソース データ | データ圧縮解像度 (ビット) | この圧縮形式を選択します |
|---|---|---|
| 成分が 3 つの色およびアルファ | カラー (5:6:5)、アルファ (1) またはアルファなし | BC1 |
| 成分が 3 つの色およびアルファ | カラー (5:6:5)、アルファ (4) | BC2 |
| 成分が 3 つの色およびアルファ | カラー (5:6:5)、アルファ (8) | BC3 |
| 成分が 1 つの色 | 1 つの成分 (8) | BC4 |
| 成分が 2 つの色 | 2 つの成分 (8:8) | BC5 |
BC1
5:6:5 の色 (赤が 5 ビット、緑が 6 ビット、青が 5 ビット) を使用する 3 つの成分のカラー データを保存するには、最初のブロック圧縮形式 (BC1) (DXGI_FORMAT_BC1_TYPELESS、DXGI_FORMAT_BC1_UNORM、または DXGI_BC1_UNORM_SRGB のいずれか) を使用します。データに 1 ビットのアルファが含まれている場合も、これが当てはまります。4×4 のテクスチャーが、可能な限り最も大きなデータ形式を使用することを想定すると、BC1 形式では必要なメモリーが 48 バイト (16 色 × 3 成分/色 × 1 バイト/成分) から 8 バイトに減少します。
このアルゴリズムは、4×4 ブロックのテクセルで機能します。16 色を保存する代わりに、このアルゴリズムでは、2 つの参照カラー (color_0 および color_1) と 16 個の 2 ビット カラー インデックス (a ～ p のブロック) を保存します。
図形 3. BC1 の圧縮レイアウト
.gif "Ee415727.d3d10_compression_bc1(ja-jp,VS.85).gif")
カラー インデックス (a ～ p) は、カラー テーブルから元の色を検索するために使用します。カラー テーブルには 4 つの色が含まれます。最初の 2 色、color_0 および color_1 は、最小および最大の色です。その他の 2 色、color_2 および color_3 は、線形補間で計算された中間色です。
color_2 = 2/3*color_0 + 1/3*color_1 color_3 = 1/3*color_0 + 2/3*color_1
4 つの色には、a ～ p のブロックに保存される 2 ビットのインデックス値を割り当てます。
color_0 = 00 color_1 = 01 color_2 = 10 color_3 = 11
最後に、a ～ p のブロックの各色がカラー テーブルの 4 つの色と比較され、最も近い色のインデックスが 2 ビット ブロックに保存されます。
このアルゴリズムは、1 ビットのアルファが含まれているデータにも適しています。違いは、color_3 が 0 (透明色を表します) に設定されることと、color_2 が color_0 と color_1 の線形ブレンドであることのみです。
color_2 = 1/2*color_0 + 1/2*color_1; color_3 = 0;
Direct3D 9 と Direct3D 10 の違い この形式は、Direct3D 9 と 10 の両方に存在します。
|
BC2
整合性が低いカラー データおよびアルファ データが含まれているデータを保存するには、BC2 形式 (DXGI_FORMAT_BC2_TYPELESS、DXGI_FORMAT_BC2_UNORM、または DXGI_BC2_UNORM_SRGB のいずれか) を使用します (整合性が高いアルファ データには BC3 を使用します)。BC2 形式は、RGB データを 5:6:5 の色 (赤が 5 ビット、緑が 6 ビット、青が 5 ビット) で、アルファを独立した 4 ビットの値で保存します。4×4 のテクスチャーが、可能な限り最も大きなデータ形式を使用すると想定すると、この圧縮方法では必要なメモリーが 64 バイト (16 色 × 4 成分/色 × 1 バイト/成分) から 16 バイトに減少します。
BC2 形式では、BC1 形式と同じビット数およびデータ レイアウトで色を保存しますが、BC2 ではアルファ データを保存するためにさらに 64 ビットのメモリーが必要です。
図形 4. BC2 の圧縮レイアウト
.gif "Ee415727.d3d10_compression_bc2(ja-jp,VS.85).gif")
Direct3D 9 と Direct3D 10 の違い この形式は、Direct3D 9 と 10 の両方に存在します。
|
BC3
整合性の高いカラー データを保存するには、BC3 形式 (DXGI_FORMAT_BC3_TYPELESS、DXGI_FORMAT_BC3_UNORM、または DXGI_BC3_UNORM_SRGB のいずれか) を使用します (整合性の低いアルファ データには BC2 を使用します)。BC3 形式では、5:6:5 の色 (赤が 5 ビット、緑が 6 ビット、青が 5 ビット) を使用してカラー データを、1 バイトを使用してアルファ データを保存します。4×4 のテクスチャーが、可能な限り最も大きなデータ形式を使用すると想定すると、この圧縮方法では必要なメモリーが 64 バイト (16 色 × 4 成分/色 × 1 バイト/成分) から 16 バイトに減少します。
BC3 形式では、BC1 形式と同じビット数およびデータ レイアウトで色を保存しますが、BC3 ではアルファ データを保存するためにさらに 64 ビットのメモリーが必要です。BC3 形式では、2 つの参照値を保存し、その 2 つの間を補間することによってアルファを処理します (BC1 で RGB カラーを保存する方法と類似しています)。
このアルゴリズムは、4×4 ブロックのテクセルで機能します。16 個のアルファ値を保存する代わりに、このアルゴリズムでは、2 つの参照アルファ (alpha_0 および alpha_1) と 16 個の 3 ビット カラー インデックス (a ～ p のアルファ) を保存します。
図形 5. BC3 の圧縮レイアウト
.gif "Ee415727.d3d10_compression_bc3(ja-jp,VS.85).gif")
BC3 形式では、アルファ インデックス (a ～ p) を使用して、8 つの値が含まれるルックアップ テーブルから元の色を検索します。最初の 2 つの値である alpha_0 および alpha_1 は、最小値と最大値です。その他の 6 つの中間値は、線形補間を使用して計算されます。
このアルゴリズムでは、2 つの参照アルファ値を調べることで、補間アルファ値の数を決定します。alpha_0 が alpha_1 より大きい場合、BC3 では 6 つのアルファ値を補間します。それ以外の場合は、4 つの値を補間します。BC3 でアルファ値を 4 つのみ補間するときは、追加のアルファ値を 2 つ (0 は完全に透明、255 は完全に不透明) 設定します。BC3 では、指定されたテクセルの元のアルファに最も近い補間アルファ値に対応するビット コードを保存することにより、4×4 のテクセル領域にアルファ値を圧縮します。
if( alpha_0 > alpha_1 ) { // 6 interpolated alpha values. alpha_2 = 6/7*alpha_0 + 1/7*alpha_1; // bit code 010 alpha_3 = 5/7*alpha_0 + 2/7*alpha_1; // bit code 011 alpha_4 = 4/7*alpha_0 + 3/7*alpha_1; // bit code 100 alpha_5 = 3/7*alpha_0 + 4/7*alpha_1; // bit code 101 alpha_6 = 2/7*alpha_0 + 5/7*alpha_1; // bit code 110 alpha_7 = 1/7*alpha_0 + 6/7*alpha_1; // bit code 111 } else { // 4 interpolated alpha values. alpha_2 = 4/5*alpha_0 + 1/5*alpha_1; // bit code 010 alpha_3 = 3/5*alpha_0 + 2/5*alpha_1; // bit code 011 alpha_4 = 2/5*alpha_0 + 3/5*alpha_1; // bit code 100 alpha_5 = 1/5*alpha_0 + 4/5*alpha_1; // bit code 101 alpha_6 = 0; // bit code 110 alpha_7 = 255; // bit code 111 }
Direct3D 9 と Direct3D 10 の違い
|
BC4
成分が 1 つのカラー データを、各色に 8 ビット使用して保存するには、BC4 形式を使用します。精度が向上する結果 (BC1 との比較)、[0 ～ 1] の範囲では DXGI_FORMAT_BC4_UNORM 形式を使用し、[-1 ～ +1] の範囲では DXGI_FORMAT_BC4_SNORM 形式を使用して、浮動小数点データを保存する場合に BC4 は最適です。4×4 のテクスチャーが、可能な限り最も大きなデータ形式を使用すると想定すると、この圧縮方法では必要なメモリーが 16 バイト (16 色 × 1 成分/色 × 1 バイト/成分) から 8 バイトに減少します。
このアルゴリズムは、4×4 ブロックのテクセルで機能します。16 色を保存する代わりに、このアルゴリズムでは、2 つの参照カラー (red_0 および red_1) と 16 個の 3 ビット カラー インデックス (red a ～ red p および green a ～ green p) を保存します。
図形 6. BC4 の圧縮レイアウト
.gif "Ee415727.d3d10_compression_bc4(ja-jp,VS.85).gif")
このアルゴリズムでは、3 ビットのインデックスを使用して、8 色が含まれるカラー テーブルから色を検索します。最初の 2 色、color_0 および color_1 は、最小および最大の色です。このアルゴリズムでは、線形補間を使用して残りの色を計算します。
このアルゴリズムでは、2 つの参照値を調べることで、補間されるカラー値の数を決定します。red_0 が red_1 より大きい場合、BC4 では 6 つのカラー値を補間します。それ以外の場合は、4 つの値を補間します。BC4 でカラー値を 4 つのみ補間するときは、追加のカラー値を 2 つ (0.0f は完全に透明、1.0f は完全に不透明) 設定します。BC4 では、指定されたテクセルの元のアルファに最も近い補間アルファ値に対応するビット コードを保存することにより、4×4 のテクセル領域にアルファ値を圧縮します。
- BC4_UNORM
- BC4_SNORM
BC4_UNORM
単一成分データの補間は、以下のコード サンプルのように行われます。
unsigned word red_0, red_1; if( red_0 > red_1 ) { // 6 interpolated color values red_2 = (6*red_0 + 1*red_1)/7.0f; // bit code 010 red_3 = (5*red_0 + 2*red_1)/7.0f; // bit code 011 red_4 = (4*red_0 + 3*red_1)/7.0f; // bit code 100 red_5 = (3*red_0 + 4*red_1)/7.0f; // bit code 101 red_6 = (2*red_0 + 5*red_1)/7.0f; // bit code 110 red_7 = (1*red_0 + 6*red_1)/7.0f; // bit code 111 } else { // 4 interpolated color values red_2 = (4*red_0 + 1*red_1)/5.0f; // bit code 010 red_3 = (3*red_0 + 2*red_1)/5.0f; // bit code 011 red_4 = (2*red_0 + 3*red_1)/5.0f; // bit code 100 red_5 = (1*red_0 + 4*red_1)/5.0f; // bit code 101 red_6 = 0.0f; // bit code 110 red_7 = 1.0f; // bit code 111 }
参照カラーには 3 ビットのインデックス (8 つの値があるので 000 ～ 111) が割り当てられます。このインデックスは、圧縮時に red a ～ red p のブロックに保存されます。
BC4_SNORM
DXGI_FORMAT_BC4_SNORM は、SNORM 範囲でデータがエンコードされることと、4 つのカラー値が補間される場合を除いて、まったく同じです。単一成分データの補間は、以下のコード サンプルのように行われます。
signed word red_0, red_1; if( red_0 > red_1 ) { // 6 interpolated color values red_2 = (6*red_0 + 1*red_1)/7.0f; // bit code 010 red_3 = (5*red_0 + 2*red_1)/7.0f; // bit code 011 red_4 = (4*red_0 + 3*red_1)/7.0f; // bit code 100 red_5 = (3*red_0 + 4*red_1)/7.0f; // bit code 101 red_6 = (2*red_0 + 5*red_1)/7.0f; // bit code 110 red_7 = (1*red_0 + 6*red_1)/7.0f; // bit code 111 } else { // 4 interpolated color values red_2 = (4*red_0 + 1*red_1)/5.0f; // bit code 010 red_3 = (3*red_0 + 2*red_1)/5.0f; // bit code 011 red_4 = (2*red_0 + 3*red_1)/5.0f; // bit code 100 red_5 = (1*red_0 + 4*red_1)/5.0f; // bit code 101 red_6 = -1.0f; // bit code 110 red_7 = 1.0f; // bit code 111 }
参照カラーには 3 ビットのインデックス (8 つの値があるので 000 ～ 111) が割り当てられます。このインデックスは、圧縮時に red a ～ red p のブロックに保存されます。
BC5
成分が 2 つのカラー データを、各色に 8 ビット使用して保存するには、BC5 形式を使用します。精度が向上する結果 (BC1 との比較)、[0 ～ 1] の範囲では DXGI_FORMAT_BC5_UNORM 形式を使用し、[-1 ～ +1] の範囲では DXGI_FORMAT_BC5_SNORM 形式を使用して、浮動小数点データを保存する場合に BC5 は最適です。4×4 のテクスチャーが、可能な限り最も大きなデータ形式を使用すると想定すると、この圧縮方法では必要なメモリーが 32 バイト (16 色 × 2 成分/色 × 1 バイト/成分) から 16 バイトに減少します。
このアルゴリズムは、4×4 ブロックのテクセルで機能します。2 つの成分でそれぞれ 16 色を保存する代わりに、このアルゴリズムでは各成分で 2 つの参照カラー (red_0、red_1、green_0、および green_1) と、各成分で 16 個の 3 ビット カラー インデックス (red a ～ red p および green a ～ green p) を保存します。
図形 7. BC5 の圧縮レイアウト
.gif "Ee415727.d3d10_compression_bc5(ja-jp,VS.85).gif")
このアルゴリズムでは、3 ビットのインデックスを使用して、8 色が含まれるカラー テーブルから色を検索します。最初の 2 色、red_0 および red_1 (または green_0 および green_1) は、最小および最大の色です。このアルゴリズムでは、線形補間を使用して残りの色を計算します。
このアルゴリズムでは、2 つの参照値を調べることで、補間されるカラー値の数を決定します。red_0 が red_1 より大きい場合、BC5 では 6 つのカラー値を補間します。それ以外の場合は、4 つの値を補間します。BC5 でカラー値を 4 つのみ補間するときは、残りの 2 つのカラー値を 0.0f と 1.0f に設定します。
- BC5_UNORM
- BC5_SNORM
BC5_UNORM
単一成分データの補間は、以下のコード サンプルのように行われます。green の成分の計算も同様です。
unsigned word red_0, red_1; if( red_0 > red_1 ) { // 6 interpolated color values red_2 = (6*red_0 + 1*red_1)/7.0f; // bit code 010 red_3 = (5*red_0 + 2*red_1)/7.0f; // bit code 011 red_4 = (4*red_0 + 3*red_1)/7.0f; // bit code 100 red_5 = (3*red_0 + 4*red_1)/7.0f; // bit code 101 red_6 = (2*red_0 + 5*red_1)/7.0f; // bit code 110 red_7 = (1*red_0 + 6*red_1)/7.0f; // bit code 111 } else { // 4 interpolated color values red_2 = (4*red_0 + 1*red_1)/5.0f; // bit code 010 red_3 = (3*red_0 + 2*red_1)/5.0f; // bit code 011 red_4 = (2*red_0 + 3*red_1)/5.0f; // bit code 100 red_5 = (1*red_0 + 4*red_1)/5.0f; // bit code 101 red_6 = 0.0f; // bit code 110 red_7 = 1.0f; // bit code 111 }
参照カラーには 3 ビットのインデックス (8 つの値があるので 000 ～ 111) が割り当てられます。このインデックスは、圧縮時に red a ～ red p のブロックに保存されます。
BC5_SNORM
DXGI_FORMAT_BC5_SNORM は、SNORM 範囲でデータがエンコードされることと、4 つのデータ値が補間され、-1.0f と 1.0f の 2 つの値が追加される場合を除いて、まったく同じです。単一成分データの補間は、以下のコード サンプルのように行われます。green の成分の計算も同様です。
signed word red_0, red_1; if( red_0 > red_1 ) { // 6 interpolated color values red_2 = (6*red_0 + 1*red_1)/7.0f; // bit code 010 red_3 = (5*red_0 + 2*red_1)/7.0f; // bit code 011 red_4 = (4*red_0 + 3*red_1)/7.0f; // bit code 100 red_5 = (3*red_0 + 4*red_1)/7.0f; // bit code 101 red_6 = (2*red_0 + 5*red_1)/7.0f; // bit code 110 red_7 = (1*red_0 + 6*red_1)/7.0f; // bit code 111 } else { // 4 interpolated color values red_2 = (4*red_0 + 1*red_1)/5.0f; // bit code 010 red_3 = (3*red_0 + 2*red_1)/5.0f; // bit code 011 red_4 = (2*red_0 + 3*red_1)/5.0f; // bit code 100 red_5 = (1*red_0 + 4*red_1)/5.0f; // bit code 101 red_6 = -1.0f; // bit code 110 red_7 = 1.0f; // bit code 111 }
参照カラーには 3 ビットのインデックス (8 つの値があるので 000 ～ 111) が割り当てられます。このインデックスは、圧縮時に red a ～ red p のブロックに保存されます。
Direct3D 10.1 を使用したフォーマット変換
Direct3D 10.1 を使用すると、ビット幅が同じであれば、事前に構造化されたタイプのテクスチャーとブロック圧縮されたテクスチャーとの間のコピーが可能になります。これを実現できる関数は、ID3D10Device::CopyResource と ID3D10Device::CopySubresourceRegion です。パフォーマンスへの影響は、データのコピーでのみ発生し、データの変換自体はパフォーマンスに影響しません。
次の表は、使用可能なコピー元とコピー先の形式を一覧にしたものです。
| ビット幅 | 圧縮されていないリソース | ブロック圧縮されたリソース |
|---|---|---|
| 32 | DXGI_FORMAT_R32_UINT DXGI_FORMAT_R32_UINT |
DXGI_FORMAT_R9G9B9E5_SHAREDEXP |
| 64 | DXGI_FORMAT_R16G16B16A16_UINT DXGI_FORMAT_R16G16B16A16_SINT DXGI_FORMAT_R32G32_UINT DXGI_FORMAT_R32G32_SINT |
DXGI_FORMAT_BC1_UNORM[_SRGB] DXGI_FORMAT_BC4_UNORM DXGI_FORMAT_BC4_SNORM |
| 128 | DXGI_FORMAT_R32G32B32A32_UINT DXGI_FORMAT_R32G32B32A32_SINT |
DXGI_FORMAT_BC2_UNORM[_SRGB] DXGI_FORMAT_BC3_UNORM[_SRGB] DXGI_FORMAT_BC5_UNORM DXGI_FORMAT_BC5_SNORM |