type size and alignment
zhaijialong opened this issue · comments
hi,
hlslpp looks great，the only reason which prevents me to use it is the size and alignment of each types.
float1/2/3 is 16 bytes, and every floatN(xM) in hlslpp has alignment of 16 bytes(rather than 4).
that's very different from hlsl, we can't share some code between c++ and hlsl, such as some buffer struct defines.
any thoughts about it ? thanks.
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.
ok, that makes sense, thank you for your detailed reply.