Why does my vulkan compute shader receive a 0.0 float as -170146355474918162907645410264962039808.0?

Question

I'm working on a small vulkan app that utilises compute shaders to transform some geometry data. This data is sent to a single compute shader via multiple storage buffers.

To ensure that everything is reaching my compute shader as expected (no byte alignment issues etc.), i've temporarily created an output buffer to which I simply copy input data on GPU side and print it to console from CPU side.

The data in question is a buffer of instance structs:

struct instance
{
    alignas(8) glm::vec2 position;
    alignas(8) glm::uvec2 colours;
    alignas(4) uint32_t object_index;
    alignas(4) float scale;
    alignas(4) float rotation;
    alignas(4) uint32_t FILLER = 0;
};

The shader (GLSL) receives the buffer the following way:

struct instance
{
    vec2 position;
    uvec2 colours;
    uint object_index;
    float scale;
    float rotation;
    uint FILLER;
};

I am creating two instances:

1. at 0, 0
2. at 1, 1

I am printing the contents of my output buffer the following way (the buffer has 256 slots, but for debug purposes i'm only printing the first 16):

    float* output_buffer_pointer;
    vkMapMemory( *get_hardware(), *get_buffer_memory(), offset, 256, 0, (void**) &output_buffer_pointer );
    for (int i = 0; i < 16; i++)
    {
        cout << i << ": " << output_buffer_pointer[i] << endl;
    }
    cout << endl;
    vkUnmapMemory( *get_hardware(), *get_buffer_memory() );

Sending a buffer of a couple of instances to the compute shader and simply copying the position x and y to my debug output buffer (into separate slots) results in mostly expected numbers, EXCEPT the x coordinate of the first instance:

0: -170146355474918162907645410264962039808.00000000 (x of instance 1)
1: 0.00000000 (y of instance 1)
2: 1.00000000 (x of instance 2)
3: 1.00000000 (y of instance 2)

The expected result should be:

0: 0.00000000
1: 0.00000000
2: 1.00000000
3: 1.00000000

This is also the very first byte that should be in my allocated memory (the instance buffer is the first one at offset 0) - not sure if that information may be relevant.

It can't be a byte alignment issue, since all other data is correct.

I've tried changing the x coordinate of the first instance, but the output number didn't change as far as I could tell.

Other fields within the first instance (e.g. the "colours" field) return correct data.

Answer 1

As @chux-ReinstateMonica correctly pointed out, the hex code of above float is ff0000ff, which does look like a colour hex code imo.

Turns out I forgot to set the offset in the vkBindBufferMemory instruction, causing my colour buffer to overwrite my instances.

It was only by coincidence, that the y-coordinate of the first instance and the second colour appeared the same in float notation:

y coordinate 0.0 and blue (0000ffff) both appear as 0.0 in the console, since blue is an incredibly small number (9.18340948595268867429866182409 E-41).