Are there plans for wide/packed types in glam?

[Kanabenki]

Hey there,

I was wondering if implementing wide/packed types similar to ultraviolet's Vec4x4 and similar was planned/wanted for glam?

I've looked into implementing some of those myself, and here's some design points that seems to need discussion in particular if wide types were to be added:

• What vector types and pack sizes should be covered? I assume the strict minimum would be packed versions of every types from the f32 and f64 modules targeting 128 bit wide SIMD registers (and possibly the corresponding mask vector types), but a packed version of the rest of the integer-based types would probably also make sense IMO?
• Does glam plan to enable support for wider than 128 bit SIMD registers? Extensions like AVX would allow adding another set of twice bigger packed types in a subsequent PR (we could also piggyback off of that to enable the use of SSE3 to 4.2 and AVX/AVX2 intrinsics in places were it can improve performance.)
• What would be the type interface for functions like dot which reduce a vector to a scalar value ? For Vec4x4 for example, several possibilities comes to mind:
  • Simply returning a vector type, though the xyzw fields would not semantically make sense, and this would not scale for packed types with more than 4 elements.
  • Creating wrapper types such as f32x4 that would abstract over the returned SIMD register (those could in turn be used as storage types for SIMD-enabled types). (Some crates like wide provide such types but from my understanding one of the goal of glam is to not pull any mandatory dependency?)
  • Casting back to an array of scalar values, from some quick testing this does not seems to block SIMD optimization but I wonder if in some cases that could lead to a loss of performance if the returned value is passed again to a packed-type due to the looser alignment constraints.

[bitshifter]

Hi,

It's not currently planned.

I don't really have the time to put into writing it myself and even consuming a PR and maintaining a large feature like this could be more time than I have to commit to glam right now. There's nothing stopping someone from making their own crate with glam compatible wide types though and I can certainly try to assist any effort like that.

I think unless you are targeting a fixed hardware architecture something like ISPC would probably be a better option than fixed width vectors in that it would allow you to write the code once and produce assembly for multiple SIMD ISAs and select the appropriate one at runtime or compile time, depending on what architecture you are targeting. This would give a more flexibility than fixed sized vector types, which would require you to write multiple implementations with different widths and choose the appropriate one to use. IPSC would take care of that for you.

In C++ there are dynamic length vector SIMD libraries like Google Highway does something similar to ISPC but without introducing another language. I haven't seen anything similar written in Rust, yet.

If I did have time that's the area I would like to look into, I don't see that happening any time soon unfortunately.

[Kanabenki]

I see, thanks for the detailed answer !