問題タブ [compute-shader]

被写界深度を計算するための次の計算シェーダー コードがあります。ただし、非常にまれに、g_rayCount が 10 であっても、ループは 1 回だけ実行されます。 for ループがあるメイン関数 raycastercs を見てください。

OpenGL 4.3 を使用して、シェーダー バッファー ブロックをバインドする方法を知りたいですglShaderStorageBinding。

「バインディング」修飾子は正常に機能しますが、使用したくありません。

私は次のコードを書きました：

計算シェーダー:

結果は 1 であると予想されますが、Obuffer では値が 0 として返されます。

私は最近、計算シェーダーで遊んでいて、[numthreads(x,y,z)] をセットアップして呼び出しをディスパッチするための最適な方法を決定しようとしています。私のデモ ウィンドウは 800x600 で、ピクセルごとに 1 つのスレッドを起動しています。2D テクスチャの修正を行っています - 重すぎることはありません。

私の最初の試みは指定することでした

私の Dispatch() 呼び出しは常に

したがって、最初のインスタンスは

これは 25 ～ 26 fps で実行されました。次に、16 fps で実行される [numthreads(4,4,1)] に減らしました。それを [numthreads(16,16,1)] に増やすと、約 30 fps の優れた結果が得られ始めました。Y スレッド グループ番号 [numthreads(16,8,1)] をいじって、なんとか 32 fps に押し上げました。

私の質問は、GPU を最も効果的に利用できるようにスレッド数を決定する最適な方法はありますか、それとも古き良き試行錯誤ですか?

詳細に入る前に、問題の概要を説明します。

RWStructuredBuffers を使用して、計算シェーダー (CS) の出力を格納します。頂点シェーダーとピクセル シェーダーは RWStructuredBuffers から読み取ることができないため、StructuredBuffer を同じスロット (u0/t0) と (u4/t4) にマップします。

ShaderRecourceView を使用して、ピクセルおよび/または頂点シェーダーにバッファーへのアクセスを許可します。この概念は私のピクセル シェーダーではうまく機能しますが、頂点シェーダーは 0 値しか読み取らないようです (バッファーへのインデックスとして SV_VertexID を使用します)。

hlsl コンパイラからのエラー メッセージや警告はなく、renderloop は (vsync を使用して) 60 fps で実行されますが、画面は黒いままです。Draw(..) が呼び出される前に Color.White で画面を空白にしているため、レンダリング パイプラインがアクティブになっているようです。

GPU から UAView を介して三角形のデータ コンテンツを「vertArray」に読み込み、それを頂点バッファーにフィードバックすると、すべてが機能します。

プログラム：

HLSL:

ここで 2D の定義 - 頂点 / ピクセルシェーダー。PS_2D はスロット t0 のバッファー「output2」にアクセスすることに注意してください。これはまさに、3D 頂点シェーダー「VS_3DA」で複製したい「トリック」です。

3日間、私は検索して実験しましたが、役に立ちませんでした. 私が収集したすべての情報は、SV_VertexID を使用した私のアプローチが機能することを確認しているようです。

誰でもアドバイスできますか？私の投稿を読んでくれてありがとう！

================================================== ===================

詳細：

私は DirectX 11 コンピューティング シェーダーのコンセプトがとても好きで、代数計算に採用したいと考えています。テスト ケースとして、フラクタル (マンデルブロ集合) を 3D でレンダリングします。壁の最後のレンガが 1 つ欠けていることを除いて、すべてが期待どおりに機能します。

計算には次の手順が必要です。

1. CS を使用して 2D テクスチャを計算する (出力は「counterTable」と「colorOutbutTable」です (動作)

2. 必要に応じて、このテクスチャを画面にレンダリングします (動作)

3. 別の CS を使用してメッシュ (三角形のリスト) を生成します。この CS は、ステップ 1 から x、y、および色の値を取得し、z 座標を計算して、最後に各ピクセルのクワッドを作成します。結果は「頂点テーブル」に格納されます。（作品）

4. 三角形のリストを頂点シェーダーにフィードする (問題!!!)

5. 画面にレンダリングします (動作 - 頂点バッファーを使用)。

プログラミングには、F# 3.0 と SharpDX を .NET ラッパーとして使用します。両方のシェーダー (ピクセルと頂点) の ShaderRessourceView は、同じパラメーター (サイズ パラメーターを除く) で設定されます。

ここでは特別なことは何もありません。2D バッファの作成 (スロット t0 のバッファ「output2」にバインド):

3D バッファの作成 (スロット t4 の「vertexTable2」にバインド):

2D のリソースの設定:

2D をレンダリング:

3D のリソースの設定:

3D をレンダリングします (機能しません – 出力結果として黒い画面が表示されます)

最後にスロット番号:

==================== 編集: 解決策 =====================

私はついに問題を発見しました.答えはDirectXを学んでいる初心者にとって重要かもしれないので、ここに投稿します. (私は DirectX への .NET ラッパーとして F# と SharpDX を使用しています)

私のプログラムでは、リソース (バッファー、ビューなど) は、スワップ チェーンのサイズが変更されたときにのみ変更されます。したがって、すべてのリソース割り当て (IA、OM、VS、PS) を function に入れますswitchTo2DLayout。スワップ チェーンのサイズが変更されていないswitchTo2DLayout場合は、(何もせずに) すぐに戻ります。これはフラグによって制御されます。

後で、このフラグがリセットされないことがわかったので、すべての描画呼び出しの前にリソース割り当てが行われました。この間違いを修正しましたが、画像は への最初の呼び出しでのみレンダリングされましたrenderPixels。ドローコールの前にShaderresourceView 毎回設定する必要があることがわかりました。

これは私にとってまったく予想外でした。私が使用する DirectX に関する書籍では、(設定が変更されない限り) 1 回割り当てられるリソースと、描画呼び出しごとに割り当てられる必要があるリソースについて明示的に述べていません。

メッシュ レンダリングでは、同様の設定を使用します (ここでは前述のバグはありません)。また、同等の行がありませんでした。

これは、2D レンダリングがバグ (ピクセル シェーダーがバッファーから読み取る) のために機能し、3D レンダリングが機能しなかった (頂点シェーダーがバッファーから読み取る) 理由を説明しています。

======================= 私の元の投稿: =================

数日前に問題を投稿しました [リンク:]頂点バッファーを使用せずに計算シェーダーの結果を頂点シェーダーにフィードするにはどうすればよいですか? それはおそらく複雑すぎて答えられませんでした。その間、セットアップをより単純なケースに落とし込みました。

ケース A: ピクセル シェーダーが色を設定する (機能する)

ケース B: 頂点シェーダーが色を設定する (機能しない)

明らかに、ピクセル シェーダーは "output2" バッファーにアクセスできますが、頂点シェーダーはアクセスできません(読み取りは常にゼロ)。

インターネットを検索しても、この動作の説明は見つかりませんでした。私の「実際の」アプリケーションでは、計算シェーダーが三角形のリストを計算し、それを RWStructuredBuffer に格納するため、頂点シェーダーから (マップされたスロットを介して) このテーブルにアクセスする必要があります。

コンピューティング シェーダーを使用する多くの人が、この問題に遭遇する可能性があると思います。これを解決する方法はありますか？(現在、レベル 11.1 または 11.2 を使用できません。11.0 に基づく解決策を見つける必要があります)

ストリーム出力を使用する頂点シェーダーではなく、計算シェーダーを使用してボーン変形をメッシュ頂点に適用することを検討しています。コンピューティング シェーダーの実行が頂点シェーダーよりもはるかに遅いことがわかりましたが、書き留める前に、何か間違ったことをしていないことを確認したいと思います。

100,000 個の頂点と 300 個のボーンの 1,000 フレームのアニメーション データのテスト データを使用すると、頂点シェーダーは約 0.22 ミリ秒で実行され、計算シェーダーは 4 倍の 0.85 ミリ秒かかります。タイミングは、(CPU タイマーではなく) D3D API タイマー クエリを介して行われます。

変形構造体.hlsl

bone_deform_cs.hlsl

bone_deform_vs.hlsl

実行後のバッファの内容を比較すると、それらは同一であり、期待される値が含まれています。

計算シェーダーを間違って実行し、スレッドを生成しすぎているのではないでしょうか? 渡す番号がDispatch間違っていますか？これは 1 次元のデータ行であるため、 を使用するのが理にかなっています[numthreads(64,1,1)]。32 ～ 1024 のさまざまな値を試しました。64 は、AMD GPU を効率的に使用するために必要な最小値であるため、スイート スポットのようです。ともかく。を呼び出すとDispatch、実行するように要求し(vertex_count / 64) + (vertex_count % 64 != 0) ? 1 : 0ます。100,000 個の頂点の場合、呼び出しは になりDispatch(1563,1,1)ます。

これが頂点シェーダーの実行方法です。

それとも、シェーダー リソース ビューからの読み取りと順序付けされていないアクセス ビューへの書き込みは、頂点バッファーからの読み取りとストリーム出力バッファーへの書き込みよりもはるかに遅いというだけでしょうか?

頂点定義と同等の構造体を使用して、UAV を RWStructuredBuffer として扱う計算シェーダーを使用して頂点を埋めるために使用している、順序付けられていないアクセス ビューを持つ頂点バッファーがあります。216000 個の頂点があります (つまり、60 x 60 x 60)。しかし、私の計算シェーダーはそれらのうち約 8000 しか満たしていないようで、残りは初期値のままです。この方法で書き込むことができる構造化バッファ内の要素数に制限はありますか?

すべての DirectX の書籍とチュートリアルでは、ドローコール間のリソース割り当てを最小限に抑えることを強く推奨していますが、詳細を説明したガイドラインは見つかりません。Web で見つかった多くのサンプル コードを検討した結果、プログラマーはこの主題に関してまったく異なるコーディング原則を持っているという結論に達しました。一部の設定および設定解除

すべての描画呼び出しの前後(セットアップは変更されていませんが) であり、他のものはそうではありません。

ちょっとやり過ぎかな…。

私自身の実験から、すべての描画呼び出しでバインドする必要があるリソースはShaderResourceViews(私の場合は toVSとPS) だけであることがわかりました。この要件は、後で/にバインドUAVsされているバッファーにバインド/バインド解除するため、計算シェーダーの使用が原因である可能性があります。VSPS

この再バインドが必要であることに気付く前に、私は何時間もの作業を失いました。そして、多くのコーダーも確信が持てず、同様の罠に陥るよりも、「少し多すぎる」ものをアンバインドして再バインドすることを好むと思います。

質問 1:この問題に関して少なくともいくつかの経験則はありますか?

質問 2: CS ディスパッチ呼び出しの前に同じバッファーにバインドしているため (自分自身をバインド解除していない)、バインドShaderResourceViews先VS/PSがドライバー/DirectX コアによってバインド解除される可能性はありますか?UAVsSRVs

質問 3:VS/PS計算シェーダーを使用する前に、null に設定すらしていません。問題なく動作しますが、このような「怠惰な」アプローチを使用して次のトラップを掘っているのかどうか、常に確信が持てません。

BF3 に使用される DICE に合わせて遅延タイル レンダラーを作成しようとしていますが、自分が何をしているのか理解していないか、GLSL が高速なレンダラーを引っ張っています。

カーネルの最初の部分は、タイルごとの最大深度と最小深度を計算することです。これは、このコードで行っています。

断片ごとに奥行きを描くとこんな感じ。

minDepth を描画しようとすると真っ白な画面になり、maxDepth を描画すると黒い画面が生成されます。メモリ管理/アトミック関数が間違っていますか、それともドライバー/GPU/ユニコーンが壊れていますか?

参考までに、試してみました

また、完全に白い画像が生成されるため、実際に何が起こっているのか非常に疑わしくなります.