ARM Skia NEON patches - 39 - arm64 565 blitters

ARM Skia NEON patches - 39 - arm64 565 blitters

This enables all 565 blitters except S32A_D565_Opaque.

Here are some performance results:

S32_D565_Opaque:
================

+-------+------------+------------+
| count | Cortex-A53 | Cortex-A57 |
+-------+------------+------------+
|     1 |    -18.37% |    -13.04% |
+-------+------------+------------+
|     2 |     -9.90% |    -13.78% |
+-------+------------+------------+
|     4 |     -8.28% |     -6.77% |
+-------+------------+------------+
|     8 |    157.63% |     78.15% |
+-------+------------+------------+
|    16 |     72.67% |     44.81% |
+-------+------------+------------+
|    64 |     76.78% |     40.89% |
+-------+------------+------------+
|   256 |     73.85% |     36.05% |
+-------+------------+------------+
|  1024 |     75.73% |     36.70% |
+-------+------------+------------+

S32_D565_Blend:
===============

+-------+------------+------------+
| count | Cortex-A53 | Cortex-A57 |
+-------+------------+------------+
|     1 |     -9.99% |    -13.79% |
+-------+------------+------------+
|     2 |     -9.17% |     -6.74% |
+-------+------------+------------+
|     4 |     -6.73% |     -4.42% |
+-------+------------+------------+
|     8 |    163.31% |    112.82% |
+-------+------------+------------+
|    16 |     55.21% |     44.68% |
+-------+------------+------------+
|    64 |     54.09% |     41.99% |
+-------+------------+------------+
|   256 |     52.63% |     40.64% |
+-------+------------+------------+
|  1024 |     52.46% |     40.45% |
+-------+------------+------------+

S32A_D565_Blend:
================

+-------+------------+------------+
| count | Cortex-A53 | Cortex-A57 |
+-------+------------+------------+
|     1 |     -5.88% |     -6.06% |
+-------+------------+------------+
|     2 |     -4.74% |     -0.01% |
+-------+------------+------------+
|     4 |     -5.42% |     -3.03% |
+-------+------------+------------+
|     8 |     78.78% |     77.96% |
+-------+------------+------------+
|    16 |     98.19% |     79.61% |
+-------+------------+------------+
|    64 |    111.56% |     72.60% |
+-------+------------+------------+
|   256 |    113.80% |     69.96% |
+-------+------------+------------+
|  1024 |    114.42% |     70.85% |
+-------+------------+------------+

S32_D565_Opaque_Dither:
=======================

+-------+------------+------------+
| count | Cortex-A53 | Cortex-A57 |
+-------+------------+------------+
|     1 |     -4.18% |     -0.93% |
+-------+------------+------------+
|     2 |     -2.43% |     -2.04% |
+-------+------------+------------+
|     4 |     -1.09% |     -1.23% |
+-------+------------+------------+
|     8 |    184.89% |    136.53% |
+-------+------------+------------+
|    16 |    128.64% |     89.11% |
+-------+------------+------------+
|    64 |    132.68% |    100.98% |
+-------+------------+------------+
|   256 |    157.02% |    100.86% |
+-------+------------+------------+
|  1024 |    163.85% |    103.62% |
+-------+------------+------------+

S32_D565_Blend_Dither:
======================

+-------+------------+------------+
| count | Cortex-A53 | Cortex-A57 |
+-------+------------+------------+
|     1 |     -4.87% |      0.01% |
+-------+------------+------------+
|     2 |     -2.71% |      2.97% |
+-------+------------+------------+
|     4 |     -2.20% |      0.28% |
+-------+------------+------------+
|     8 |    149.76% |    146.80% |
+-------+------------+------------+
|    16 |     85.69% |     95.77% |
+-------+------------+------------+
|    64 |     88.81% |    101.39% |
+-------+------------+------------+
|   256 |     97.32% |    107.22% |
+-------+------------+------------+
|  1024 |     98.08% |    115.71% |
+-------+------------+------------+

S32A_D565_Opaque_Dither:
========================

+-------+------------+------------+
| count | Cortex-A53 | Cortex-A57 |
+-------+------------+------------+
|     1 |     -1.86% |      0.02% |
+-------+------------+------------+
|     2 |     -0.58% |     -1.52% |
+-------+------------+------------+
|     4 |     -0.75% |      1.16% |
+-------+------------+------------+
|     8 |    240.74% |    155.16% |
+-------+------------+------------+
|    16 |    181.97% |    132.15% |
+-------+------------+------------+
|    64 |    203.11% |    136.48% |
+-------+------------+------------+
|   256 |    223.45% |    133.05% |
+-------+------------+------------+
|  1024 |    225.96% |    134.05% |
+-------+------------+------------+

Signed-off-by: Kévin PETIT <kevin.petit@arm.com>;

BUG=skia:

Committed: https://skia.googlesource.com/skia/+/ea6b46b6c06fd9e03b98f01b274733de1eeae89d

[kevin.petit, 2014-06-05 16:18:33]

This enables most 565 blitters on arm64. The mismatches are due only to
S32A_D565_Blend which uses the same approximation as arm32.

[mtklein, 2014-06-05 16:28:35]

https://codereview.chromium.org/317193003/diff/10001/src/opts/SkBlitRow_opts_...
File src/opts/SkBlitRow_opts_arm_neon.cpp (right):

https://codereview.chromium.org/317193003/diff/10001/src/opts/SkBlitRow_opts_...
src/opts/SkBlitRow_opts_arm_neon.cpp:33: "ld4    {v0.8b - v3.8b}, [%[src]] \t\n"
Looks like we've got the same load-32-bytes thing going on here several times. 
Any way we can abstract out this whole #ifdef-#else-#endif block as an inline
function?  Seems like the main difference is that some post-increment and some
manually increment src?

[kevin.petit, 2014-06-05 17:00:02]

https://codereview.chromium.org/317193003/diff/10001/src/opts/SkBlitRow_opts_...
File src/opts/SkBlitRow_opts_arm_neon.cpp (right):

https://codereview.chromium.org/317193003/diff/10001/src/opts/SkBlitRow_opts_...
src/opts/SkBlitRow_opts_arm_neon.cpp:33: "ld4    {v0.8b - v3.8b}, [%[src]] \t\n"
On 2014/06/05 16:28:36, mtklein wrote:
> Looks like we've got the same load-32-bytes thing going on here several times.

> Any way we can abstract out this whole #ifdef-#else-#endif block as an inline
> function?  Seems like the main difference is that some post-increment and some
> manually increment src?

There are actually a few more differences. Some use only 24bytes, some the full
32.

Factorising the whole #ifdef-#else-#endif would be ideal but would require quite
a lot of regression testing (the blocks are slightly different from function to
function with a measurable impact on performance) on arm32 which I don't really
have the time to do right now (although that's definitely on the list of things
I want to do). I'll try to make something sensible for the SK_ARM_CPU64 case.

BTW, do you know if Skia still has to support gcc4.6?

[kevin.petit, 2014-06-06 14:31:11]

On 2014/06/05 17:00:02, kevin.petit wrote:
>
https://codereview.chromium.org/317193003/diff/10001/src/opts/SkBlitRow_opts_...
> File src/opts/SkBlitRow_opts_arm_neon.cpp (right):
> 
>
https://codereview.chromium.org/317193003/diff/10001/src/opts/SkBlitRow_opts_...
> src/opts/SkBlitRow_opts_arm_neon.cpp:33: "ld4    {v0.8b - v3.8b}, [%[src]]
\t\n"
> On 2014/06/05 16:28:36, mtklein wrote:
> > Looks like we've got the same load-32-bytes thing going on here several
times.
> 
> > Any way we can abstract out this whole #ifdef-#else-#endif block as an
inline
> > function?  Seems like the main difference is that some post-increment and
some
> > manually increment src?
> 
> There are actually a few more differences. Some use only 24bytes, some the
full
> 32.
> 
> Factorising the whole #ifdef-#else-#endif would be ideal but would require
quite
> a lot of regression testing (the blocks are slightly different from function
to
> function with a measurable impact on performance) on arm32 which I don't
really
> have the time to do right now (although that's definitely on the list of
things
> I want to do). I'll try to make something sensible for the SK_ARM_CPU64 case.
> 
> BTW, do you know if Skia still has to support gcc4.6?

I've pushed a revised version. It definitely looks better, thanks for pushing me
:-).
I've even managed to get something like 1-2% perf on top the existing figures.

[mtklein, 2014-06-06 14:41:17]

lgtm

https://codereview.chromium.org/317193003/diff/20001/src/opts/SkBlitRow_opts_...
File src/opts/SkBlitRow_opts_arm_neon.cpp (right):

https://codereview.chromium.org/317193003/diff/20001/src/opts/SkBlitRow_opts_...
src/opts/SkBlitRow_opts_arm_neon.cpp:405: #if (__GNUC__ > 4) || ((__GNUC__ == 4)
&& (__GNUC_MINOR__ > 6))
Think it makes sense to follow up and do the same for 32-bit side, given that we
have what looks like a couple different strategies here too?  Then all the code
can call sk_vld4_u8_3 or sk_vld4_u8_4 as needed?

[kevin.petit, 2014-06-06 15:20:42]

On 2014/06/06 14:41:17, mtklein wrote:
> lgtm
> 
>
https://codereview.chromium.org/317193003/diff/20001/src/opts/SkBlitRow_opts_...
> File src/opts/SkBlitRow_opts_arm_neon.cpp (right):
> 
>
https://codereview.chromium.org/317193003/diff/20001/src/opts/SkBlitRow_opts_...
> src/opts/SkBlitRow_opts_arm_neon.cpp:405: #if (__GNUC__ > 4) || ((__GNUC__ ==
4)
> && (__GNUC_MINOR__ > 6))
> Think it makes sense to follow up and do the same for 32-bit side, given that
we
> have what looks like a couple different strategies here too?  Then all the
code
> can call sk_vld4_u8_3 or sk_vld4_u8_4 as needed?

Yep, I would love to do that but I won't unless I can prove it doesn't affect
benchmarks (this has proven to be very sensitive). That will go on the TODO list
for now.

[kevin.petit, 2014-06-06 15:20:54]

The CQ bit was checked by kevin.petit@arm.com

[commit-bot: I haz the power, 2014-06-06 15:21:55]

CQ is trying da patch. Follow status at
 https://skia-tree-status.appspot.com/cq/kevin.petit@arm.com/317193003/20001

[commit-bot: I haz the power, 2014-06-06 15:45:42]

Change committed as ea6b46b6c06fd9e03b98f01b274733de1eeae89d