Vulkan unpack uvec4 from integer

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?

Solution

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.