0

So when I was working with buffers I was having something like UnsafeRawPointer (which consisted of SCNVector3) and I was casting it to UnsafeBufferPointer<SIMD3<Float>>. And then I saw that my function that reads information from that produces wrong results.

Then I've tried that:

MemoryLayout<SCNVector3>.size // 12
MemoryLayout<SCNVector3>.stride // 12

MemoryLayout<SIMD3<Float>>.size //16
MemoryLayout<SIMD3<Float>>.stride //16

And I don't get it why SIMD3 is 16 if it's only consists of 3 Floats.

Also found this on official docs but it seems wrong 'cuz it produces 12 on iPhone and M1 Important

SCNVector3. In macOS, the x, y, and z fields in this structure are CGFloat values. In iOS, tvOS, and watchOS, these fields are Float values.

  • 1
    Possibly helpful: https://stackoverflow.com/questions/74314930/how-to-deal-with-the-lack-of-simd-packed-float3-in-swift One of the answers includes this statement “By the way, simd_float3 is 16 bytes everywhere, simd types have stricter alignment requirements.” – Geoff Hackworth Apr 14 '23 at 13:02
  • 1
    128 bits is a really common SIMD lane size. If you're using SIMD types, you're presumably doing it for the perf benefit. Modelling 3 floats with 16 bytes instead of 12 does 'waste' 4 bytes of padding, but it saves you from needing to expand out and contract back the result every time you want to do SIMD operations on it – Alexander Apr 14 '23 at 17:26
  • Guys thanks for the answers. It's clear for me now! – Dzmitry Valkovich Apr 17 '23 at 07:52

0 Answers0