Shader Memory Layout
See how typed data fits into a shader buffer. Inspect offsets and padding, then compare a different field order.
Layout rules
Logical buffer contents, not physical VRAM allocation or register usage. The selected profile controls layout; a pasted cbuffer wrapper does not change it. Native 16-bit mode corresponds to DXC -enable-16bit-types.
Define data
This overload illustrates a buffer of input fields. The byte map includes those fields only; the result and compiler-managed temporaries are excluded. Selecting a function preserves your layout profile and precision settings. HLSL reference ↗
DXC legacy cbuffer · 24 B data + 24 B padding = 48 B layout span. Changes update automatically.
Inspect memory
| Metric | One block / element | Repeated data budget |
|---|---|---|
| Useful data | 24 B | 24 B |
| Padding | 24 B | 24 B |
| Layout span / stride | 48 B | 48 B |
Color = data per row: green ≥75%, yellow 50–<75%, red <50%. Hatching = padding; numbers = field IDs. Density alone does not establish possible savings. Partial structured rows count only actual bytes. Hover or click a byte to inspect it.
50% data · 24 B of 48 B · 24 B padding in the displayed layout. Field order has not been checked. Use Suggest field order to test whether the span can shrink.
Byte 0 · gain · float · 4-byte component at offset 0. Field gain.
| Field | Type | Offset | Data / extent | Align / stride |
|---|---|---|---|---|
| float | 0 | 4 / 4 | 4 Fits at the next aligned offset | |
| float4 | 16 | 16 / 16 | 4 value would cross a 16-byte row · 12 B before field. | |
| float | 32 | 4 / 4 | 4 Fits at the next aligned offset |
Compare & export
Suggest field order searches top-level permutations for up to eight fields; larger records use a bounded heuristic. It preserves types, array lengths and nested structure order. A smaller layout does not guarantee a faster shader. Update every CPU/GPU consumer when changing layout.
Selected declarations
cbuffer LayoutData
{
float gain;
float4 tint;
float bias;
};