定数バッファ

定数バッファでハマったのでそれについてのメモ。

定数バッファの種類

フレーム依存定数バッファ

最初に自作ライブラリで用意したのはフレーム数に依存した定数バッファ。

ダブルバッファならフレーム数は２で、定数バッファのサイズを２５６の倍数に補正したサイズをフレーム数倍した領域をCreateCommittedResourceしたもの。

D3D12_HEAP_TYPE_UPLOADでCreateCommittedResourceしたリソースから、Mapでマッピングしたポインタをリソース破棄まで保持する。

データの書き換えは、このポインタに書き込む。

これは毎フレーム頻繁に値の書き換えがあるような用途で、用意した前半部分と後半部分のメモリをフレームの切り替えで書き込むオフセットを制御する。

読み取り専用定数バッファ

シェーダの内容によってはパラメータとして設定はするんだけど、値自体は最初に設定した以降変わらないというパターンのものもある。

フレーム数に依存した定数バッファでこのパターンのシェーダを使う場合、毎フレームの更新は不必要なため、最初に１フレームと、２フレーム目に同じデータを設定して使うことになる。また、大抵の場合データは書き換えの必要がない。

データの領域がフレーム数倍必要になり、初期化時にフレーム数分書き込む必要がある。

これはかなり無駄なので、このパターンに対応するため次に用意したのは読み取り専用の定数バッファ。フレーム数分定数バッファを用意するのはマイクロソフトのサンプルがそうなっていたからで、常にフレーム数分用意しないといけないと思いこんでいたけど、値を書き換えないなら１つ分でも行けるかなと思い試してみたところ問題なく動作した。

領域は必要な定数バッファサイズを２５６の倍数に補正したサイズのみ。

作成時にテクスチャと同様、データをGPUに書き込んでしまう。

D3D12_HEAP_TYPE_DEFAULTでCreateCommittedResourceしたリソースに、一時的に作成したD3D12_HEAP_TYPE_UPLOADのリソースを使って、CopyBufferRegionでコピーする。

Uploadでマッピングしたポインタは必要ないのでUnmapする。

32Bit定数バッファ

いろいろなサンプルを見ている中で見つけた定数バッファ。

ルート署名内に「RootConstants( num32BitConstants=1, b0)」と書けば、別途リソースの準備をする必要なく定数バッファを扱える。

テクスチャにミップマップを生成するコンピュートシェーダを用意したとき、別途定数バッファリソースの準備が不要なので使ってみたのがきっかけ。

前回のぼかしのシェーダで、パラメータをこの定数バッファで渡そうとしたものの、エラーがでてうまくいかず、読み取り専用定数バッファでとりあえず済ませた。

その時のエラーがこれ。

D3D12 ERROR: ID3D12CommandList::SetGraphicsRoot32BitConstants: No root signature has been set, so setting root constants doesn't make sense and is invalid. [ EXECUTION ERROR #709: SET_ROOT_CONSTANT_INVALID]

ルート署名に32Bit定数が存在しているのはPIXで確認できる。

PIXのパイプライン情報

このエラー文や32Bit定数バッファにまつわるキーワードで検索しまくったが解決につながる情報は得られなかった。

ネットのサンプルでも普通に使われているし、ミップマップのコンピュートシェーダでは普通に使えている。

コンピュートシェーダで使っているのはSetComputeRoot32BitConstantsで、今回使おうとしているのはSetGraphicsRoot32BitConstants

万策尽きて諦めかけてたとき、ふと思いついた。

BeginRenderという関数を用意して、レンダリング開始時にコマンドアロケータ、コマンドリストをリセットしているが、うまく行ってるミップマップのシェーダでは、このBeginRender後にSetComputeRoot32BitConstantsを呼び出している。対して、うまく行ってないシェーダではBeginRender前に呼び出していた。

コマンドリストのResetから、Closeの間で呼び出す必要があったというのが原因。

定数バッファのリソースは存在せず、シェーダに付属しているイメージなので常に書き込めるわけではないようだ。

もう１つ分かったことは、32Bit定数はフレーム依存定数バッファと同じ使い方ということ。

前回のぼかしのシェーダでは、用途としては読み取り専用定数バッファだったため、ぼかし強度を変更したタイミングで定数バッファを書き換え、毎フレームは書き換えてはいなかった。32Bit定数バッファでも同じように１回だけ書き込んで、次回以降書き込まずにいたら、結果が思い通りにならない。前回書き込んだ値は保持されず、毎フレーム書き込まないといけない模様（GPUによる？）

2023/8/27追記

この頃は定数バッファと同様にバッファが独立してあって、そこに値を設定する関数がSet[Graphics|Compute]Root32BitConstantsだと思っていた。

この関数はコマンドリストに追記する関数なので、当然コマンドリストが記録状態になっていないと使えない。

フレーム毎の書き込み

フレーム依存定数バッファ：不要　※最初に全フレーム分書き込んだ場合

ダブルバッファの場合、前回、前々回のデータは保持している。

フレーム単位に参照する場所を切り替える関係上、更新を止めるなら全フレームのデータが同じになっていないと動作がおかしくなる。

実質フレーム毎の更新は必要。

読み取り専用定数バッファ：不可

作成時にGPU側にデータをコピーして、仕組み上書き換えできなくしているのでフレーム毎の書き込みはできない。

32Bit定数バッファ：必須

前回の値が保持されないため、毎フレーム書き込む必要がある。

データサイズ

フレーム依存定数バッファ：256byte単位×フレーム数

一定以上のデータ量でフレーム毎に書き換えが必要な場合に選択する。

また、フレーム専用の領域を用意しているので、32Bit定数よりも高速に動作（して欲しい）

読み取り専用定数バッファ：256byte単位

GPU側に書き込んでいるため、大きいデータでも高速に参照ができる。

32Bit定数バッファ：32Bit(4Byte)単位

少量のデータを渡す場合に適している。

コンピュートシェーダの場合は読み取り専用と同じような使い方もできる。

軽量なぼかし処理

以前DoFにチャレンジした際、ぼかし処理にガウシアンブラーを使ってぼかして見たが、思っていたほどボケなかった。

それにもかかわらず結構なGPUパワーを使うので、もっといい方法を探していた。

そこで見つけたのがこのサイト。

ガウシアンブラー単体だと、ブラーをかける対象のサイズが大きいと処理の負担も大きい。

DoFでは1/4の縮小画像を作っていきながらブラーをかけて、その画像を拡大して使う。

ほぼそれと同じ発想なんだけど、ブラーの処理が例えば8×8ブラーだと１６回サンプリングする必要があるのに対し、８回で済ませる。

あと、縮小画像1/16の画像と、1/64の画像の２段階で処理を行っていた。

最初真似して２段階、その後３段階まで試してみたけど、どうも結果が汚い。どんどん縮小させていって、最後に拡大するとどうしても粗が目立つ。

逆に最初から落としたいレベルまで縮小させてしまってから、縮小画像を４倍に拡大するようにしてみたところ、納得行く感じになった。

処理の流れ

PSシェーダ

#define DefRS "RootFlags(ALLOW_INPUT_ASSEMBLER_INPUT_LAYOUT | DENY_HULL_SHADER_ROOT_ACCESS | DENY_DOMAIN_SHADER_ROOT_ACCESS | DENY_GEOMETRY_SHADER_ROOT_ACCESS),DescriptorTable( Sampler(s0),visibility=SHADER_VISIBILITY_PIXEL),DescriptorTable( SRV(t0, flags=DATA_STATIC),visibility=SHADER_VISIBILITY_PIXEL),DescriptorTable( CBV(b0, flags=DATA_STATIC),visibility=SHADER_VISIBILITY_PIXEL)"

SamplerState Sampler : register(s0) ;

Texture2D TexColor : register(t0) ;

struct _Param { 
	float2	Scale ;		// 倍率
} ;
ConstantBuffer<_Param> Param : register(b0) ;

static const int BLUR_SAMPLE_COUNT = 8 ;
static const float2 BLUR_KERNEL[ BLUR_SAMPLE_COUNT ] = {
	float2(-1.0f, -1.0f),
	float2(-1.0f,  1.0f),
	float2( 1.0f, -1.0f),
	float2( 1.0f,  1.0f),
	float2(-0.5f,  0.0f),
	float2( 0.0f,  0.5f),
	float2( 0.5f,  0.0f),
	float2( 0.0f, -0.5f),
} ;

struct PSInput
{
	float4 Pos	: SV_POSITION ;
	float2 UV	: TEXCOORD ;
} ;
struct PSOutput
{
	float4 Col : SV_TARGET ;
} ;
PSOutput PSMain( PSInput In )
{
	PSOutput Out ;

	float4 color = 0 ;
	for( int j = 0 ; j < BLUR_SAMPLE_COUNT ; j++ ) {
		color += TexColor.Sample( Sampler, In.UV + BLUR_KERNEL[j] * Param.Scale ) ;
	}
	Out.Col = float4( color.rgb / float( BLUR_SAMPLE_COUNT ), 1.0f ) ;

	return Out ;
}

Param.Scaleに「1.0f / 元のテクスチャサイズ * ぼかし強度」を指定する。

1/4096の場合は、元のテクスチャ幅、高さそれぞれ64で割ったサイズの画像を用意して、ぼかし強度に64を指定してレンダリングをした後、元のテクスチャ幅、高さそれぞれ32で割ったサイズの画像を用意して、ぼかし強度に32を指定してレンダリングする。

出力結果

無料の写真素材「ぱくたそ」からお借りした画像

この画像をそれぞれの強度でぼかした結果がこれ。

1/16

1/64

1/256

1/1024

1/4096

中間バッファ

1/1024と1/4096の中間バッファはこんな感じ

1/1024の中間バッファ

1/4096の中間バッファ

この時点ではかなりカクカクしているけど、この後それぞれ1/512、1/2048の画像にアップスケーリングして、間をなだらかにするので元のサイズに戻してもあまり違和感がない状態になっている。

パフォーマンス

ガウシアンブラーは４KでGPU使用率が４０％ぐらいに対し、今回の方式だと２０％で半分になっていた。

PIXで測ってみると、1024×1024のサイズ同士ではガウシアンブラーが646usに対し、1/16縮小が365us、1/4096縮小が178usだった。

ボケの強度を強くするほど中間バッファのサイズが小さくなるので処理が軽くなる。

ガウシアンブラーは期待していたボケ具合にはならず、更に重い処理だったが、今回の方式であればボケ具合を調整できる上に、処理時間も半分以下ので済むので満足。

サンプラー見本

サンプラーはテクスチャを貼り付けるときに必要なリソースで、主にフィルターと、アドレスモードを設定する。（そのほかの値は比較関数以外は固定値で使いこなせてない）

フィルター

D3D12_FILTERのenum値で、定義値を見るとごちゃごちゃしていてよくわからない。

最初に定義されているのが「D3D12_FILTER_MIN_MAG_MIP_POINT」で、D3D12_FILTERの後に、MIN、MAG、MIP、POINTという名前がついている。

MINがテクスチャの縮小時の挙動、MAGがテクスチャの拡大時の挙動、MIPがミップレベルの挙動を指していて、最後のPOINTがその挙動。

挙動にはPOINTとLINERとANISOTROPICがあり、ANISOTROPICはちょっと特殊。

POINTはポイントサンプリング、LINERはサンプリングに線形補間を使用。

改めて「D3D12_FILTER_MIN_MAG_MIP_POINT」を見ると、拡大縮小、ミップレベルですべてポイントサンプリングするということになる。

別の定義「D3D12_FILTER_MIN_LINEAR_MAG_POINT_MIP_LINEAR」は、縮小時は線形補間、拡大時はポイントサンプリング、ミップレベルは線形補間を利用する。

ただリファレンスには「拡大または縮小のどちらを行うかの選択があいまいな場合に、未定義の動作が発生します。」とあるので、実質使うのは「D3D12_FILTER_MIN_MAG_MIP_POINT」と「D3D12_FILTER_MIN_MAG_MIP_LINER」だけでいいのではないか？

残りのANISOTROPICは異方性補完という方法で、視線も考慮した補完方法らしい。

線形補間よりも品質は良くなるがパフォーマンスも落ちるので、今のところは未使用。

定義も、「D3D12_FILTER_ANISOTROPIC」で、拡大縮小、ミップレベルの補完をいい具合にしてくれるみたい。

アドレスモード

D3D12_TEXTURE_ADDRESS_MODEのenum値で全部で５種類ある。

D3D12_TEXTURE_ADDRESS_MODE_WRAP

並べて表示

D3D12_TEXTURE_ADDRESS_MODE_MIRROR

反転して表示

D3D12_TEXTURE_ADDRESS_MODE_CLAMP

範囲外は端の色が続く

D3D12_TEXTURE_ADDRESS_MODE_BORDER

範囲外はD3D12_SAMPLER_DESCの色で塗りつぶされる

アルファを０にすると、範囲外は何も描かれなくなる

D3D12_TEXTURE_ADDRESS_MODE_MIRROR_ONCE

１回だけ反転して、それ以降はCLAMPの動作

アドレスモードはD3D12_SAMPLER_DESCに３つ指定することになる。

１つ目は横方向、２つ目は縦方向、３つ目はよくわからない。

横と縦に同じアドレスモードを指定した見本

貼り付けるテクスチャ画像はこれ。

テクスチャ画像

このテクスチャを５×５で表示（UVの値は-2～2を指定）

WRAP/LINER

ドットがしっかりした画像の場合は、線形補間するとぼやけてしまう。

以降はポイントサンプリング。

WRAP/POINT

MIRROR/POINT

CLAMP/POINT

BORDER/POINT

MIRROR ONE/POINT

横と縦に別のアドレスモードを指定した見本

横にWRAPを指定

WRAP/MIRROR/POINT

WRAP/CLAMP/POINT

WRAP/BORDER/POINT

WRAP/MIRROR ONE/POINT

横にMIRRORを指定

MIRROR/WRAP/POINT

MIRROR/CLAMP/POINT

MIRROR/BORDER/POINT

MIRROR/MIRROR ONE/POINT

横にCLAMPを指定

CLAMP/WRAP/POINT

CLAMP/MIRROR/POINT

CLAMP/BORDER/POINT

CLAMP/MIRROR ONE/POINT

横にBORDERを指定

BORDER/WRAP/POINT

BORDER/MIRROR/POINT

BORDER/CLAMP/POINT

BORDER/MIRROR ONE/POINT

横にMIRROR ONEを指定

MIRROR ONE/WRAP/POINT

MIRROR ONE/CLAMP/POINT

MIRROR ONE/BORDER/POINT

MIRROR ONE/MIRROR/POINT