arm: dynamic NEON support for SkBitmapProcState matrix operations.

arm: dynamic NEON support for SkBitmapProcState matrix operations.

This patch implements dynamic ARM NEON support for the functions
implemented by src/core/SkBitmapProcState_matrixProcs.cpp.

 - Because the SkBitmapProcState_matrix_{clamp,repeat}.h headers
   are NEON-specific, they are renamed with a _neon.h suffix, and
   moved to src/opts/ (from src/core/)

 - Add a new file src/opts/SkBitmapProcState_matrixProcs_neon.cpp
   which implements the NEON code paths for all builds, and add
   it to the 'opts_neon' static library.

 - Modify SkBitmapProcState_matrixProcs.cpp to select the right
   code-path depending on our build configuration. Note that in
   the case where 'arm_neon == 1', we do not embed regular ARM
   code paths in the final binary. Only 'arm_neon_optional == 1'
   builds will contain both regular and NEON code paths at the
   same time.

Note that there doesn't seem to be a simple way to put the
NEON-specific selection from that currently is in
SkBitmapProcState_matrixProcs.cpp into src/opts/. Doing so
would require much more drastic restructuring. This is also
true of the other SkBitmapProcState source files that will
be touched in a future patch.
Committed: https://code.google.com/p/skia/source/detail?r=4888

[digit1, 2012-07-31 16:39:44]

This is a slight reimplementation of http://codereview.appspot.com/6262044/

The main difference is that this fixes the "code generation bug" which really
was a downshift bug in TILEX_PROCF/TILEY_PROCF that only occurs for maxX ==
65535 (fixed by using SkUSHIFT16). Damn.

Tested with the new SkAndroidApp using the following build types:

 On a Xoom tablet (running JellyBean):
     xoom
     arm_all

 On a Nexus-S (running IceCreamSandwich):
     xoom
     nexus_s
     arm_all

[DerekS, 2012-07-31 18:57:20]

https://codereview.appspot.com/6453065/diff/1/gyp/opts.gyp
File gyp/opts.gyp (right):

https://codereview.appspot.com/6453065/diff/1/gyp/opts.gyp#newcode141
gyp/opts.gyp:141: #          that currently comes with the skia 'android'
directory.
you can remove this as the android directory now uses 4.6

[digit1, 2012-08-01 09:05:54]

https://codereview.appspot.com/6453065/diff/1/gyp/opts.gyp
File gyp/opts.gyp (right):

https://codereview.appspot.com/6453065/diff/1/gyp/opts.gyp#newcode141
gyp/opts.gyp:141: #          that currently comes with the skia 'android'
directory.
On 2012/07/31 18:57:20, DerekS wrote:
> you can remove this as the android directory now uses 4.6

Yes, moreoever, this wasn't a compiler generation bug after all, so the comment
is incorrect :)

[DerekS, 2012-08-01 12:46:08]

On 2012/08/01 09:05:54, digit1 wrote:
> https://codereview.appspot.com/6453065/diff/1/gyp/opts.gyp
> File gyp/opts.gyp (right):
> 
> https://codereview.appspot.com/6453065/diff/1/gyp/opts.gyp#newcode141
> gyp/opts.gyp:141: #          that currently comes with the skia 'android'
> directory.
> On 2012/07/31 18:57:20, DerekS wrote:
> > you can remove this as the android directory now uses 4.6
> 
> Yes, moreoever, this wasn't a compiler generation bug after all, so the
comment
> is incorrect :)

lgtm

[caryclark1, 2012-08-01 12:56:00]

Digit, did you move the files (e.g., svn move
src/core/SkBitmapProcState_matrix_clamp.h
src/opts/SkBitmapProcState_matrix_clamp_neon.h) or delete and add? It's hard to
tell -- although I expected a '+' after the 'A' in the change description if it
was a move. There may be no significant difference, although it's nice to be
able to trace the history of where a file comes from.

[digit1, 2012-08-01 13:29:20]

I did the "svn rm" + "svn add", I'll try to redo this patch with a move. Thanks.

[digit1, 2012-08-01 13:43:35]

Patch set 3 seems to look good now :)

[caryclark1, 2012-08-01 13:54:27]

On 2012/08/01 13:43:35, digit1 wrote:
> Patch set 3 seems to look good now :)

Agreed. That certainly improved the diff. LGTM