ARM Skia NEON patches - 29 - Xfermode: SkFourByteInterp

src/opts/SkXfermode_opts_arm_neon.cpp

Index: src/opts/SkXfermode_opts_arm_neon.cpp
diff --git a/src/opts/SkXfermode_opts_arm_neon.cpp b/src/opts/SkXfermode_opts_arm_neon.cpp
index b8d8ef521b2a48310223f87f3ee58c2ad1b7ef1b..7435dd44de102af82ac3af028fb57da1be8ac7a4 100644
--- a/src/opts/SkXfermode_opts_arm_neon.cpp
+++ b/src/opts/SkXfermode_opts_arm_neon.cpp
@@ -632,7 +632,7 @@ void SkNEONProcCoeffXfermode::xfer32(SkPMColor dst[], const SkPMColor src[],
                 SkPMColor dstC = dst[i];
                 SkPMColor C = proc(src[i], dstC);
                 if (a != 0xFF) {

[reed1, 2013/12/02 16:25:42]

Does this test/branch help in the neon case? Just wondering.

[kevin.petit.not.used.account, 2013/12/02 16:59:45]

For this change: yes.

If you were thinking of the full NEON case (which is not that change): nope.
It's the even the contrary though honestly it has a small impact compared to the
"0 != a" test just above it. The more if/else, the slower the NEON code will be.

For example, assume a code like this one:

if (want_to_do_it) {
    if (foo)
        result = fn1(data);
    else
        result = fn2(data);
}

When unrolling such a code in a loop using NEON, you have to compute fn1(data)
AND fn2(data) even if want_to_do_it is false for all the input data. ARMv8
allows to special-case in the latter case but at the expense of a slight cost.

-                    C = SkFourByteInterp(C, dstC, a);
+                    C = SkFourByteInterp_neon(C, dstC, a);
                 }
                 dst[i] = C;
             }
@@ -700,7 +700,7 @@ void SkNEONProcCoeffXfermode::xfer16(uint16_t* SK_RESTRICT dst,
                 SkPMColor dstC = SkPixel16ToPixel32(dst[i]);
                 SkPMColor C = proc(src[i], dstC);
                 if (0xFF != a) {
-                    C = SkFourByteInterp(C, dstC, a);
+                    C = SkFourByteInterp_neon(C, dstC, a);
                 }
                 dst[i] = SkPixel32ToPixel16_ToU16(C);
             }