Vulkan unpack uvec4 from integer

Question

I've observed some strange behavior. I have an array of unsigned 32bit integers. I use one integer to encode 4 values, each one byte in size. I'd like to then pass such buffer to vertex shader

layout (location = 0) in uvec4 coords;

In order to achieve this, I use VkVertexInputAttributeDescription with format set to VK_FORMAT_R8G8B8A8_UINT. I have defined such handy struct

struct PackedUVec4{
   unsigned char x;
   unsigned char y;
   unsigned char z;
   unsigned char w;
};

Then I build my buffer as PackedUVec4[] and such buffer is then sent to GPU. However, what I have observed, is that the order of bytes gets swapped. For example if I have

layout (location = 0) in uvec4 coords;
void main(){
   debugPrintfEXT("%v4d", coords);
}

it seems to print the correct output. But if change format to VK_FORMAT_R32_UINT and try to run

layout (location = 0) in uint coords;
void main(){
    uint w = coords & 255u;
    uint z = coords/256 & 255u;
    uint y = coords/(256*256) & 255u;
    uint x = coords/(256*256*256) & 255u;
    debugPrintfEXT("%v4d", uvec4(x,y,z,w));
}

I get the bytes in opposite order. Do the vector types use different endianness?

I don't understand the question. You recognize that there is a distinction between the logical order of bytes in a multi-byte integer and the addressing order of those bytes in memory (ie: endian). But you don't know what it means when the logical order of bytes in a multi-byte integer doesn't match your addressing order? — Nicol Bolas, Aug 13 '21 at 19:03
I mean, I thought that the GPU should use the same endianness as my CPU. I'm trying to do some bit-shifting on GPU and I constantly encounter bugs because the byte order is different than what I expected. But I cannot find anything about this in Vulkan documentation. What can I do to reliably predict the endianness on GPU? I'm a bit afraid that my current code will completely break down on different machines due to this issue. — alagris, Aug 14 '21 at 09:28
"*I thought that the GPU should use the same endianness as my CPU.*" It does. The problem is that *you* didn't. You reversed the endianness of your data on the CPU. That is, your code is confused as to what the endianness of the data actually is. "*But I cannot find anything about this in Vulkan documentation.*" You can go to the PDF and search for "endian" and find it. — Nicol Bolas, Aug 14 '21 at 13:39

score 2 · Accepted Answer · answered Aug 14 '21 at 14:15

The problem is not with Vulkan, but with your code's interpretation of what's going on. Both sending and receiving.

Recall that endianness is about the (potential) difference between the logical location of a byte within a multi-byte value and the relative address of a byte within a multi-byte value. In little endian, if you write a four-byte value to memory, the first byte will be the least significant byte of the value.

Endianness applies to both reading and writing, but only when reading/writing multi-byte values as multi-byte values. Your PackedUVec4 is not a multi-byte value; it's a struct containing bytes with a specific layout. Therefore, if you write to the x component of a PackedUVec4, you are writing to the first byte of that structure, regardless of your CPU's endian.

When you told Vulkan to read this data as a single 4-byte value (VK_FORMAT_R32_UINT), it does so as defined by your CPU's endian. But your code didn't generate that data in accord with your CPU's endian; it generated it in terms of the layout of a PackedUVec4. So the first byte in memory is x. If the GPU reads those 4 bytes as a little endian 4-byte value, then the first byte will map to the least significant byte of the 4-byte value.

But your code that manually decodes the data is decoding it wrong. It expects the least significant byte to be w.

If you want your code to be endian-independent, then you need the GPU to read the data as 4 individual bytes, in the order stored in memory. Which is what the VK_FORMAT_R8G8B8A8_UINT represents. If you want the GPU to read it as an endian-based ordering within a single 32-bit integer, then it needs to be written that way by the CPU.

Vulkan unpack uvec4 from integer

1 Answers1