Yary.Blog: StructuredBufferとCopyQueue

StructuredBuffer

メッシュのボーン行列をシェーダにわたす定義は、定数バッファで固定の配列にしていた。

struct _Bone {
	float4x4 Bones[255] ;
} ;
ConstantBuffer<_Bone> Bone : register(b1) ;

実際に渡す個数はボーンの数分だけで、利用するインデックスも渡した分だけを指すようになっているので問題ない。

ただ、この固定の書き方が気持ち悪いのと、読み込んだメッシュのボーンが固定値を超える場合に調整が必要になるのでなんとかしたい。

構造化バッファ(StructuredBuffer)の場合、可変の配列定義が許されているのでリソースのタイプに追加することにした。

前にテクスチャのミップマップを作る際、GPU側(ComputeShader)で更新するリソースを用意したけど、今度はCPU側から更新するタイプのSRVリソースとなる。

D3D12_HEAP_TYPE_UPLOADとD3D12_HEAP_TYPE_DEFAULTの２リソースを用意して、Uploadの方はMapしっぱなしで更新時にmemcpyしつつ、CopyBufferRegionでDefaltの方に反映する。

このコピーを行うコマンドリストは、汎用的に使えるように用意したDIRECT版のコマンドリストを使っていて、ステータス遷移(D3D12_RESOURCE_STATE_COPY_DEST)、CopyBufferRegionを追加する。

StructuredBuffer<float4x4> Bone : register(t1) ;

シェーダの定義はこんな感じになって、Bone[Index]という風に使える。

疑問点が１つあって、定数バッファはフレームのバッファ数分用意する必要がある。

マイクロソフトのサンプルでは、ダブルバッファの場合必要サイズの２倍データ領域を用意して、毎フレーム交互に書き込み、参照していく。

構造化バッファの場合、今のところ１つで済んでいる。

中間レンダーバッファの時も思ったけど、SRVをベースにしていると１つで済むのか？

ただし、UAV経由で更新する場合は領域が２つ必要だった。

更新時UploadとDefaultの２つが絡んでいるから、これが２つ分扱いになっているのか？

謎。

CopyQueue

ボーンのバッファは毎フレーム更新を行うことになるけど、そのデータのコピーについて今まで使ってなかった専用のコピーキューを用意してやってみようと思う。

D3D12_COMMAND_LIST_TYPE_COPYでCreateCommandQueueを作成する。

コマンドリスト、アロケータも同様にD3D12_COMMAND_LIST_TYPE_COPYで作成して、利用してみるとエラーになった。

D3D12 ERROR: ID3D12CommandList::ResourceBarrier: D3D12_RESOURCE_STATES has invalid flags for copy command list. [ RESOURCE_MANIPULATION ERROR #537: RESOURCE_BARRIER_INVALID_COMMAND_LIST_TYPE]

コピーで作ったリストにはコピーコマンドしか入れることができず、リソースの状態遷移はできないのか？

いろいろ調べてみるとコピーコマンドリストが理解できるステータスなら許容されるみたいだ。Beforeステータスには現在のステータスを設定していたが、これをD3D12_RESOURCE_STATE_COMMONにしてしまえばコピーコマンドのリストでも状態遷移ができた。真面目に今の状態をセットしていたのに、適当な値でいいなんて・・・。それまでは別のDIRECTコマンドのリストで遷移させていたがプログラムが多少スッキリした。