SSE2 implementation of memcpy32

SSE2 implementation of memcpy32

With SSE2 version memcpy32, S32_Opaque_BlitRow32() in SkBlitRow_D32.cpp
has about 30% performance improvement. Here are the data on desktop
i7-3770.
before:
       bitmap_scale_filter_90_90   8888:  cmsecs =      2.01
      bitmaprect_FF_filter_trans   8888:  cmsecs =      3.61
    bitmaprect_FF_nofilter_trans   8888:  cmsecs =      3.57
   bitmaprect_FF_filter_identity   8888:  cmsecs =      3.53
 bitmaprect_FF_nofilter_identity   8888:  cmsecs =      3.53
              bitmap_4444_update   8888:  cmsecs =      4.84
     bitmap_4444_update_volatile   8888:  cmsecs =      4.81
                     bitmap_4444   8888:  cmsecs =      4.81
after:
       bitmap_scale_filter_90_90   8888:  cmsecs =      1.83
      bitmaprect_FF_filter_trans   8888:  cmsecs =      2.36
    bitmaprect_FF_nofilter_trans   8888:  cmsecs =      2.36
   bitmaprect_FF_filter_identity   8888:  cmsecs =      2.60
 bitmaprect_FF_nofilter_identity   8888:  cmsecs =      2.63
              bitmap_4444_update   8888:  cmsecs =      3.30
     bitmap_4444_update_volatile   8888:  cmsecs =      3.30
                     bitmap_4444   8888:  cmsecs =      3.29

BUG=skia:

Committed: http://code.google.com/p/skia/source/detail?r=14822

[qiankun, 2014-05-15 07:46:43]

PTAL.

[mtklein, 2014-05-15 15:38:30]

So, I can reproduce improvements in those bitmap_ benches, but I don't
understand it and am suspicious.  We've always figured memcpy would handle the
vectorization for us.  I just sent out a benchmark focused on only memcpy32, and
I sort of can't get it to go slow no matter how I implement it, manually
(aligned and unaligned), autovectorized, or just calling memcpy.

https://codereview.chromium.org/285313002/diff/1/src/opts/SkUtils_opts_SSE2.cpp
File src/opts/SkUtils_opts_SSE2.cpp (right):

https://codereview.chromium.org/285313002/diff/1/src/opts/SkUtils_opts_SSE2.c...
src/opts/SkUtils_opts_SSE2.cpp:81: __m128i src_pixel1 =  _mm_loadu_si128(s++);
src_pixelN seems like a misleading name, as it's really 4 pixels.  I wouldn't
mind something neutral like 
__m128i a = ... ;
__m128i b = ... ;

https://codereview.chromium.org/285313002/diff/1/src/opts/SkUtils_opts_SSE2.c...
src/opts/SkUtils_opts_SSE2.cpp:86: _mm_store_si128(d    , src_pixel1);
Any chance you compared _mm_store and _mm_stream here?  Last I checked,
_mm_store was much, much better, but that may be an artifact of
microbenchmarking being really cache friendly.

https://codereview.chromium.org/285313002/diff/1/src/opts/SkUtils_opts_SSE2.c...
src/opts/SkUtils_opts_SSE2.cpp:86: _mm_store_si128(d    , src_pixel1);
For symmetry with s, maybe _mm_store_si128(d++, ...) here instead of += 4 below?

https://codereview.chromium.org/285313002/diff/1/src/opts/opts_check_x86.cpp
File src/opts/opts_check_x86.cpp (right):

https://codereview.chromium.org/285313002/diff/1/src/opts/opts_check_x86.cpp#...
src/opts/opts_check_x86.cpp:315: if (cachedHasSSE2()) {
Once you rebase this will be if (supports_simd(SK_CPU_SSE_LEVEL_SSE2)) { ...

[qiankun, 2014-05-20 09:35:29]

Not sure why the microbenchmark of different memcpy_* perform almost same.

https://codereview.chromium.org/285313002/diff/1/src/opts/SkUtils_opts_SSE2.cpp
File src/opts/SkUtils_opts_SSE2.cpp (right):

https://codereview.chromium.org/285313002/diff/1/src/opts/SkUtils_opts_SSE2.c...
src/opts/SkUtils_opts_SSE2.cpp:81: __m128i src_pixel1 =  _mm_loadu_si128(s++);
On 2014/05/15 15:38:30, mtklein wrote:
> src_pixelN seems like a misleading name, as it's really 4 pixels.  I wouldn't
> mind something neutral like 
> __m128i a = ... ;
> __m128i b = ... ;

Done.

https://codereview.chromium.org/285313002/diff/1/src/opts/SkUtils_opts_SSE2.c...
src/opts/SkUtils_opts_SSE2.cpp:86: _mm_store_si128(d    , src_pixel1);
On 2014/05/15 15:38:30, mtklein wrote:
> For symmetry with s, maybe _mm_store_si128(d++, ...) here instead of += 4
below?

Done.

https://codereview.chromium.org/285313002/diff/1/src/opts/SkUtils_opts_SSE2.c...
src/opts/SkUtils_opts_SSE2.cpp:86: _mm_store_si128(d    , src_pixel1);
On 2014/05/15 15:38:30, mtklein wrote:
> Any chance you compared _mm_store and _mm_stream here?  Last I checked,
> _mm_store was much, much better, but that may be an artifact of
> microbenchmarking being really cache friendly.

At my side, _mm_store is better than _mm_stream too.

https://codereview.chromium.org/285313002/diff/1/src/opts/opts_check_x86.cpp
File src/opts/opts_check_x86.cpp (right):

https://codereview.chromium.org/285313002/diff/1/src/opts/opts_check_x86.cpp#...
src/opts/opts_check_x86.cpp:315: if (cachedHasSSE2()) {
On 2014/05/15 15:38:30, mtklein wrote:
> Once you rebase this will be if (supports_simd(SK_CPU_SSE_LEVEL_SSE2)) { ...

Done.

[mtklein, 2014-05-20 14:25:42]

On 2014/05/20 09:35:29, qiankun wrote:
> Not sure why the microbenchmark of different memcpy_* perform almost same.

Hmm. OK.  Let's investigate that in parallel.  LGTM.

[qiankun, 2014-05-21 02:00:46]

The CQ bit was checked by qiankun.miao@intel.com

[commit-bot: I haz the power, 2014-05-21 02:01:24]

CQ is trying da patch. Follow status at
 https://skia-tree-status.appspot.com/cq/qiankun.miao@intel.com/285313002/20001

[commit-bot: I haz the power, 2014-05-21 02:01:39]

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

[commit-bot: I haz the power, 2014-05-21 02:01:40]

Presubmit check for 285313002-20001 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')

Presubmit checks took 10.7s to calculate.

Was the presubmit check useful? If not, run "git cl presubmit -v"
to figure out which PRESUBMIT.py was run, then run git blame
on the file to figure out who to ask for help.

[qiankun, 2014-05-21 02:22:49]

On 2014/05/21 02:01:40, I haz the power (commit-bot) wrote:
> Presubmit check for 285313002-20001 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:
> (mailto:, mailto:, mailto:,
> mailto:)
> 
> Presubmit checks took 10.7s to calculate.
> 
> Was the presubmit check useful? If not, run "git cl presubmit -v"
> to figure out which PRESUBMIT.py was run, then run git blame
> on the file to figure out who to ask for help.

reed && bsalomon, this need your review.

[reed1, 2014-05-21 12:38:02]

api lgtm

We should consider moving most of this (in SkUtils.h) into a private header --
no need to expose our trickery to public clients.

[reed1, 2014-05-21 12:38:09]

The CQ bit was checked by reed@google.com

[commit-bot: I haz the power, 2014-05-21 12:38:54]

CQ is trying da patch. Follow status at
 https://skia-tree-status.appspot.com/cq/qiankun.miao@intel.com/285313002/20001

[commit-bot: I haz the power, 2014-05-21 12:43:09]

Change committed as 14822

[f(malita), 2014-05-21 20:30:54]

On 2014/05/21 12:43:09, I haz the power (commit-bot) wrote:
> Change committed as 14822

Perf-ChromeOS-Alex is crashing in memcpy32_sse2_unalign_10 after this:
http://108.170.220.120:10117/builders/Perf-ChromeOS-Alex-GMA3150-x86-Release/...

(although the blame list points somewhere nearby, we have reasons not to trust
it)

[f(malita), 2014-05-22 12:55:21]

On 2014/05/21 20:30:54, Florin Malita wrote:
> On 2014/05/21 12:43:09, I haz the power (commit-bot) wrote:
> > Change committed as 14822
> 
> Perf-ChromeOS-Alex is crashing in memcpy32_sse2_unalign_10 after this:
>
http://108.170.220.120:10117/builders/Perf-ChromeOS-Alex-GMA3150-x86-Release/...
> 
> (although the blame list points somewhere nearby, we have reasons not to trust
> it)

After running a revert test for this CL, the bot is still crashing. So the
initial blame is misplaced - sorry about the noise.