mbl*_*mbl 4 directx direct3d hlsl directx-12
我想知道哪种资源类型最适合使用,以便为静态数据保存尽可能多的元素,并且在绘制调用期间不会更改。我能看出常量缓冲区和只读结构化缓冲区之间的唯一区别是常量缓冲区数据必须在其ID3D12Resource对象内部按 256 字节对齐。
lights.hlsl
#define as_many_as_possible 1000
struct light
{
float3 position;
float falloff_start;
float3 direction;
float falloff_end;
float3 color;
float3 strenght;
};
struct light_data
{
light lights [as_many_as_possible];
};
ConstantBuffer<light_data> cb_lights : register(b0);
// Versus
StructuredBuffer<light> sb_lights : register(s0);
Run Code Online (Sandbox Code Playgroud)
如果我的目标是保存尽可能多的灯光数据,那么哪一个更好?
常量缓冲区和结构化缓冲区之间存在更多差异。
在常量缓冲区中,只能同时显示 64k 的数据,因此您不能拥有 1mb 的数据并使其在着色器中立即可见,而在结构化缓冲区上则可以。
常量缓冲区比结构化缓冲区具有更复杂的对齐规则,您的示例实际上非常适合它:
如果是结构化缓冲区,您的灯光结构的大小为:
struct light
{
float3 position; /12
float falloff_start; /4 -> 16
float3 direction; /12 -> 28
float falloff_end; /4 -> 32
float3 color; /12 -> 44
float3 strenght; /12 -> 56
};
Run Code Online (Sandbox Code Playgroud)
因此您的数据将被解释为 56 字节结构的数组。
但是,常量缓冲区结构对齐需要 16 个字节,因此您的结构将被解释为:
struct light
{
float3 position; /12
float falloff_start; /4 -> 16
float3 direction; /12 -> 28 (not 16 byte boundary crossing)
float falloff_end; /4 -> 32
float3 color; /12 -> 44 (no 16 byte boundary crossing)
float pad; /4 -> 48 (float3 would cross 16 boundary)
float3 strenght; /12 -> 60
float pad2; /4 ->64 (next float3 would cross 16 boundary, which is the next position in the array, there is no end padding for the last element of the array however)
Run Code Online (Sandbox Code Playgroud)
所以你的灯将是 64 字节(需要与你的 cpu 结构匹配,否则你的数据将不匹配)。
在某些硬件上,由于这些限制,在常量缓冲区与结构化缓冲区的情况下,读访问可以得到更加优化。这取决于许多因素(例如着色器中的读取频率),因此您需要进行分析以查看用例中的差异。
此外,一些供应商(如 NVidia)建议出于性能原因(在结构化缓冲区的情况下),结构应与 16 字节边界对齐,因此在您的情况下结构将是:
struct light
{
float3 position; /12
float falloff_start; /4 -> 16
float3 direction; /12 -> 28
float falloff_end; /4 -> 32
float3 color; /12 -> 44
float3 strenght; /12 -> 56
float2 _pad;
};
Run Code Online (Sandbox Code Playgroud)
| 归档时间: |
|
| 查看次数: |
3064 次 |
| 最近记录: |