Replace SSE optimization of Color32A_D565

src/opts/opts_check_x86.cpp

 /*
  * Copyright 2009 The Android Open Source Project
  *
  * Use of this source code is governed by a BSD-style license that can be
  * found in the LICENSE file.
  */
 
 #include "SkBitmapFilter_opts_SSE2.h"
 #include "SkBitmapProcState_opts_SSE2.h"
 #include "SkBitmapProcState_opts_SSSE3.h"
@@ skipping 198 matching lines @@
 };
 
 SkBlitRow::Proc16 SkBlitRow::PlatformFactory565(unsigned flags) {
     if (supports_simd(SK_CPU_SSE_LEVEL_SSE2)) {
         return platform_16_procs[flags];
     } else {
         return NULL;
     }
 }
 
+static const SkBlitRow::ColorProc16 platform_565_colorprocs_SSE2[] = {
+    Color32A_D565_SSE2,                 // Color32A_D565,
+    NULL,                               // Color32A_D565_Dither
+};
+
 static const SkBlitRow::ColorProc16 platform_565_colorprocs_SSE4[] = {
     Color32A_D565_SSE4,                 // Color32A_D565,
     NULL,                               // Color32A_D565_Dither
 };
 
 SkBlitRow::ColorProc16 SkBlitRow::PlatformColorFactory565(unsigned flags) {
+/* Ironically, the 32-bit multiplication used in the SSE4 version of this
+ * optimization (MULLD) is 5-10 times slower on an Atom Silvermont, than on
+ * the Core CPUs. This makes the SSE2 version almost twice as fast on Atom.
+*/
+#if !defined(__slm__)

[mtklein, 2015/02/12 14:56:31]

Is this __slm__ for SiLverMont?  Is there a way to detect we're compiling for
Atom or Core more generally?  I know Silvermont is the only Atom chip with SSE4
today, but if we're going to start down this path, it might make sense to
generalize this guard up to the whole family.

Another option is to simply remove the SSE4 path for now.  It doesn't seem like
SSE4 makes a huge difference on Haswell (an extra 15% improvement), and we're
not really expecting much coverage of 565 on non-mobile.

[henrik.smiding, 2015/02/12 15:45:06]

Yes, it's one of the defines set by gcc/llvm when targeting Silvermont
architecture. I haven't found any better flag to check. __atom__ is only set
when targeting pre-Silvermonts. I also don't know when or if gcc/llvm will
support future *mont archs targets. It felt overkill to check this with cpuid.
It might make sense to change it to check the ANDROID flag instead?

Do you mean I should remove the entire SSE4 function, or just the call in
opts_check_x86.cpp?
It would remove the need for the Silvermont 'special exception', and the
performance of the SSE2 version is still very good.

     if (supports_simd(SK_CPU_SSE_LEVEL_SSE41)) {
         return platform_565_colorprocs_SSE4[flags];
+    } else
+#endif
+    if (supports_simd(SK_CPU_SSE_LEVEL_SSE2)) {
+        return platform_565_colorprocs_SSE2[flags];
     } else {
         return NULL;
     }
 }
 
 static const SkBlitRow::Proc32 platform_32_procs_SSE2[] = {
     NULL,                               // S32_Opaque,
     S32_Blend_BlitRow32_SSE2,           // S32_Blend,
     S32A_Opaque_BlitRow32_SSE2,         // S32A_Opaque
     S32A_Blend_BlitRow32_SSE2,          // S32A_Blend,
@@ skipping 169 matching lines @@
     } else {
         return SkPlatformXfermodeFactory_impl(rec, mode);
     }
 }
 
 SkXfermodeProc SkPlatformXfermodeProcFactory(SkXfermode::Mode mode);
 
 SkXfermodeProc SkPlatformXfermodeProcFactory(SkXfermode::Mode mode) {
     return NULL;
 }