HLSLPP_SCALAR and struct alignment?

[Benualdo]

Hi, recently I add a bug on ARM and wanted to switch to scalar implementation of hlslpp onto that platform but this introduced another issue: mesh loading was not working anymore!

Turns out I was serializing a struct like this:

struct Vertex
{
    core::float4    pos; 
    core::float4    nrm;
    core::float4    bin;
    core::float4    tan;
    core::float4    color;
    core::float2    uv[2];
    u16             indices[4];
    u8              weights[4];
};

And sizeof(Vertex) was 128 with SSE implementation but only 124 with scalar implementation because of SSE alignement.

While I understand that serializing vector types is discutable (e.g., uv[0] is 16 bytes instead of 8 here) do you think it might be a good idea to enforce struct alignment of hlslpp structs like float4 even when the scalar implementation is used for consistency?

e.g.:

struct **alignas(16)** hlslpp_nodiscard	float4
{ 

The value of 16 here is because of SSE and could vary but at least we could have a define like
#define HLSLPP_MIN_ALIGNMENT 16
?

I solved my issue by using alignas on my own struct, but what do you think about the feature for hlslpp?

Thanks,
Benoît.

[redorav]

Yes, that is a good idea. It should be consistent between platforms. I'll take a look

@Benualdo Also, what but did you get on ARM?

[Benualdo]

Using a small epsilon like float1 vlerp1 = lerp(vfoo1, vbar1, vbaz1); hlslpp_check(eq(vlerp1, lerpf(vfoo1.r, vbar1.r, vbaz1.r), 0.000001f)); the test now passes indeed.

I'm more concerned about quaternion::rotation_euler_zxy returning crazy values on ARM:

MSVC x64:

MSVC ARM64 (Surface Pro 11):

(both debug and release)

Because that's exactly the issue I have in my engine.

[redorav]

Can you open separate issues for all those issues you have and I can take a look? With the inputs, the functions, essentially the repro

[redorav]

Disregard my last comment, I have been able to repro in Android as well. I'm trying to see where it goes wrong

[redorav]

Fixed in 4dd067b

[Benualdo]

Awesome, thanks!

[redorav]

This is fixed in 92729f2 btw

[redorav]

I think there is a further possible discussion regarding the size and alignment of the types. There is an argument towards having types with the same alignment across platforms if e.g. one platform is used to store data and the other to consume it. To be honest, I don't recommend using these types to store data due to wasted space but that could come with the interop structs. It is a known issue and it needs a solution.

I am enforcing the alignment of the float4 for now and we'll see what scope or desire there it to change it for other platforms (I'm thinking of NEON here)

[Benualdo]

Yeah, it's a common pitfall, but I don't like how many engines end up with two math libraries: one SIMD and one scalar. Maybe I'll just create 'storage' types like StorageFloat4, StorageFloat3, etc., with no methods except casts to and from HLSLPP types or just use float[] maybe. And IMHO, enforcing 16 bytes alignment for SIMD types is totally acceptable even for NEON because even if not stricly necessary it's better for performance but I understand other people could think otherwise, hence the #define for minimum enforced alignment idea.