2D描画

D3D11On12をやめて、自前で文字描画を作った。

次に必要になるのが線、矩形、円の描画。矩形と円については線バージョンと塗りつぶしバージョンを用意する。

塗りつぶし用シェーダ

どう描画するのがいいか？

思いつく方法は２つで、オーソドックスに頂点バッファとインデックスバッファを用意して、別途構造化バッファで形状や色を指定する方法。

もう1つは、構造化バッファのみで描画する方法。

文字描画は後者の方法で描画していて、前から２D描画の仕組みもこれで行こうと考えていた。

いざこの方法で描画しようとした場合、形別にシェーダ関数を用意してシェーダ内で振り分けるか、呼び出し側で振り分けてシェーダ自体を切り替える必要があると至った。

どちらもシェーダにとって重くなりそうな処理なので前者の方式で描画することにした。

形状を頂点バッファ、インデックスバッファで表現することにより、シェーダを同一にできる。通常の３Dモデル描画と同じだけど、こうすることによりこの後作る円や、もっと複雑な形状もモデルの準備で済む。

複数インスタンスを同時に描画する部分は構造化バッファに位置、スケール、色情報を含めて対応することにした。

通常３Dモデルの場合はWorldMatrixを複数用意して描画するけど、サイズが大きいのとそこまで複雑な指定をしないので、制限を掛けることでサイズを減らしてパフォーマンスを向上させる。

シェーダ側でWorldMatrixを作って、m[0][0]に幅の倍率、m[1][1]に高さの倍率、m[0][3]にX座標（移動量）、m[1][3]にY座標（移動量）を指定してからmul関数で変換する。

あと、深度バッファを有効にして、z座標を調整することで自動的にZオーダが処理されるようにした。手前ほど先に描画するようにして奥をスキップできるようにソートして構造化バッファに書き込むようにする。

矩形（塗りつぶしバージョン）

矩形のモデルを下記の4点で用意

-0.5,0.5(左上)

0.5,0.5(右上)

-0.5,-0.5(左下)

0.5,-0.5(右下)

円（塗りつぶしバージョン）

３Dモデルの場合はグローシェーディングでモデルがローポリでも球に見えるけど、２Dの場合輪郭だけなのでごまかせない。

分割数１６、３２、６４の輪郭＋中心の頂点バッファのデータを用意して、描画サイズにより違和感のないクオリティを選択して描画できるようにした。

線用シェーダ

線の描画自体あまりやったことがなかったけど、唯一やってたのが視錐台の描画でD3D12_PRIMITIVE_TOPOLOGY_TYPE_LINEを使っていた。

線の描画ではD3D_PRIMITIVE_TOPOLOGY_LINELISTとD3D_PRIMITIVE_TOPOLOGY_LINESTRIPの両方を対応できるシェーダを用意したいと考えた。

通常の線描画であれば頂点バッファを用意する必要もないので、構造化バッファのみで描画を行う方式を採用した。

D3D_PRIMITIVE_TOPOLOGY_LINELISTで描画する場合は、構造化バッファに始点、終点のセットで書き込みを行う。

D3D_PRIMITIVE_TOPOLOGY_LINESTRIPで描画する場合は、単純に構造化バッファに点情報を書き込む。ただし、他のデータをまた描きたい場合その前に描いた線と繋がってしまう。そこで、線と線の間に、アルファ０、Zオーダ０の2点（最後の線の終点と次の線の先頭と同じ座標）を追加することにした。こうすることで、D3D_PRIMITIVE_TOPOLOGY_LINESTRIPのデータもまとめて1コマンドで描画できるようになる。

線

線の場合、D3D_PRIMITIVE_TOPOLOGY_LINELISTで2点追加することで描画できる。

矩形

矩形の場合は、線のD3D_PRIMITIVE_TOPOLOGY_LINESTRIPに対して５点（左上、右上、右下、左下、左上）を指定する。

円

円の場合は、線のD3D_PRIMITIVE_TOPOLOGY_LINESTRIPに対してN点を指定する。

Nは３点以上で、cos、sinで座標を計算する。８点以上で円ぽくなる。

スプライト用シェーダ

矩形のテクスチャ貼り付けバージョンのシェーダを用意する。

データソースにリソースに登録されたテクスチャの他に、文字列描画で出力したテクスチャ、さらに今作ってる２D描画で出力したテクスチャも指定できるようにした。

スプライト描画

張り付ける位置の矩形、テクスチャを参照する矩形を指定する。

半透明の描画

不透明の描画の場合、Zオーダが手前を先に描画することで高速化を図る。

逆に透明の描画の場合は、Zオーダが奥のものから描画することで結果を正しく表現する。

またシェーダも切り替えて深度バッファ参照のみに変更して書き込みを止める。

同じシェーダ同士の描画順は制御しているが、塗りつぶし、線、スプライトの描画順は固定。

スプライト（不透明）、塗りつぶし（不透明）、線（不透明）、スプライト（透明）、塗りつぶし（透明）、線（透明）の順で描画する。

PIX GPUキャプチャ失敗

今までDirectXの描画でうまくいかない部分をPIXで確認して何度もヒントを貰って直せた。

ところが突然PIXのキャプチャに失敗するようになった。

直前に直したであろうソースを戻しても記憶が曖昧でうまくいかない。

それから２，３日キャプチャができない日が続いた。

ネットで調べると、サスペンド状態で実行してキャプチャすると成功するというのを見つけ、試してみるとたしかに成功した。

ただこれは狙ったタイミングではキャプチャできず、一番最初のみうまくいく。

その状態のまま開発を続けたが、どうしてもキャプチャしたい状態が出てきてちゃんと調査することにした。

ほとんどの動作をコメントにして、キャプチャできるかを試したら久しぶりに成功した。

この状態から徐々に処理を開放していき駄目になる部分を特定した。

最終的に原因の特定に成功。

キャプチャ失敗の原因

最終的に失敗していた箇所が中間レンダーターゲットをテクスチャにコピーする処理だった。

このコピー前後にバリアを張っていたが、外してもデバッグレイヤで怒られないので不要なことはしないようにコメントアウトしていた。

実はこれが原因でPIXのキャプチャ失敗するようになったようだ。

バリアを戻すと、PIXでキャプチャが成功する。

実際の動作には何の問題もないがPIXのために必要なのか、それともデバッグレイアのチェックが抜けていて実は必要な処理なのか？

PIXでキャプチャできないのは困るので、バリアのコメントを外して復活させることで解決した。

文字列を描画する仕組みをレンダリングエンジンに組み込む

文字列を描画する仕組みは作ったけど、レンダリングエンジンへの組み込みが中途半端になっていたので、きちんと組み込んでみた。

文字列の属性

最初はFPSなどを描画する為に毎フレーム更新する前提のものを用意していたけど、ラベルのように設定したら更新されないものにも対応したいと思っていた。

SetText（一時的なテキスト設定）

毎フレーム更新される前提で、Update内で毎回設定する。

前回のテキストはクリアされ設定しなければ描画されない。

SetLabel（ラベルテキスト設定）

毎フレームは変更されず、更新のあった場合だけ再描画する。

利用側は毎フレーム書き込んでもいいし、書き込まなくてもよい。

管理側でID別に文字列を管理し、関数が呼び出される度に値を比較し変更があった場合だけ描画する。

出力先の設定

今までレンダーターゲットにのみ書き込んでいた。

SetTextは直接レンダーターゲットに書き込み、毎フレーム必要な文字列を描画する。

SetLabelは中間レンダーターゲットをキャッシュに利用できるようにする。

専用の単一中間レンダーターゲットに対して書き込み、変更がなければそのまま維持される。（ダブルバッファで用意してないのは前回の書き込みを利用するため）

描画完了後、別途テクスチャにコピーする。実際の画面への描画はこのテクスチャを貼り付ける。

出力方法

SetTextの場合は、主にレンダーターゲットを想定しており全体がクリアされたところに描画する。

SetLabelの場合は、状況により全体クリアと部分クリアを切り替える。

　

部分クリア

最初に描画位置を設定して文字列を描画する。

この時の描画範囲を記憶しておく。

次回描画時に前回記憶してある範囲だけをクリアして、新しい文字を書き込む。

大量のラベルを貼り付けても、実際に描画するのは最初と書き換えたときのみ。書き換えた場合もその書き換えた文字列のみの描画だけで済む。

ただし制限として文字列同士が重なり合うような場合は強制的に全体を描画し直す必要がある。

全体クリア

前述の通り初回の書き込み時と、文字列が重なるような状況の場合は強制的に全体クリアを行う。文字列が重なる場合、各ラベルの描画範囲を確認して重なる対象のラベルだけ部分クリアも可能だけど、ライブラリ内では重くなるから行わない。

利用側が重ならないように使うか、重なる状況の場合は強制クリア、もしくはSetTextでの描画を選択してもらう。

ハマりポイント

ClearRenderTargetView

部分クリアはこの関数の引数に渡す複数の矩形で行っている。

動作させてみると落ちる。

設定した矩形の数が６１個で呼び出していた模様。

これを試しに１つに変更したら動いた。いままで０でしか動かしたことがなかった。

１０、２０、３０と増やしても動き、５０にしたらだめだった。

予想は３２個で、３１、３２、３３と試したら３３で落ちた。

制限についてネットで調べてみても出てこない。

似たようなので見つけたのはClearUnorderedAccessViewUint関数の指定できる矩形の数が127だったという記事。環境に依存するのか、DirectXの仕様として決まっているのかもわからない。とりあえず数が多い場合は３２ずつ処理するように修正した。

Text Services Framework (TSF)のつづき

以前TSFについて実装した。

TSFにまつわる文字入力と、それを表示する仕組みの部分にいくつかのバグが見つかり、ここ何日かで直していた。

バグその１

開発当初から気づいてはいたんだけど、放置していたバグ。

入力文字をテクスチャに展開していき用意していた領域全部を使ってしまった場合、先頭に戻って１行分をクリアして再利用するようにしている。

このとき、表示するデータの中に１行目のテクスチャを利用する文字が含まれていた場合表示されなくなってしまう。

この不具合の修正は、次に消えるであろう数行に表示データが含まれている場合は、最新部分に移してしまうようにすることで対処してみた。

実際に実装はしてみたがそのチェック処理が若干重めになるのと、実際に不具合が起きた際に起きる表示が１フレームだけ表示されない（もしくは別の文字で表示される）だけなので、あえて元のままにした。

バグその２

漢字変換を通さない文字入力(半角アルファベット入力など)をした直後に、漢字変換をしようと、文字入力をすると入力できないというもの。

状況によって、変換候補だけが表示されたり、更に文字入力すると表示されるようになったり、ならなかったりという現象が起こった。

現象はMicrosoftIMEで起きて、Google日本語入力では起きない。

幸い現象は１００％起こせて、いつでも検証出来たがなかなか原因がつかめなかった。

何回も試しているうちになんとなく原因はわかった。

通常はITextStoreACPの継承関数がコールバックとしてTextStore側から通知される形だけど、文字変換を通さない入力の場合、ロックを掛けて、カーソル位置や内部文字を変更してアンロックをして、TextStore側は変更内容を知らない状態。勝手にこっち側で内容を変更しただけなので、文字列が増えたことが伝わってない状態で文字列外のカーソル位置に入力しているように見えてるのではないかと推測した。

GetSelectionや、GetTextなどが呼ばれて内容が変わってるのはわかってるはずなんだけど、MicrosoftIMEはわからないらしい。

その線で調べてみた結果、ITextStoreACPSink::OnTextChangeを呼べばいいのではないかと言うことにたどり着いた。

試しに実装してみると正しく入力できるようになった。

他にもこちらだけで内容を変更している箇所がいくつかあったので通知を加え、ついでにカーソル位置が変わったらITextStoreACPSink::OnSelectionChangeも呼ぶようにしてみた。

バグその３

毎フレーム登録して描画するのは非効率なので、ラベルとしてID付きで登録できるようにして、更新がなければStructuredBufferの更新をしないようにした。また一部のラベルで更新があった場合でも他のラベルのバイナリを再作成不要なようにバイナリを保持するようにした。

試しに１００個のラベルを登録して毎フレームの登録がなくなりCPU使用率が下がって、GPU使用率だけが増えることを確認しようとしたところプログラムが落ちてしまった。

このデータ管理に自作ライブラリのHashMapを利用していたが、今まで発覚しなかったバグを見つけた。

調べてみるとHashMapの拡張時にデータの移行がうまく行っていなかった。

キャパシティの７５％以上になったタイミングでデータ拡張を行い今までのデータを新しく確保した領域に移す。

テンプレートに指定された型がstd::is_trivially_copyable_vがtrueなら要素をまとめてmemcpy、falseなら１要素毎にnewする仕組みに振り分けている。

moveで例外を飛ばさない(std::is_nothrow_move_constructible_v)という暗黙の条件もつけていた。この条件に合致しない型を指定した状態でmoveを行うと何もしないようにしていた。

今回指定した型がちょうどstd::is_nothrow_move_constructible_vでfalseを返しており、データ拡張時元データを引き継いでいない状態になっていた。

構造体にいくつかの型が含まれているが、自作ライブラリのすべてをstd::is_nothrow_move_constructible_vにしているつもりだったけど、そうでないものが含まれていた。

UTF-8用の文字列クラスがあり、バイナリクラス(vectorのunsigned char型)を継承して作っていた。バイナリクラスはstd::is_nothrow_move_constructible_vはtrueで問題ないが、これをテンプレートクラスで継承した型の場合、スーパクラス側の自身のmoveコンストラクタとmove operator=が表面に届いていないようで、別途定義する必要があった。

必要な定義を追加して、move時std::is_nothrow_move_constructible_vでない場合はassertを入れつつ、copyを呼び出すように修正。対応していない型のmoveに気づくようにするのと、最悪このままreleaseビルドした場合でも動くようにした。

バグその４

UTF-8型の文字列クラスにもう１つバグがあって、ICUの機能を組み込んで見た目の文字数を取得できるようにする際、BreakIteratorのキャッシュを用意していた。

一度書記素単位に分けた情報を作ったら、次回はそれを使い回す。

今自分で書いていてもすぐに起こるであろうバグそのままが起きていた。

登録されている文字の変化があった場合、キャッシュのクリアが必要だったがクリアしていなかったためバグその３を直したあとに文字化けするようになった。

内容が変化し得る箇所にクリア処理を追加した。

バグその５

「バグその３」を引き起こした機能の実装でバイナリをキャッシュに問題があった。

データの更新に合わせてキャッシュはクリアしている。

ただ「バグその１」で起こっていた、テクスチャが書き換わった際のフォローが抜けている。

テクスチャの書き換えが起こったら、すべてのキャッシュを削除するようにした。

本来は利用していたものだけキャッシュを削除すればスマートだが、厳密にチェックするとなると重くなる。「バグその１」で妥協したように処理済みデータに対してキャッシュを消してしまっても、表示されないのは１フレームのみなのでこちらも妥協することにした。

これも対応してみたはいいけど、テクスチャ書き換えの度に文字がフラッシュするので、キャッシュ消す必要もない。どうせフラッシュするならそのままにすることにより影響受けるとこだけに抑えられる。結局何もしないことにした。

「バグその１」はフラッシュしないところまで実装したけど、こっちの方は今のところフラッシュしない方法を思いついてない。

シェーダに符号付き８ビットデータを渡す

前回のステンシルバッファでテキストのクリッピングをやろうとしたけど、単純な矩形をステンシルバッファへ書き込む方法がまだわからないので方針を変えることにした。

ステンシルバッファをClearDepthStencilViewの最後の引数に複数渡せる矩形情報でクリッピング範囲を指定できたら良かったんだけど、クリアの値が作成時のクリア値以外で書き込むとパフォーマンスが落ちるらしいので諦めた。

テキストのクリッピング処理

テキストをレンダリングするシェーダに渡しているSRVに16ビットのオフセット情報を増やして、書き込む幅を調整できるように考えた。

今まで渡していた情報はすべてuint16_tで描画する位置のx, yと、フォントマスタのインデックスno、カラー番号cno。

このデータサイズが毎フレーム更新に影響を与えるために極力小さくするチューニングを行って現在の形になっている。データを増やすのはかなり抵抗があるが致し方ない。

int16_tでオフセットofsを追加した。

マイナスの場合は左から、プラスの場合は右からオフセット分描画しないようにする。

普通に２バイトのデータを書き込んでシェーダ側でint16_tとして解釈すればこれについてはなんの問題もなかった。

ただ、１文字内で左右どちらもクリッピングはできないという制限はあるがこれは許容した。

ここまで出来て、縦方向も欲しくなった。エディットボックス内の文字列描画で、枠以上の文字列入力が可能な場合にクリッピング処理が発生する想定で作っていたから、縦方向は仕様次第で不要な状況にできるかなと思っていたけど作ることにした。

符号付きの１６ビットの範囲は32767～-32768なので１文字に使う範囲としてはもったいない。これを符号付き８ビットにすると、127～-128なのでちょうど良い感じ。８ビットシフトして、上位８ビットに水平方向のオフセット、下位８ビットに垂直方向のオフセットを渡すようにした。

HLSL側でもシフトが普通に使えるので、水平方向のオフセットは右シフトで普通に取り出し、下位８ビットは「& 0x00FF」で上位８ビットを切り捨てた。

ところがこれだと渡した値が、プラスの場合は問題ないが、マイナスの場合正しく評価されない。

試してうまく行ったのは、一度左に８ビットシフトしてから、右に８ビットシフトする方法。上位８ビットについては右シフトで算術シフトできることはわかっていたので、下位８ビットも、最上位ビットにタッチさせて右シフトすれば行けるかと思ったら行けた。

他にもいろいろやり方はあるだろうけど、条件分岐一切なしにできたのでこれが良さそう。専用の関数（８ビット→１６ビット）があれば別だけど。

今回の対応はVertexBufferにしてやれば、オフセット情報は増やす必要なく、書き込む位置とUVの調整で済むし、１文字内で両端のクリッピングにも対応できるけど、どうなんだろ？

フォントのマスタが不要になる一方、１文字４点分のデータ書き込みが必要になるから微妙か。

Stencil Buffer

今回はステンシルバッファについて

フォーマット

深度バッファのみのときは、DXGI_FORMAT_D32_FLOATを使っていた。

ステンシルバッファを使う場合は、DXGI_FORMAT_D24_UNORM_S8_UINTを使う。

Dの部分が深度バッファの精度で、ステンシルバッファに８ビット使ってしまうため、２４に落ちる。

精度を落としたくなければDXGI_FORMAT_D32_FLOAT_S8X24_UINTというものもあるらしいけど、２４ビット丸々無駄にするらしいし、４バイトの範囲に収まらないのでなんだか遅そう。

D3D12_RESOURCE_DESC1.Format

深度バッファのみのときは、DXGI_FORMAT_R32_TYPELESS

ステンシルバッファを使う場合は、DXGI_FORMAT_R24G8_TYPELESS

D3D12_CLEAR_VALUE.Format

深度バッファのみのときは、DXGI_FORMAT_D32_FLOAT

ステンシルバッファを使う場合は、DXGI_FORMAT_D24_UNORM_S8_UINT

CreatePlacedResource2.CastFormat

深度バッファのみのときは、

CastFormat[0]=DXGI_FORMAT_D32_FLOAT

CastFormat[1]=DXGI_FORMAT_R32_FLOAT

ステンシルバッファを使う場合は指定なし。

これがいまいち分からず、指定するとエラーになりCreateできない。

深度バッファの方は、指定する場合は両方指定しないとランタイムエラーになる。

指定なしにしたら動くので、下手に指定する必要がないかも。

D3D12_DEPTH_STENCIL_VIEW_DESC.Format

深度バッファのみのときは、DXGI_FORMAT_D32_FLOAT

ステンシルバッファを使う場合は、DXGI_FORMAT_D24_UNORM_S8_UINT

D3D12_GRAPHICS_PIPELINE_STATE_DESC.DSVFormat

深度バッファのみのときは、DXGI_FORMAT_D32_FLOAT

ステンシルバッファを使う場合は、DXGI_FORMAT_D24_UNORM_S8_UINT

D3D12_SHADER_RESOURCE_VIEW_DESC.Format

深度バッファのみのときは、DXGI_FORMAT_R32_FLOAT

ステンシルバッファを使う場合は、DXGI_FORMAT_R24_UNORM_X8_TYPELESS

ここを見るとPlaneSlice０にDXGI_FORMAT_R24_UNORM_X8_TYPELESS、１にDXGI_FORMAT_X24_TYPELESS_G8_UINTを指定する様に書かれている。

SRVでPlaneSliceを複数指定する方法がわからないけど、２つ指定するとそれぞれ深度バッファと、ステンシルバッファが参照できるのだろう。

今のところステンシルありのバッファをテクスチャ利用する予定はないので、必要が出てきたら調べることにする。

PSO

ステンシルバッファを使う場合は、DepthStencilState.StencilEnableをTRUEにする。

ステンシルバッファ書き込み

DepthStencilState.StencilReadMask = D3D12_DEFAULT_STENCIL_READ_MASK ;

DepthStencilState.StencilWriteMask = D3D12_DEFAULT_STENCIL_WRITE_MASK ;

DepthStencilState.FrontFace = {

    D3D12_STENCIL_OP_KEEP,

    D3D12_STENCIL_OP_KEEP,

    D3D12_STENCIL_OP_REPLACE,

    D3D12_COMPARISON_FUNC_ALWAYS

} ;

DepthStencilState.BackFace = DepthStencilState.FrontFace ;

上記は描画した場所をOMSetStencilRefで設定した値で塗りつぶす場合の設定（D3D12_STENCIL_OP_REPLACE）

D3D12_STENCIL_OPは３つ設定できて、最初がステンシルテストに失敗した場合、次がステンシルテストは成功したけど、Zバッファのテストが失敗した場合、最後が両方のテストが成功した場合。

ステンシルバッファの書き込みだけで、描画は行わない場合BlendState.RenderTarget[i].RenderTargetWriteMaskも０にするといいらしいけど、そもそもレンダーターゲットを指定しなければいいんじゃないのか？

バッファ書き込みはやってないので分からず。

ステンシルテスト

DepthStencilState.StencilReadMask = D3D12_DEFAULT_STENCIL_READ_MASK ;

DepthStencilState.StencilWriteMask = 0 ;

DepthStencilState.FrontFace = {

    D3D12_STENCIL_OP_KEEP,

    D3D12_STENCIL_OP_KEEP,

    D3D12_STENCIL_OP_KEEP,

    D3D12_COMPARISON_FUNC_EQUAL

} ;

DepthStencilState.BackFace = DepthStencilState.FrontFace ;

上記は、OMSetStencilRefで設定した値と同じ箇所だけ描画する場合の設定。

ClearDepthStencilViewでD3D12_CLEAR_FLAG_DEPTH | D3D12_CLEAR_FLAG_STENCILを指定して、深度バッファとステンシルバッファを初期化したあと、ClearDepthStencilViewの最後の引数に矩形を指定して、ステンシルバッファだけを１０で初期化。OMSetStencilRefにも１０を設定して描画してみると、こんな感じになった。

Hが欠けてる

指定通りの動作になっているけど、デバッグレイヤには下記の警告が出続ける。

D3D12 WARNING: ID3D12CommandList::ClearDepthStencilView: The clear values do not match those passed to resource creation. The clear operation is typically slower as a result; but will still clear to the desired value. [ EXECUTION WARNING #821: CLEARDEPTHSTENCILVIEW_MISMATCHINGCLEARVALUE]

ステンシルバッファの書き換えにClearDepthStencilViewを利用したのがだめみたい。

矩形で指定範囲を書き換えたい時、わざわざシェーダを通さずClearDepthStencilViewで手軽にクリップ領域を指定できるかと思ったけど、この使い方はだめみたい。

Multithread GPU Command

マルチスレッドでコマンドを発行する仕組みを作ったけど、久しぶりに見たらところどころ忘れてしまってたので資料としてまとめておくことにした。

コマンド発行の仕組み

コマンド発行の全体図

クラスはCommand、CommandList、ComanndAgent、CommandQueueの４つで構成されている。

CommandQueue

CommandQueueは以前はGraphics、Compute、Copyの３つ用意してそれぞれに発行できるようにしていたけど、フレームの途中で同期はしないようにすることを考えるとGraphicsのみで良いという考えに至り、１つのみ用意している。

またGPU処理完了でブロックしないように、Queue１つに付き、１スレッドが待機している。

Command

GPUに命令する最低単位。１命令文＝１Commandで、要求するコマンドに必要なパラメータを管理している。

CommandList

DirectX12のID3D12CommandAllocatorとID3D12CommandListを内包するクラス。

CommandAgent

コマンドを内包し、実行タイミング要求で別スレッド経由でコマンドリストに追加する。

Agent１つに付き、１スレッドが待機している。

処理の流れ

①GetCommandAgent

動作スレッド：メイン

描画開始時、BeginRender内でプールからCommandAgentを取得する。

②AddCommand

動作スレッド：メイン

CommandAgentに対して、各種コマンドを追加していく。

③Execute

動作スレッド：メイン

CommandQueueにCommandAgentを移管して、CommandAgent内に眠っているスレッドを起こす。

同時にCommandQueue内に眠っているスレッドも起こす。

④GetCommandList

動作スレッド：CommandAgent

CommandAgent内のスレッドが、コマンド発行用のリストをプールから取得する。

⑤AddCommandList

動作スレッド：CommandAgent

ComanndAgent内に溜め込んだコマンドを１つずつコマンドリストに追加していく。

⑥ExecuteCommandLists

動作スレッド：CommandQueue

CommandQueue内のスレッドがCommandAgentを監視して、現在管理中のCommandAgentの処理が全て完了していたら、ExecuteCommandListsを呼び出し、GPUの処理を開始する。

⑦ReleaseCommandAgent

動作スレッド：CommandQueue

CommandAgentを返却する。

その際CommandAgentが抱えている各種リソースの開放を行う。

※厳密には、NextFrame内で呼び出される。

⑧NextFrame

動作スレッド：CommandQueue

切り替え先のフレームのGPU命令が完了しているかチェックし、終わっていなければ待つ。

終わっている場合はReleaseCommandAgentを呼び出す

次のフレームに切り替える。

課題

最初の頃はコマンドを追加するたびに、別スレッドでコマンドリストに追加して、全コマンドが追加できたらExecuteCommandListsを発行していた。

現在はCommandQueueにExecuteする単位でExecuteCommandListsする仕組みを用意はしているけど、実際にExecuteするタイミングは全コマンドを追加したらで変わっていない。

nVIDIAのドキュメントによると、１フレームで5～１０回に分けてExecuteCommandListsを呼び出すと良いと書かれている。手動で分割するか、動的に判断するか今後考える。

またCommandAgent内のCommandListは複数持てるように設計しているが、現状利用しているのは１つのみになっている。更に、１フレームで複数CommandAgentを扱えるようにしているけど、現状利用しているのは１つのみ。全体で１５～３０くらいCommandListを保持して使い回すらしいので、複数のCommandListをまとめてExecuteするようにしたい。

※nVIDIAのドキュメントが以前「DX12 Do's And Don'ts」という題名のBlogだったけど、それぞれのトピックに分けて再構成されていた。最初なくなってしまったのかと思ったけど、１つ１つをよく見ると前と同じ内容だった。