「定数バッファ」の版間の差分
Administrator (トーク | 投稿記録) (→概要) |
Administrator (トーク | 投稿記録) |
||
22行目: | 22行目: | ||
シェーダー定数で激しく変化する値といえば「カメラの位置」くらいである。 | シェーダー定数で激しく変化する値といえば「カメラの位置」くらいである。 | ||
ならば、その部分だけ書き換えて他の部分は再利用した方が効率が良い。 | ならば、その部分だけ書き換えて他の部分は再利用した方が効率が良い。 | ||
+ | |||
+ | == 注意:16バイトアライメント == | ||
+ | |||
+ | ほとんどのプラットフォームで「定数バッファの要素」は「16byteアライメント」となっています。 | ||
+ | 構造体のフィールド変数を上から順番に足したものが16バイト単位でなければなりません。 | ||
+ | |||
+ | ; 問題ない例 | ||
+ | <source lang="c"> | ||
+ | struct cb { | ||
+ | float2 v1; // +8 = 8 | ||
+ | float2 v2; // +8 = 16 | ||
+ | } | ||
+ | </source> | ||
+ | |||
+ | ; ダメな例 | ||
+ | 以下は16バイトを超えているのでダメです。 | ||
+ | <source lang="c"> | ||
+ | struct cb { | ||
+ | float3 v1; // +12 = 12 | ||
+ | float2 v2; // +8 = 20 (16を超えてるのでダメです) | ||
+ | } | ||
+ | </source> | ||
+ | |||
+ | 上記のような場合は16バイト区切りになるようにダミー変数を挿入しましょう。 | ||
+ | <source lang="c"> | ||
+ | struct cb { | ||
+ | float3 v1; // +12 = 12 | ||
+ | float _dummy1; // +4 = 16 | ||
+ | |||
+ | float2 v2; // +8 = 8 | ||
+ | float2 _dummy2; // +8 = 16 | ||
+ | } | ||
+ | </source> | ||
+ | |||
+ | ; もっとも確実な解決策 | ||
+ | もっとも簡単な解決方法は「すべて16バイトのfloat4(vec4)を使うこと」です。 | ||
+ | 無駄だと思っても16バイトのVector4で代用しましょう。 | ||
+ | 定数バッファがバカみたいに巨大化するようなことはまずないので、今の高速なPCだとたった数十バイトで体感速度なんて変わりません。 | ||
+ | その数十バイトであらゆる悩みから解放されます。 | ||
== 関連項目 == | == 関連項目 == |
2023年5月19日 (金) 01:53時点における版
定数バッファ(英語:Constant Buffer、通称:cbuffer)とは、CPUで動くプログラムの変数群を、GPUで動くプログラマブルシェーダーに定数群(バッファ)としてドスンと送り込む機構をいう。
OpenGL界隈では宗教上の理由により「Uniform Buffer Object」という方言が使われている。 意味はほぼ同じである。
概要
まず前提条件としてシェーダーへ渡す変数(定数)はドローコールのたびに再設定するものであり、その変数(定数)は1回のドローコールが終わると自動的に消去される。
次にCPU側で動くプログラムの変数を[GPU]]側で動くプログラマブルシェーダーに定数として送り込むには、
- Direct3D 9
ドローコールの直前に毎回SetVertexShaderConstant命令やSetPixelShaderConstant命令を使って1個1個送り込んでいた。つまり1フレームを描画のたびにメインメモリからVRAMに小さなデータの転送を繰り返していた。
- Direct3D 10
定数バッファ(Constant Buffer、cbuffer)を作成してGPU(VRAM)に送信しておき、以後はドローコールの直前にその定数バッファのポインタだけを送り込むようになった。
つまり定数バッファを利用することで頂点バッファやインデックスバッファなどと同様に再利用でき、かつ毎回送信するデータもポインタひとつで済むようになった。
利点
シェーダー定数には主にディレクショナルライトやポイントライトの座標や明るさなどを格納していることが多い。これらはゲームシーンの中でそんなに勢いよく変化するものではない。ゲーム内で時間経過とともに「昼から夜に」「夜から昼に」なるものでもフレームレート単位でみたら変化などないに等しい。何千回、何万回というドローコールで1回変化するくらいのものである。そもそも常に同じ天候や室内などの場合はほぼ変化がない。
シェーダー定数で激しく変化する値といえば「カメラの位置」くらいである。 ならば、その部分だけ書き換えて他の部分は再利用した方が効率が良い。
注意:16バイトアライメント
ほとんどのプラットフォームで「定数バッファの要素」は「16byteアライメント」となっています。 構造体のフィールド変数を上から順番に足したものが16バイト単位でなければなりません。
- 問題ない例
struct cb {
float2 v1; // +8 = 8
float2 v2; // +8 = 16
}
- ダメな例
以下は16バイトを超えているのでダメです。
struct cb {
float3 v1; // +12 = 12
float2 v2; // +8 = 20 (16を超えてるのでダメです)
}
上記のような場合は16バイト区切りになるようにダミー変数を挿入しましょう。
struct cb {
float3 v1; // +12 = 12
float _dummy1; // +4 = 16
float2 v2; // +8 = 8
float2 _dummy2; // +8 = 16
}
- もっとも確実な解決策
もっとも簡単な解決方法は「すべて16バイトのfloat4(vec4)を使うこと」です。 無駄だと思っても16バイトのVector4で代用しましょう。 定数バッファがバカみたいに巨大化するようなことはまずないので、今の高速なPCだとたった数十バイトで体感速度なんて変わりません。 その数十バイトであらゆる悩みから解放されます。