Add SSSE3 implementation for SkPMFloat, with faster get() and set().

Add SSSE3 implementation for SkPMFloat, with faster get() and set().

With SSSE3, we can use the Swiss Army Knife byte shuffler pshufb,
a.k.a. _mm_shuffle_epi8(), to jump directly between 32 and 128 bits.

In microbench isolation, this looks like an additional 10-15% speedup:

SkPMFloat_get:   2.35ns -> 1.98ns
SkPMFloat_clamp: 2.35ns -> 2.18ns

Before this CL, get() and clamp() were identical code.  The _get benchmark improves because both set() and get() become faster; the _clamp benchmark shows the improvement from set() getting faster with clamp() staying the same.

BUG=skia:

Committed: https://skia.googlesource.com/skia/+/8c7ba092a68836c5db95c2a80b74d4f9cb475cc2

[mtklein_C, 2015-03-03 17:08:01]

mtklein@chromium.org changed reviewers:
+ msarett@google.com

[msarett, 2015-03-04 18:06:12]

lgtm

https://codereview.chromium.org/976493002/diff/80001/src/opts/SkPMFloat_SSSE3.h
File src/opts/SkPMFloat_SSSE3.h (right):

https://codereview.chromium.org/976493002/diff/80001/src/opts/SkPMFloat_SSSE3...
src/opts/SkPMFloat_SSSE3.h:17: _mm_store_ps(fColor, _mm_cvtepi32_ps(fix8_32));
As far as instructions, it looks to me like you have taken advantage of the best
ones.

I'm pretty sure that my main thoughts for improvements are the same things you
are already thinking.

Ideally, the code would be structured so that the convert hardware is always
busy (and the speed of the convert is the limiting factor).  If we pass in a
whole array of SkPMColor, setting the constant for the shuffle would be a one
time overhead.  We could perform four shuffles and four converts for every one
vector load.

If we unroll the loop appropriately to limit dependencies it is possible that
the load, shuffle, and convert could be performed in parallel (though I haven't
been able to confirm that the shuffle and convert use different hardware).  This
might get us closer to the optimum of only being constrained by the convert
step.

https://codereview.chromium.org/976493002/diff/80001/src/opts/SkPMFloat_SSSE3...
src/opts/SkPMFloat_SSSE3.h:33: fix8_16 = _mm_packus_epi16(fix8_32, fix8_32),
For lack of anything to comment on, it might be more readable to use
_mm_packus_epi32 here.  But as far as I can tell, the behavior and performance
will be identical.

[mtklein, 2015-03-04 18:10:24]

mtklein@google.com changed reviewers:
+ mtklein@google.com

[mtklein, 2015-03-04 18:10:24]

https://codereview.chromium.org/976493002/diff/80001/src/opts/SkPMFloat_SSSE3.h
File src/opts/SkPMFloat_SSSE3.h (right):

https://codereview.chromium.org/976493002/diff/80001/src/opts/SkPMFloat_SSSE3...
src/opts/SkPMFloat_SSSE3.h:17: _mm_store_ps(fColor, _mm_cvtepi32_ps(fix8_32));
On 2015/03/04 18:06:12, msarett wrote:
> As far as instructions, it looks to me like you have taken advantage of the
best
> ones.
> 
> I'm pretty sure that my main thoughts for improvements are the same things you
> are already thinking.
> 
> Ideally, the code would be structured so that the convert hardware is always
> busy (and the speed of the convert is the limiting factor).  If we pass in a
> whole array of SkPMColor, setting the constant for the shuffle would be a one
> time overhead.  We could perform four shuffles and four converts for every one
> vector load.
> 
> If we unroll the loop appropriately to limit dependencies it is possible that
> the load, shuffle, and convert could be performed in parallel (though I
haven't
> been able to confirm that the shuffle and convert use different hardware). 
This
> might get us closer to the optimum of only being constrained by the convert
> step.

+1, though keep in mind this code is inlined.   Setting the constant for the
shuffles _is_ a one time overhead if we call SkPMFloat::set() in a loop.  This
code is inlined and those non-loop-dependent ops are hoisted up.

https://codereview.chromium.org/976493002/diff/80001/src/opts/SkPMFloat_SSSE3...
src/opts/SkPMFloat_SSSE3.h:33: fix8_16 = _mm_packus_epi16(fix8_32, fix8_32),
On 2015/03/04 18:06:12, msarett wrote:
> For lack of anything to comment on, it might be more readable to use
> _mm_packus_epi32 here.  But as far as I can tell, the behavior and performance
> will be identical.

Yeah.  I'd have done that, just for the readability, but sadly _mm_packus_epi32
is SSE 4.1.  We've only got _mm_packus_16 to play with until then.

[mtklein, 2015-03-04 18:10:28]

The CQ bit was checked by mtklein@google.com

[commit-bot: I haz the power, 2015-03-04 18:11:36]

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

[commit-bot: I haz the power, 2015-03-04 18:18:12]

Committed patchset #5 (id:80001) as
https://skia.googlesource.com/skia/+/8c7ba092a68836c5db95c2a80b74d4f9cb475cc2