type size and alignment about hlslpp HOT 2 CLOSED

Hi @zhaijialong, thanks for your question. Hlslpp is developed to use SIMD, and it tries very hard to stay in "SIMD-land" as much as possible. The consequences of these decisions are:

a) All vectors and matrices use hardware vectors. float1, float2, float3, and float4 are always 16 bytes. Making these float would undermine the goal of keeping everything SIMD
b) Different SIMD implementations can have different alignments. For instance, the 4x4 matrix could be 16 byte aligned if in SSE 2, or 32 bytes in AVX, etc.

I have my own toy engine and came across this problem. What I created is another set of hlsl-like structures that are only data types. This has several advantages:

a) There are no alignment issues
b) There are no functions to modify the data. If you're not careful you can accidentally read or mess with the sequentiality of writing to write-combine memory (typical for uploading data to GPU) and having no functions can help prevent that
c) You can easily access components (x, y, z, w) without SIMD-like penalties

You can create conversion functions such that it is seamless to go from hlsl++ to your custom structures. Use the store_* family of functions to safely convert.

Ultimately, this library is not for interfacing/sharing with hlsl, but rather to have math that you can portably copy-paste between GPU and CPU and have it work as seamlessly as possible.

from hlslpp.

ok, that makes sense, thank you for your detailed reply.

from hlslpp.