Commit Graph

3 Commits

Author SHA1 Message Date
mtklein
115acee938 Sk4h and Sk8h for SSE
These will underly the SkPMFloat-like class for uint16_t components.

Sk4h will back a single-pixel version, and Sk8h any larger number than that.

BUG=skia:

Review URL: https://codereview.chromium.org/1088883005
2015-04-14 14:02:52 -07:00
mtklein
a156a8ffbe Use switch operator[](int) to kth<int>() so we can use vget_lane.
#floats

BUG=skia:
BUG=skia:3592

Review URL: https://codereview.chromium.org/1059743002
2015-04-03 06:16:13 -07:00
mtklein
c9adb05b64 Refactor Sk2x<T> + Sk4x<T> into SkNf<N,T> and SkNi<N,T>
The primary feature this delivers is SkNf and SkNd for arbitrary power-of-two N.  Non-specialized types or types larger than 128 bits should now Just Work (and we can drop in a specialization to make them faster).  Sk4s is now just a typedef for SkNf<4, SkScalar>; Sk4d is SkNf<4, double>, Sk2f SkNf<2, float>, etc.

This also makes implementing new specializations easier and more encapsulated.  We're now using template specialization, which means the specialized versions don't have to leak out so much from SkNx_sse.h  and SkNx_neon.h.

This design leaves us room to grow up, e.g to SkNf<8, SkScalar> == Sk8s, and to grown down too, to things like SkNi<8, uint16_t> == Sk8h.

To simplify things, I've stripped away most APIs (swizzles, casts, reinterpret_casts) that no one's using yet.  I will happily add them back if they seem useful.

You shouldn't feel bad about using any of the typedef Sk4s, Sk4f, Sk4d, Sk2s, Sk2f, Sk2d, Sk4i, etc.  Here's how you should feel:
  - Sk4f, Sk4s, Sk2d: feel awesome
  - Sk2f, Sk2s, Sk4d: feel pretty good

No public API changes.
TBR=reed@google.com

BUG=skia:3592

Review URL: https://codereview.chromium.org/1048593002
2015-03-30 10:50:27 -07:00