<blockquote>
  <p>The block should total up to 8320 bytes.</p>
</blockquote>

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

<p>You should instead use a <code>uvec4[4]</code> instead, which you would index from like a multidimensional array.</p>

CC BY-SA 4.0
2019-03-27T16:01:50.697Z
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
CC BY-SA 4.0
2019-03-27T16:05:35.353Z
@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
CC BY-SA 4.0
2019-03-27T16:16:53.657Z
@Temp4890: That being said, the [Vulkan specification section on layout](https://www.khronos.org/registry/vulkan/specs/1.1/html/chap14.html#interfaces-resources) 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
CC BY-SA 4.0
2019-03-28T00:41:01.283Z
Thanks for the clarification. I'll go grab myself a copy of the glsl spec
Temp4890
CC BY-SA 4.0
2019-03-27T13:50:05.703Z
2019-03-27T13:50:05.703Z
Nicol Bolas
<p>So I have a uniform block that looks something lile this</p>

<p>{
mat4;
mat4[128];
uint[16]
}</p>

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

<p>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?</p>

<glsl><vulkan>
Clarifying vulkan glsl std140
Temp4890
# Clarifying vulkan glsl std140

(Asked by: username_0 on 2019-03-27)

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?

**Tags:** glsl, vulkan


---

## 1 answers

### Answer by username_1 on 2019-03-27. Score: 6 | Accepted answer

> 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.

> **Comments:**
> **username_0**: 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?  
> **username_1**: @username_0: "*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.  
> **username_1**: @username_0: That being said, the [Vulkan specification section on layout](https://www.khronos.org/registry/vulkan/specs/1.1/html/chap14.html#interfaces-resources) 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.  
> **username_0**: Thanks for the clarification. I'll go grab myself a copy of the glsl spec  

---

