Readback Heap

今までCPUのメモリからVRAMへ一方通行の使い方しかしていなかった。

Heap管理をまとめて、ReadbackのHeapも用意できるようになったので使えるようにしてみる。

Heapの種類

Heapの種類にはUpload、Default、Readback、Customと４つ定義されている。

Customは使うつもりがないので対象は３つ。

CPUのメモリと各種Heapの関係

CPUのメモリと各種Heapの関係はこんな感じ。

それぞれのHeapに利用用途に合わせて各種Viewを付けて、GPUから参照する。

Upload Heap

Uploadは書き込み専用のポインタをMapして、CPU側からデータを直接書き込める。ただし遅いので常時使うのは小さな定数バッファぐらい。また、Default HeapはCPU側から直接扱えないので、データをコピーするために一時的にUploadを経由させるために使う。

Default Heap

GPUが一番効率よくメモリを使える場所。

CPU側からは直接参照できない。

Readback Heap

Readbackは読込専用のポインタをMapして、CPU側からデータを直接参照できる。

Default HeapをReadback経由で参照する場合、まずデータをコピーする。

Uploadでデータをコピーする際、コピー先のリソースのステータスはD3D12_RESOURCE_STATE_COPY_DESTだったがReadbackでデータをコピーする際は、コピー元のリソースのステータスはD3D12_RESOURCE_STATE_COPY_SOURCEにする必要がある。

コピーの完了を待って、Mapで読み取り用のポインタを取得する。

このときD3D12_RANGEを渡すが、Uploadの場合0,0で初期化していた。これはCPU側から読み取らない宣言だったわけだけど、Readbackの場合は読み取るので、読み取るオフセットを指定する。

UAV経由でデータを書き換える

GPUでデータを書き換える代表格はレンダーターゲットや深度バッファになるけど、Compute Shaderで計算結果を書き込むのはUnordered Access Viewを使うことになる。その時のデータ型にもいろいろ種類があるが、ここでは２つで例を挙げる。

RWStructuredBuffer

StructuredBufferの書き込める版。

データソースとしてStructuredBufferで渡されたデータをCompute Shaderで、計算した結果を同じインデックスのRWStructuredBufferに書き込むといったような使い方をする。

AppendStructuredBuffer

Appendはキューのようなデータ構造で、スレッドの処理が完了した順に追加していく。例えばカリングを行って対象データのみ追加する場合、処理後のデータ数がデータ元と異なる。

その変わったサイズを管理するのがUAV Counter。そのためAppendを使う場合UAVにはカウンタが必須になる。

UAV Counterとは

以前UAVのことについて書いたが、このときはUAVカウンタのことを理解していなかった。

このカウンタはUAVにオプションで付けることが出来て、RWStructuredBufferの場合、IncrementCounter、DecrementCounter関数、AppendStructuredBufferの場合、Append関数を使うとカウントが制御される。

バッファに入っているデータ数を管理するカウンタとして利用できるということがわかった。

そのため、データを書き込む前には一旦０にリセットする必要がある。

（ExecuteIndirectを使う場合、Readback不要でシェーダで処理したUAVリソースとカウンタのオフセットをそのまま渡すようなI/Fになっている）

#define DefRS "RootFlags(DENY_VERTEX_SHADER_ROOT_ACCESS|DENY_HULL_SHADER_ROOT_ACCESS|DENY_DOMAIN_SHADER_ROOT_ACCESS|DENY_GEOMETRY_SHADER_ROOT_ACCESS|DENY_PIXEL_SHADER_ROOT_ACCESS),DescriptorTable( SRV(t0, flags=DATA_STATIC_WHILE_SET_AT_EXECUTE),visibility=SHADER_VISIBILITY_ALL),DescriptorTable( UAV(u0, flags=DATA_VOLATILE),visibility=SHADER_VISIBILITY_ALL)"

StructuredBuffer<uint> Src : register(t0) ;
AppendStructuredBuffer<uint> Dst : register(u0) ;

struct CSInput
{
	uint3 ID : SV_DispatchThreadID ;
} ;

[RootSignature(DefRS)] 
[numthreads( 8, 1, 1 )]
void CSMain( CSInput In )
{
	int i = In.ID.x ;
	if( Src[i] > 30 ) {
		Dst.Append( Src[i]) ;
	}
	return ;
}

試しに作ったサンプルでは、Srcで渡した点数データをDstにAppendしていく。

その際、３０点以下の場合は除外するようにした。

１００、８０、６０、５０、４０、３０、２０、１０の８個のデータをSrcで渡すと

Dstで１００、８０、６０、５０、４０の５個のデータと、カウンタには５という値が渡る。

Src

Dst

Counter

Readback経由でCounterを取得して、その数分Dstの先頭から値を取得するとGPUで処理した結果が受け取れるようになった。

これでGPUの処理結果を受け取れるようになったので、単純で大量の計算をGPUに任せることも出来る。

今回のハマりポイント

データ元を構造化バッファにしていたけど、最初は定数バッファで試していた。

定数バッファの場合、全体を配列で使えないので構造体内に配列を定義した。

struct _Src
	uint Val[8] ;
} ;

ConstantBuffer<_Src> Src : register(b0) ;
AppendStructuredBuffer<uint> Dst : register(u0) ;

struct CSInput
{
	uint3 ID : SV_DispatchThreadID ;
} ;

[RootSignature(DefRS)] 
[numthreads( 8, 1, 1 )]
void CSMain( CSInput In )
{
	int i = In.ID.x ;
	if( Src.Val[i] > 30 ) {
		Dst.Append( Src.Val[i]) ;
	}
	return ;
}

C++側からは、バイナリで４バイトずつ８つ（３２バイト）のデータを書き込んだ。

PIXで確認してもきちんとデータが入っている。

にも関わらず出力結果は構造化バッファと同じにならず、２件、１００と４０が返却された。

DXILの_Src構造体のサイズ情報が１１６となっており、３２バイトではない。

どうやら配列の１要素単位で１６バイトアライメントになっているみたいで、最後の項目だけ４バイトと考えるとサイズが一致する。

試しに渡すバイナリを１６バイト単位にすると、同じ結果が得られた。

PIX上のデータには０、４に値が入っていて、１，２，３，５，６，７には値が入っていないように見えるが、シェーダは結果は正しい値になっている。

BufferFormatが実際のデータと合っていないっぽい。

struct _Src
	uint4 Val[2] ;
} ;

ConstantBuffer<_Src> Src : register(b0) ;
AppendStructuredBuffer<uint> Dst : register(u0) ;

struct CSInput
{
	uint3 ID : SV_DispatchThreadID ;
} ;

[RootSignature(DefRS)] 
[numthreads( 8, 1, 1 )]
void CSMain( CSInput In )
{
	int i = In.ID.x / 4 ;
	int j = In.ID.x % 4 ;
	if( Src.Val[i][j] > 30 ) {
		Dst.Append( Src.Val[i][j]) ;
	}
	return ;
}

定義をuint4に変更して、渡すデータも４バイト単位に戻して実行したらうまく行った。

バイナリデータとアライメントが間違っていただけだった。

配列で定義すると、１要素単位で１６バイトアライメントになる。

配列にせず、uintを８つ変数定義すると期待通り４バイトアライメントになる。floatなども同じ。