Uniform Buffer Objects: Passing Data to Shaders

Topic Overview

Constants Shared Across a Draw Call

Shaders need data constant for all vertices or fragments in a draw call: MVP matrices, light positions, material properties, elapsed time. Early OpenGL passed these one at a time via glUniform. Modern OpenGL and Vulkan use Uniform Buffer Objects (UBOs) for one bind instead of dozens of API calls.

A UBO is a GPU memory block bound to a shader binding point. The shader declares a uniform block and reads fields by name.

std140 Layout Rules

UBOs follow std140 packing rules for predictable alignment:

cCopy
Loading…

For example, a vec3 followed by a float in the same struct may waste padding because vec3 already occupies 16 bytes in std140. Misaligned CPU structs cause shaders to read garbage silently. Engines like Unreal auto-generate reflection metadata to avoid this.

• One bind replaces many glUniform calls
• Reusable across multiple shader programs
• Vulkan equivalent: uniform buffer in a descriptor set

For This Exercise

You will define a UBO struct in C with correct std140 padding and print each field's byte offset. This task asks you to compute alignment for matrices, vec3/float pairs, and arrays. Getting struct layout wrong is a classic bug where the GPU reads garbage because CPU-side packing does not match the shader's expected layout.

Your Task

Shaders read uniform and storage buffers with a fixed memory layout, and the CPU side must write bytes at exactly those offsets. Write a std140/std430 layout calculator. For every member of a block or struct, print its offset, size and alignment, the array and matrix-column strides, and the padding that the rules insert. Then print the total size and how much of it is padding. The vec3 that aligns like a vec4 is the classic bug this catches.

Input

// starts a comment. ;, { and } are ignored, except that a } on its own acts as end.

cCopy
Loading…

Types: float int uint bool, vec2 vec3 vec4 (and the ivec/uvec forms), mat2 mat3 mat4 (column-major), and previously declared structs.

Rules

• Placement: each member starts at the next multiple of its alignment. A matrix's size is columns × stride, and an array's size is count × stride.
• Structs: a struct's size is rounded up to its alignment (tail padding). A block's total is simply the end of its last member.
• Data bytes: the real data, 4 per scalar component (vec3 = 12, mat3 = 36), times the array counts, summed through structs. Padding = total - data.

Output

cCopy
Loading…

• Member lines: %4d: TYPE NAME[N] size S, align A[, array stride X][, column stride Y].
• Padding: a gap before a member prints (N bytes of padding) on its own line, and a struct's rounding prints (N bytes of tail padding).
• Struct totals end with , align A.
• Errors (the line is skipped):
  • line N: unknown type T
  • line N: bad array size in NAME[..]
  • line N: expected TYPE NAME[N]
  • line N: struct S cannot contain itself
  • line N: struct|block X has no members (it is dropped)
  • line N: layout std140|std430
  • line N: expected layout, struct, block or show
  • line N: too many declarations / too many members
  • show: no declaration X
  • NAME: missing end (at the end of input)

Example

Input:

cCopy
Loading…

Output:

cCopy
Loading…

Requirements

1. Compute struct sizes and alignments recursively, with the current layout rules, since a struct embedded in a block follows the block's rules.
2. Keep "array" and "matrix" as layout concepts. Both are sequences whose element stride is rounded, which is where most padding comes from.

Hidden tests cover arrays of scalars and vec3s under both layouts, mat2 in std140 versus std430, a struct array with tail padding, show after switching layouts, and declaration errors.