次の方法で共有

タイルリソーステクスチャサンプリング機能

  • [アーティクル]

このセクションでは、タイルリソーステクスチャサンプリング機能について説明します。

タイルリソーステクスチャサンプリング機能の要件

ここで説明するテクスチャ サンプリング機能では、 階層 2 レベルのタイル リソースのサポートが必要です。

マップされた領域に関するシェーダー フィードバック

タイル リソースに対して読み取りまたは書き込みを行うシェーダー命令では、状態情報が記録されます。 この状態は、リソース アクセス命令が発生するたびに、省略可能な追加の戻り値として公開され、32 ビットの一時レジスタに保存されます。 この戻り値の内容は "不透明" です。 つまり、シェーダー プログラムによる直接の読み取りは認められていません。 ただし、CheckAccessFullyMapped 関数を使用して、状態情報を抽出できます。

完全なマップのチェック

CheckAccessFullyMapped 関数は、メモリ アクセスから返された状態を解釈し、アクセスされるすべてのデータがリソースにマップされていたかどうかを示します。 CheckAccessFullyMapped は、データがマップされている場合は true (0xFFFFFFFF) を、マップされていない場合は false (0x00000000) を返します。

フィルター操作中に、特定のテクセルの重み付けが 0.0 になることがあります。 例としては、テクセルの中央に直接置かれるテクスチャ座標を持つリニア サンプルです。3 つのその他のテクセル (どれが該当するかは、ハードウェアによって決まります) は、フィルターでは考慮されますが、重みは 0 です。 このような重みが 0 であるテクセルはフィルター結果にはまったく影響しないため、このようなテクセルが偶然 NULL タイルに適用された場合、マップされていないアクセスとしてカウントされません。 複数の mip レベルを含むテクスチャ フィルターにも、同じことが言えます。ミップマップの 1 つに適用されたテクセルがマップされていなくて、そのようなテクセルの重みが 0 の場合、それらのテクセルはマップされていないアクセスとしてカウントされません。

4 つ未満のコンポーネント (DXGI_FORMAT_R8_UNORM など) を含む形式からサンプリングすると、 NULL タイルに含まれるテクセルは、シェーダーが実際に結果で見ているコンポーネントに関係なく 、NULL マップされたアクセスが報告されます。 たとえば、シェーダーで R8_UNORM から読み取りを行い、.gba/.yzw を使用して読み取り結果をマスクした場合、テクスチャの読み取りはまったく必要ないような結果になります。 ただし、テクセル アドレスが NULL マップ タイルの場合、操作はやはり NULL マップ アクセスとしてカウントされます。

シェーダーは状態を確認し、エラーが発生している場合は一連の対応策を実行できます。 たとえば、一連の対応策としては 'ミス' をログに記録すること (UAV 書き込みなど) であったり、より詳細度の低い、マップされていることがわかっている LOD にクランプした別の読み取りを発行することが該当します。 タイルのマップ済みセットのどの部分がアクセスされたかを把握するため、成功したアクセスもアプリケーションで追跡したい場合があります。

ログで 1 つ厄介なのは、アクセスされたと思われる一連のタイルを正確にレポートできるメカニズムが存在しないことです。 アプリケーションでは、アクセスに使用した座標を把握し、ハードウェア LOD 計算の内容を返す LOD 命令 ( tex2Dlod など) を使用して、保守的な推測を行うことができます。

また、同じタイルに対して大量のアクセスが発生するため、冗長なログも大量に発生し、メモリで競合が起きる可能性があります。 タイルのアクセスについて別の場所で既にレポートされている場合は、レポートを不要にするオプションがハードウェアに用意されると便利である可能性があります。 おそらく、そのような追跡の状態は、(おそらくフレーム境界において) API からリセットできるでしょう。

サンプルごとの MinLOD クランプ

マップされていないことがわかっている mipmapped タイル リソース内の領域をシェーダーが回避できるように、サンプラー (フィルター処理) を使用するほとんどのシェーダー命令には、シェーダーが追加の float32 MinLOD クランプ パラメーターをテクスチャ サンプルに渡す新しいモードがあります。 基盤のリソースと異なり、この値はビューのミップマップ番号のスペースに保持されます。

ハードウェアは、リソースごとの MinLOD クランプが発生する LOD 計算の同じ場所で max(fShaderMinLODClamp,fComputedLOD) を実行します。これは max() でもあります。

サンプラーに定義されているサンプルごとの LOD クランプとその他の LOD クランプを適用した結果、空のセットが返された場合、結果は、リソースごとの minLOD クランプの結果と同様に境界外アクセスになり、サーフェス形式内に存在するコンポーネントに対しては 0、欠落しているコンポーネントに対しては既定値が使用されます。

ここで説明するサンプルごとの minLOD クランプより前の LOD 命令 ( tex2Dlod など) は、クランプされた LOD と非クランプされた LOD の両方を返します。 この LOD 命令から返されたクランプありの LOD は、リソースごとのクランプも含め、すべてのクランプを反映しますが、サンプルごとのクランプは反映されません。 サンプルごとのクランプは、いずれにせよシェーダーによって制御および認識されているため、必要に応じて、シェーダーの作成者は手動でそのクランプを LOD 命令の戻り値に適用できます。

最小および最大除去フィルタリング

アプリケーションは、タイルリソースのマッピングがどのように表示されるのかを通知する独自のデータ構造を管理することを選択できます。 たとえば、タイル リソース内のすべてのタイルの情報を保持するテクセルを含むサーフェスがあります。 たとえば、任意のタイルの場所でマップされている最初の LOD を保存する必要があるとします。 タイル 化されたリソースのサンプリングを意図したのと同様の方法で、このデータ構造を慎重にサンプリングすることで、テクスチャ フィルターフットプリント全体に対して完全にマップされる最小 LOD が何であるかを発見する可能性があります。 このプロセスを簡単にするため、Direct3D 11.2 では、最小/最大フィルタリングという新しい汎用サンプラー モードが導入されています。

LOD 追跡用の最小/最大フィルタリングのユーティリティは、おそらく深度サーフェスのフィルタリングなど、他の用途にも便利であると思われます。

最小/最大フィルタリングは、通常のテクスチャ フィルターがフェッチするのと同じテクセルのセットをフェッチするサンプラーのモードです。 ただし、値をブレンドして回答を出すのではなく、コンポーネントごとに、フェッチされたテクセルの min() または max() を返します (たとえば、すべての G 値の min とは別に、すべての R 値の min を返すなど)。

最小/最大操作は、Direct3D の演算精度のルールに従います。 比較の順序は問題になりません。

最小/最大フィルタリングではないフィルター操作中に、特定のテクセルの重み付けが 0.0 になることがあります。 たとえば、テクスチャ座標がテクセルの中心に直接配置される線形サンプルです。他のテクセル (ハードウェアによって異なる場合がある) 3 個のテクセルがフィルターに寄与しますが、重みは 0 です。 最小/最大フィルター以外のフィルターで重みが 0 になるテクセルの場合、最小/最大のフィルターを使用しても、このようなテクセルは結果に影響を及ぼしません (重みも最小/最大操作に影響しません)。

フィルター モードの完全な一覧は、列挙値に MINIMUM と MAXIMUM を指定した D3D11_FILTER 列挙に表示されます。

この機能のサポートは、タイル化されたリソースに対する 階層 2 のサポートによって異なります。

タイル化されたリソースへのパイプライン アクセス