# Clarifying vulkan glsl std140

So I have a uniform block that looks something lile this

{ mat4; mat4[128]; uint[16] }

The block should total up to 8320 bytes. After aligning by 256 bytes for nvidia, that brings the total allocation size to 8448 bytes.

However, according to renderdoc and spirv-cross the total block size should be 8512 bytea. Can someone explain to me why there is a 64 byte padding at the end?

The block should total up to 8320 bytes.

No, it shouldn't. You use a uint[16] array. Well, std140 layout makes it clear that the array stride for any array is always rounded up to the stride of a vec4. So that array takes up 256 bytes.

You should instead use a uvec4[4] instead, which you would index from like a multidimensional array.

• Thanks! The vulkan spec doesn't clearly state the std140 rules and i must have missed that. Is this better documented in the opengl spec instead? Or doea glsl have its own spec? – Temp4890 Mar 27 at 16:01
• @Temp4890: "The vulkan spec doesn't clearly state the std140 rules" It isn't supposed to. std140 layout is not a part of Vulkan or SPIR-V; it's a part of OpenGL and GLSL. Vulkan requires that the SPIR-V it consumes provides explicit byte offsets and array/matrix strides; it doesn't allow you to use std140 layout. It is the GLSL-to-SPIR-V compiler that creates these offsets&strides by applying the OpenGL std140 rules. It's GLSL/OpenGL that decides what std140 means. – Nicol Bolas Mar 27 at 16:05
• @Temp4890: That being said, the Vulkan specification section on layout does make it clear that UBOs require that the ArrayStride must be a multiple of the size of the extended alignment. And the extended alignment of an array/struct is the alignment of its member(s), rounded up to 16. – Nicol Bolas Mar 27 at 16:16
• Thanks for the clarification. I'll go grab myself a copy of the glsl spec – Temp4890 Mar 28 at 0:41