Optimize RGB16 blitH functions with NEON for ARM platform.

Optimize RGB16 blitH functions with NEON for ARM platform.

Here are some performance resultsi on Nexus 9:
SkRGB16BlitterBlitH_neon:
    +--------+-----------+
    |height  |  C/NEON   |
    +--------+-----------+
    |1       | 0.888531  |
    +--------+-----------+
    |8       | 1.231800  |
    +--------+-----------+
    |18      | 1.073327  |
    +--------+-----------+
    |32      | 1.136991  |
    +--------+-----------+
    |76      | 1.174638  |
    +--------+-----------+
    |85      | 1.188551  |
    +--------+-----------+
    |120     | 1.180261  |
    +--------+-----------+
    |128     | 1.183726  |
    +--------+-----------+
    |512     | 1.220806  |
    +--------+-----------+

BUG=skia:

Committed: https://skia.googlesource.com/skia/+/6c72d5740231f47c664a8e765a8df05cd124c88c

[yang.zhang, 2015-07-16 03:48:00]

yang.zhang@linaro.org changed reviewers:
+ bero@linaro.com, caryclark@google.com, djsollen@google.com,
mtklein@google.com, reed@google.com

[yang.zhang, 2015-07-29 02:35:27]

On 2015/07/16 03:48:00, yang.zhang wrote:

Hi mtklein

Any comments?

[mtklein, 2015-07-29 14:07:12]

https://codereview.chromium.org/1229673008/diff/1/src/core/SkBlitter_RGB16.cpp
File src/core/SkBlitter_RGB16.cpp (right):

https://codereview.chromium.org/1229673008/diff/1/src/core/SkBlitter_RGB16.cp...
src/core/SkBlitter_RGB16.cpp:612: #if SK_ARM_NEON_IS_ALWAYS &&
defined(SK_CPU_LENDIAN)
This is fine, but we basically make no attempt to support big-endian anymore. 
I'm not sure it'd even compile.

https://codereview.chromium.org/1229673008/diff/1/src/opts/SkBlitMask_opts_ar...
File src/opts/SkBlitMask_opts_arm_neon.cpp (right):

https://codereview.chromium.org/1229673008/diff/1/src/opts/SkBlitMask_opts_ar...
src/opts/SkBlitMask_opts_arm_neon.cpp:337: int height,
Let's call this width or count or n?  height is rather confusing, given that
we're moving horizontally.

[yang.zhang, 2015-07-30 05:35:34]

https://codereview.chromium.org/1229673008/diff/1/src/core/SkBlitter_RGB16.cpp
File src/core/SkBlitter_RGB16.cpp (right):

https://codereview.chromium.org/1229673008/diff/1/src/core/SkBlitter_RGB16.cp...
src/core/SkBlitter_RGB16.cpp:612: #if SK_ARM_NEON_IS_ALWAYS &&
defined(SK_CPU_LENDIAN)
On 2015/07/29 14:07:11, mtklein wrote:
> This is fine, but we basically make no attempt to support big-endian anymore. 
> I'm not sure it'd even compile.

I have verified that this NEON function can be compiled.

https://codereview.chromium.org/1229673008/diff/1/src/opts/SkBlitMask_opts_ar...
File src/opts/SkBlitMask_opts_arm_neon.cpp (right):

https://codereview.chromium.org/1229673008/diff/1/src/opts/SkBlitMask_opts_ar...
src/opts/SkBlitMask_opts_arm_neon.cpp:337: int height,
On 2015/07/29 14:07:11, mtklein wrote:
> Let's call this width or count or n?  height is rather confusing, given that
> we're moving horizontally.

Done.

[mtklein, 2015-07-30 12:29:05]

lgtm

FYI, I've been writing some new code to wrap SIMD instructions in a
platform-independent way (see SkNx.h, SkPMFloat.h, Sk4px.h).  I've started
converting parts of Skia over to use it (see Sk4pxXfermode.h) with good success.
 I hope to have some docs up on skia.org soon.

At some point we will start asking that all SIMD code in Skia go through these
platform-independent SIMD wrappers so that we get uniform speedups (and more
importantly,uniform results) on NEON, SSE, MIPS, etc.  We're not there yet, but
if you're planning on contributing more NEON 565 procs, it'd probably be a good
idea to start looking at those wrappers.

https://codereview.chromium.org/1229673008/diff/1/src/core/SkBlitter_RGB16.cpp
File src/core/SkBlitter_RGB16.cpp (right):

https://codereview.chromium.org/1229673008/diff/1/src/core/SkBlitter_RGB16.cp...
src/core/SkBlitter_RGB16.cpp:612: #if SK_ARM_NEON_IS_ALWAYS &&
defined(SK_CPU_LENDIAN)
On 2015/07/30 05:35:34, yang.zhang wrote:
> On 2015/07/29 14:07:11, mtklein wrote:
> > This is fine, but we basically make no attempt to support big-endian
anymore. 
> > I'm not sure it'd even compile.
> 
> I have verified that this NEON function can be compiled.

(Sorry, I meant "whether Skia'd even compile for big-endian".  Anyway, no big
deal.)

[mtklein, 2015-07-30 12:29:15]

The CQ bit was checked by mtklein@google.com

[commit-bot: I haz the power, 2015-07-30 12:29:23]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1229673008/20001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1229673008/20001

[commit-bot: I haz the power, 2015-07-30 12:37:09]

Committed patchset #2 (id:20001) as
https://skia.googlesource.com/skia/+/6c72d5740231f47c664a8e765a8df05cd124c88c

[mtklein, 2015-07-30 14:03:06]

A revert of this CL (patchset #2 id:20001) has been created in
https://codereview.chromium.org/1268513003/ by mtklein@google.com.

The reason for reverting is: This doesn't draw correctly, e.g. our GM test named
dashcubics.

Good: https://gold.skia.org/img/images/0f7e8e226379afbad8a700e0a80fd8f1.png

Bad:
https://gold.skia.org/img/images/56ce15fc67436065a3db4b8ee31f13ae.png.