Refactor Sk2x<T> + Sk4x<T> into SkNf<N,T> and SkNi<N,T>

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
Committed: https://skia.googlesource.com/skia/+/c9adb05b64fa0bfadf9d1a782afcda470da68c9e

[mtklein, 2015-03-30 12:26:30]

The CQ bit was checked by mtklein@google.com

[commit-bot: I haz the power, 2015-03-30 12:26:42]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1048593002/220001

[commit-bot: I haz the power, 2015-03-30 12:26:42]

Note for Reviewers:
The CQ is waiting for an approval.
If you believe that the CL is not ready yet, or if you would like to L-G-T-M
with comments then please uncheck the CQ checkbox.

Waiting for LGTM from valid reviewer(s) till 2015-03-30 18:26 UTC

[mtklein, 2015-03-30 12:27:06]

The CQ bit was unchecked by mtklein@google.com

[mtklein, 2015-03-30 14:09:39]

The CQ bit was checked by mtklein@google.com

[commit-bot: I haz the power, 2015-03-30 14:09:48]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1048593002/240001

[commit-bot: I haz the power, 2015-03-30 14:09:49]

Note for Reviewers:
The CQ is waiting for an approval.
If you believe that the CL is not ready yet, or if you would like to L-G-T-M
with comments then please uncheck the CQ checkbox.

Waiting for LGTM from valid reviewer(s) till 2015-03-30 20:09 UTC

[commit-bot: I haz the power, 2015-03-30 14:09:58]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-03-30 14:09:59]

Presubmit check for 1048593002-240001 failed and returned exit status 1.

Running presubmit commit checks ...

** Presubmit ERRORS **
Since the CL is editing public API, you must have an LGTM from one of:
('reed@chromium.org', 'reed@google.com', 'bsalomon@chromium.org',
'bsalomon@google.com', 'djsollen@chromium.org', 'djsollen@google.com')

[mtklein, 2015-03-30 14:49:37]

The CQ bit was checked by mtklein@google.com

[commit-bot: I haz the power, 2015-03-30 14:49:47]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1048593002/240001

[commit-bot: I haz the power, 2015-03-30 14:56:35]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-03-30 14:56:36]

This issue passed the CQ dry run.

[mtklein, 2015-03-30 15:31:18]

The CQ bit was checked by mtklein@google.com

[commit-bot: I haz the power, 2015-03-30 15:31:25]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1048593002/260001

[commit-bot: I haz the power, 2015-03-30 15:49:14]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-03-30 15:49:15]

This issue passed the CQ dry run.

[mtklein, 2015-03-30 16:53:08]

The CQ bit was checked by mtklein@google.com

[commit-bot: I haz the power, 2015-03-30 16:53:28]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1048593002/280001

[commit-bot: I haz the power, 2015-03-30 16:55:30]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-03-30 16:55:31]

Try jobs failed on following builders:
  Build-Ubuntu-GCC-Arm7-Debug-Android-Trybot on client.skia.compile (JOB_FAILED,
http://build.chromium.org/p/client.skia.compile/builders/Build-Ubuntu-GCC-Arm...)

[mtklein, 2015-03-30 16:57:10]

The CQ bit was checked by mtklein@google.com

[commit-bot: I haz the power, 2015-03-30 16:57:25]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1048593002/300001

[mtklein, 2015-03-30 17:44:42]

The CQ bit was checked by mtklein@google.com

[commit-bot: I haz the power, 2015-03-30 17:44:49]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1048593002/340001

[commit-bot: I haz the power, 2015-03-30 17:50:31]

Committed patchset #18 (id:340001) as
https://skia.googlesource.com/skia/+/c9adb05b64fa0bfadf9d1a782afcda470da68c9e

[reed2, 2015-03-30 19:55:12]

reed@chromium.org changed reviewers:
+ reed@chromium.org

[reed2, 2015-03-30 19:55:13]

My interpreation of 's' is that scalar may be float or double, hence we use
'scalar'.

Colors need never be done with doubles -- I think floats are always what they
will be (hence SkPMFloat is aptly named).

With that in mind, I think it is clearer to keep the SkPMFloat and ColorMatrix
routines using Sk4f instead of Sk4s.

[mtklein, 2015-03-30 19:57:08]

On 2015/03/30 19:55:13, reed2 wrote:
> My interpreation of 's' is that scalar may be float or double, hence we use
> 'scalar'.
> 
> Colors need never be done with doubles -- I think floats are always what they
> will be (hence SkPMFloat is aptly named).
> 
> With that in mind, I think it is clearer to keep the SkPMFloat and ColorMatrix
> routines using Sk4f instead of Sk4s.

Ah, sg.  Went a little sed-crazy.

[reed2, 2015-03-30 20:01:09]

8x and 16x seem like great additions for efficiently capturing unroll semantics.

[mtklein, 2015-03-30 20:02:18]

On 2015/03/30 20:01:09, reed2 wrote:
> 8x and 16x seem like great additions for efficiently capturing unroll
semantics.

Yep.  Should be good to just start using them now, modulo bugs.  I haven't
tested them extensively, but Sk4d works fine as a 2x unroll of Sk2d.

[reed2, 2015-03-30 20:03:02]

great change to SkMatrix.cpp, since before is was float-specific