次の方法で共有

ハザード追跡対タイル プール リソース

  • [アーティクル]

非ストリーミング リソースの場合、Direct3D はレンダリング時に特定のハザード条件を防止できますが、ハザード追跡はストリーミング リソースのタイル レベルで行われるため、ストリーミング リソースのレンダリング時のハザード追跡にはかなりコストがかかる可能性があります。

たとえば、非ストリーミング リソースでは、ランタイムが特定の SubResource を同時に入力 (シェーダー リソース ビューなど) および出力 (レンダー ターゲット ビュー) としてバインドすることはできません。このようなケースが発生すると、ランタイムは入力をバインド解除します。 ランタイムでのこの追跡のオーバーヘッドはコストが安く、サブリソース レベルで実行されます。 この追跡オーバーヘッドの利点の 1 つは、アプリケーションが誤ってハードウェア シェーダーの実行順序に依存する可能性を最小限に抑えられることです。 ハードウェア シェーダーの実行順序は、特定のグラフィックス処理装置 (GPU) 上でなければ変化する可能性があり、異なる GPU では確実に異なります。

ストリーミング リソースの場合、リソースのバインド方法を追跡することは、タイル レベルでの追跡となるため、コストが高くなりすぎる可能性があります。 1 つのタイルがサーフェスの複数の領域に同時にマップされている場合、レンダー ターゲット ビューへのレンダリングの試行の検証など、新しい問題が発生します。 ランタイムでこのタイルごとのハザード追跡のコストが高すぎる場合、少なくともこれをデバッグ レイヤーでのオプションにすることをお勧めします。

アプリケーションは、タイル プール メモリを参照するストリーミング リソースに対する書き込みまたは読み取り操作を発行したときに、そのタイル プール メモリが、次に発生する読み取りまたは書き込み操作で別のストリーミング リソースによって参照される場合、後続の操作を開始する前に最初の操作が完了することを想定していることをディスプレイ ドライバーに通知する必要があります。

タイル プールにマッピングされます