arm: dynamic NEON support for SkBitmapProcState functions.

arm: dynamic NEON support for SkBitmapProcState functions.

This patch does the following:

  - Move the NEON-specific code from src/core/SkBitmapProcState_filter.h
    to src/opts/SkBitmapProcState_filter_neon.h

  - Implement the NEON-specific functions in the new source file
    src/opts/SkBitmapProcState_opts_arm_neon.cpp, added to the "opts_neon"
    static library target. All functions now use the _neon suffix, even
    in full-NEON builds.

  - Move most of the content of src/core/SkBitmapProcState.cpp to a
    new header: src/core/SkBitmapProcState_procs.h

This header is included by two source files:

  src/core/SkBitmapProcState.cpp, to define the regular functions.
  src/opts/SkBitmapProcState_opts_arm_neon.cpp to define NEON ones.

This is to deal with the fact that all NEON functions now
use the _neon suffix, even in SK_ARM_NEON_IS_ALWAYS mode,
and to be able to include the same header twice in the
SK_ARM_NEON_IS_DYNAMIC case.
Committed: https://code.google.com/p/skia/source/detail?r=5055

[digit1, 2012-08-08 22:33:03]

For the record, this is the final patch that moves all NEON-related code into
the opts_neon library.

[reed1, 2012-08-09 12:24:37]

What are the bench runs before and after this change?

[DerekS, 2012-08-10 12:11:12]

lgtm.  On a side note I have a couple of patches from NVidia that were pushed in
the Android copy of Skia that I'm going to upstream.  I'll add you to those CL's
so that you can validate that I'm using your macro's and new library structure
the way you intended.

[digit1, 2012-08-13 14:03:53]

To answer Mike's question, I've run a few benchmarks. Results available at
https://docs.google.com/a/chromium.org/spreadsheet/ccc?key=0Arp73PHrzcIQdGJtV...

For the record, there seems to be a lot of variance in some of the test results,
not sure if this is due to background processes on the device or something else.
In all cases, the patch doesn't seem to regress performance though.

[reed1, 2012-08-13 14:55:05]

On 2012/08/13 14:03:53, digit1 wrote:
> To answer Mike's question, I've run a few benchmarks. Results available at
>
https://docs.google.com/a/chromium.org/spreadsheet/ccc?key=0Arp73PHrzcIQdGJtV...
> 
> For the record, there seems to be a lot of variance in some of the test
results,
> not sure if this is due to background processes on the device or something
else.
> In all cases, the patch doesn't seem to regress performance though.

-repeat 5 is almost certainly too small a value (because of variance). We
typically run with repeats of 10-50x that value.

[reed1, 2012-08-13 14:56:27]

On 2012/08/13 14:55:05, reed1 wrote:
> On 2012/08/13 14:03:53, digit1 wrote:
> > To answer Mike's question, I've run a few benchmarks. Results available at
> >
>
https://docs.google.com/a/chromium.org/spreadsheet/ccc?key=0Arp73PHrzcIQdGJtV...
> > 
> > For the record, there seems to be a lot of variance in some of the test
> results,
> > not sure if this is due to background processes on the device or something
> else.
> > In all cases, the patch doesn't seem to regress performance though.
> 
> -repeat 5 is almost certainly too small a value (because of variance). We
> typically run with repeats of 10-50x that value.

The Xoom results have their fair-share of performance loss.