ストリーミング リソース テクスチャ サンプリングの機能は複数あります。たとえば、マップの領域についてシェーダー状態のフィードバックを取得する機能、アクセスされている全データがリソース内にマップされたかどうか確認する機能、マップされていないことがわかっているミップマップ ストリーミング リソース内の領域をシェーダーが避けられるようにクランプする機能、テクスチャ フィルターのフットプリント全体に完全にマップされる最小の LOD を検出する機能などがあります。
ストリーミング リソース テクスチャ サンプリング機能の要件
ここで説明するテクスチャ サンプリング機能には、 Tier 2 レベルのストリーミング リソースサポートが必要です。
マップされた領域に関するシェーダーの状態のフィードバック
ストリーミング リソースに対して読み取りまたは書き込みを行うシェーダー命令は、状態情報を記録します。 この状態は、32 ビットの一時レジスタに入るすべてのリソース アクセス命令で、省略可能な追加の戻り値として公開されます。 戻り値の内容は不透明です。 つまり、シェーダー プログラムによる直接読み取りは許可されません。 ただし、 CheckAccessFullyMapped 関数を使用して状態情報を抽出できます。
完全なマップのチェック
CheckAccessFullyMapped 関数は、メモリ アクセスから返された状態を解釈し、アクセスされているすべてのデータがリソースにマップされたかどうかを示します。 CheckAccessFullyMapped は、データがマップされた場合は true (0xFFFFFFFF) を返し、データがマップ解除された場合は false (0x00000000) を返します。
フィルター操作中に、特定のテクセルの重みが 0.0 になる場合があります。 たとえば、テクセルの中心に直接収まるテクスチャ座標を持つ線形サンプルです。他の 3 つのテクセル (ハードウェアによって異なる場合があります) は、フィルターの影響を受けますが、重みは 0 です。 これらの 0 個の重みテクセルはフィルターの結果にまったく影響しないため、 NULL タイルで発生した場合、マップされていないアクセスとしてカウントされません。 複数のミップ レベルを含むテクスチャ フィルターにも同じ保証が適用されることに注意してください。ミップマップの 1 つのテクセルがマップされていないが、それらのテクセルの重みが 0 の場合、それらのテクセルはマップされていないアクセスとしてカウントされません。
4 つ未満のコンポーネント (DXGI_FORMAT_R8_UNORM など) からサンプリングした場合、 NULL タイル上にあるテクセルは、シェーダーが実際に結果を見るコンポーネントに関係なく、 NULL マップされたアクセスが報告されます。 たとえば、シェーダーで R8_UNORM から読み取りを行い、.gba/.yzw を使用して読み取り結果をマスクした場合、テクスチャの読み取りはまったく必要ないような結果になります。 ただし、テクセル アドレスが NULL マップされたタイルの場合、操作は引き続き NULL マップ アクセスとしてカウントされます。
シェーダーは状態を確認し、障害発生時に必要なアクションのコースを追求できます。 たとえば、アクションのコースとして、"ミス" (UAV 書き込みなど) をログに記録したり、マップされていることがわかっている粗い LOD にクランプされた別の読み取りを発行したりできます。 アプリケーションでは、マップされたタイル セットのどの部分にアクセスしたかを把握するために、成功したアクセスを追跡することもできます。
ログ記録の複雑さの 1 つは、アクセスされたタイルの正確なセットを報告するためのメカニズムが存在しないということです。 アプリケーションは、アクセスに使用した座標を把握し、LOD 命令を使用して保守的な推測を行うことができます。たとえば、 tex2Dlod) はハードウェア LOD 計算を返します。
もう 1 つの複雑な問題は、多くのアクセスが同じタイルに対して行われるため、多くの冗長ログが発生し、メモリで競合が発生する可能性があるということです。 以前に他の場所で報告された場合にタイル アクセスを報告しないようにするオプションをハードウェアに提供できれば便利です。 このような追跡の状態は、(おそらくフレーム境界で) API からリセットされる可能性があります。
サンプルごとの MinLOD クランプ
マップされていないことがわかっている mipmapped ストリーミング リソース内の領域をシェーダーが回避できるように、サンプラー (フィルター処理) の使用を伴うほとんどのシェーダー命令には、シェーダーが追加の float32 MinLOD クランプ パラメーターをテクスチャ サンプルに渡すモードがあります。 この値は、基になるリソースではなく、ビューのミップマップの数値空間にあります。
ハードウェアはmax(fShaderMinLODClamp,fComputedLOD)リソースごとの MinLOD クランプが発生する LOD 計算と同じ場所で実行されます。これは、 max() でもあります。
サンプルごとの LOD クランプとサンプラーで定義されている他の LOD クランプを適用した結果が空のセットの場合、結果はリソースごとの minLOD クランプと同じ範囲外アクセス結果になります。サーフェス形式のコンポーネントの場合は 0、不足しているコンポーネントの場合は既定値になります。
ここで説明するサンプルごとの minLOD クランプより前の LOD 命令 (たとえば、 tex2Dlod) は、クランプされた LOD と非クランプされた LOD の両方を返します。 この LOD 命令から返されるクランプされた LOD は、リソースごとのクランプを含むすべてのクランプを反映しますが、サンプルごとのクランプは反映しません。 サンプルごとのクランプはシェーダーによって制御および認識されるため、シェーダー作成者は必要に応じて、そのクランプを LOD 命令の戻り値に手動で適用できます。
最小および最大除去フィルタリング
アプリケーションは、ストリーミング リソースに対するマッピングの外観を通知する独自のデータ構造を管理することを選択できます。 たとえば、ストリーミング リソース内のすべてのタイルの情報を保持するテクセルを含むサーフェスがあります。 特定のタイルの場所にマップされている最初の LOD を格納できます。 ストリーミング リソースがサンプリングされるのと同様の方法でこのデータ構造を慎重にサンプリングすることで、テクスチャ フィルターフットプリント全体に対して完全にマップされる最小 LOD が何であるかを発見する可能性があります。 このプロセスを容易にするために、Direct3D 11.2 では、新しい汎用サンプラー モードである最小/最大フィルタリングが導入されています。
LOD 追跡用の最小/最大フィルタリングのユーティリティは、深度サーフェスのフィルタリングなど、他の目的に役立つ場合があります。
最小/最大リダクション フィルタリングは、通常のテクスチャ フィルターがフェッチするのと同じテクセル セットをフェッチするサンプラーのモードです。 しかし、値をブレンドして回答を生成する代わりに、フェッチされたテクセルの min() または max() がコンポーネントごとに返されます (たとえば、すべての R 値の最小値は、すべての G 値の最小値とは別に返されます)。
最小/最大操作は、Direct3D 算術精度ルールに従います。 比較の順序は関係ありません。
最小/最大ではないフィルター操作中に、特定のテクセルの重みが 0.0 になる場合があります。 たとえば、テクセルの中心に直接収まるテクスチャ座標を持つ線形サンプルです。その場合、他の 3 つのテクセル (ハードウェアによって異なる場合があります) がフィルターに影響しますが、重みは 0 です。 これらのテクセルのうち、最小/最大以外のフィルターで重みが 0 になる場合、フィルターが min/max の場合、これらのテクセルは結果に影響しません (また、重みは min/max フィルター操作に影響しません)。
この機能のサポートは、 Tier 2 のストリーミング リソースのサポートによって異なります。
関連トピック