Unable to read vec3<float> buffer data from binary file

[Ilkka Saarelainen]

Reading buffer contents from a binary file doesn't work properly if the buffer type is vec3 (or corresponding vulkan type with 3 components e.g. R32G32B32_SFLOAT). Amber seems to expect one element to be 4 components long (4 floats).
The problem can be reproduced by changing the buffer types from vec4 to vec3 in the buffer_load_binary.amber test (https://github.com/google/amber/blob/main/tests/cases/buffer_load_binary.amber)

from:

BUFFER buf0 DATA_TYPE vec4<float> SIZE 3 FILE BINARY vec4data.bin
BUFFER buf1 DATA_TYPE vec4<float> SIZE 3 FILL 0.0

BUFFER ref0 DATA_TYPE vec4<float> DATA
1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0 10.0 11.0 12.0
END

BUFFER ref1 DATA_TYPE vec4<float> DATA
2.0 4.0 6.0 8.0 10.0 12.0 14.0 16.0 18.0 20.0 22.0 24.0
END

to:

BUFFER buf0 DATA_TYPE vec3<float> SIZE 4 FILE BINARY vec4data.bin
BUFFER buf1 DATA_TYPE vec3<float> SIZE 4 FILL 0.0

BUFFER ref0 DATA_TYPE vec3<float> DATA
1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0 10.0 11.0 12.0
END

BUFFER ref1 DATA_TYPE vec3<float> DATA
2.0 4.0 6.0 8.0 10.0 12.0 14.0 16.0 18.0 20.0 22.0 24.0
END

The modified test outputs following error:
buffer_load_binary.amber: 54: EXPECT EQ_BUFFER command cannot compare buffers of different size: 3 vs 4

[dan sinclair]

I'm guessing this is getting into the layout rules. In both STD140 and STD430 a vec3 gets the alignment of a vec4. So it's possibly expecting to read 4 elements even though it's a vec3 because of the round up.

[Ilkka Saarelainen]

Oh, I see. I thought padding wasn't used in std430 with vec3.