You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Chrome 144 added the WGSL uniform_buffer_standard_layout language feature. When enabled via requires uniform_buffer_standard_layout;, uniform buffers may use the same memory layout constraints as storage buffers — in particular, the 16-byte alignment requirement on array elements is lifted. This matches GLSL's std430 semantics.
Why this matters
The engine packs uniform data into uniform buffers automatically (via the uniform buffer / dynamic buffer paths). Today, arrays like array<f32, N> or array<vec3<f32>, N> get padded out to 16-byte stride, wasting bandwidth and complicating layouts shared between uniform and storage buffers.
With this feature, the engine could:
Pack array<f32, N> and array<vec3<f32>, N> at natural stride
Share data structure layouts between uniform and storage buffers without padding hacks
Reduce uniform buffer bandwidth for the affected types
Why this is more work than a typical WGSL feature cap
Unlike the other WGSL feature caps (which just emit a requires directive and let shaders opt-in conditionally), the engine's uniform buffer packing code in JS (e.g. UniformBuffer, UniformBufferFormat, the dynamic buffer system) currently encodes the std140-style alignment rules. To benefit from uniform_buffer_standard_layout, the packing logic itself has to branch on the cap and apply std430-style stride when supported.
This means:
JS-side packing layout needs to be cap-aware (per-device, since Firefox/Safari may not support it)
Shader-side struct layouts may need conditional padding for portability
Existing uniform buffer formats / layouts may need versioning to avoid breaking pre-built shaders
Audit the JS uniform-buffer packing code paths to identify where the std140 alignment is applied and what would need to change.
Decide on a portability strategy: do shaders always use the tighter layout where supported and fall back where not, or is this opt-in per uniform buffer?
Background
Chrome 144 added the WGSL
uniform_buffer_standard_layoutlanguage feature. When enabled viarequires uniform_buffer_standard_layout;, uniform buffers may use the same memory layout constraints as storage buffers — in particular, the 16-byte alignment requirement on array elements is lifted. This matches GLSL'sstd430semantics.Why this matters
The engine packs uniform data into uniform buffers automatically (via the uniform buffer / dynamic buffer paths). Today, arrays like
array<f32, N>orarray<vec3<f32>, N>get padded out to 16-byte stride, wasting bandwidth and complicating layouts shared between uniform and storage buffers.With this feature, the engine could:
array<f32, N>andarray<vec3<f32>, N>at natural strideWhy this is more work than a typical WGSL feature cap
Unlike the other WGSL feature caps (which just emit a
requiresdirective and let shaders opt-in conditionally), the engine's uniform buffer packing code in JS (e.g.UniformBuffer,UniformBufferFormat, the dynamic buffer system) currently encodes the std140-style alignment rules. To benefit fromuniform_buffer_standard_layout, the packing logic itself has to branch on the cap and apply std430-style stride when supported.This means:
Suggested approach
supportsUniformBufferStandardLayout,CAPS_UNIFORM_BUFFER_STANDARD_LAYOUT,requires uniform_buffer_standard_layout;) — trivial, follows the existing pattern (feat(graphics): expose WGSL unrestricted_pointer_parameters as a device cap #8785, feat(graphics): expose WGSL pointer_composite_access as a device cap #8786, feat(graphics): expose WGSL packed_4x8_integer_dot_product as a device cap #8787, #TBD).References