This patch adds minimal support for dynamic ARM NEON support,
i.e. the ability to probe the CPU at runtime for NEON and
provide alternate code paths when it is available.
- Add include/core/SkUtilsArm.h, which declares a few helper
macros (e.g. SK_NEON_ARM_IS_DYNAMIC), plus the handy
function 'sk_cpu_arm_has_neon()' which returns true if
the target CPU supports the ARM NEON instruction set.
Note that the header is in include/core/ because it will
have to be included from NEON-specific code under src/code/
It would probably be more logical to put it under include/opts/
instead, but this would require moving all the NEON-specific
stuff under src/code/ into src/opts/, which is not trivial
due to the way the code is currently architected.
- Add src/core/SkUtilsArm.cpp which implements
'sk_cpu_arm_has_neon' for ARM-based Linux systems, only
when SK_NEON_ARM_IS_DYNAMIC is true.
(For other cases, 'sk_cpu_arm_has_neon' is an inline function
that returns a constant 'true' or 'false' value).
There is no user-level accessible CPUID instruction on ARM,
so do all CPU feature probing by parsing /proc/cpuinfo.
This is Linux-specific.
For Debug build types, the CPU probing result is printed
to the Android log (or Linux command-line) for easier
debugging.
- Create a new 'opts_neon' target (static library) which shall
contain all the NEON-specific code paths for the library.
This is necessary because -mfpu=neon impacts also non-scalar
code. Just like with -mssse3 on x86, we can't build the rest
of the library with this flag.
Note that for now, we only include memset16_neon and
memset32_neon in this library.
- Modify opts_check_arm.cpp to implement SK_ARM_NEON_IS_DYNAMIC
properly.
Compared to a 'xoom' build, the only difference is the use of
NEON-optimized memset16/32 functions. Later patches will move
more NEON-specific code paths to 'opts_neon'.
Review URL: https://codereview.appspot.com/6247058
git-svn-id: http://skia.googlecode.com/svn/trunk@4069 2bbb7eff-a529-9590-31e7-b0007b416f81
Need to opt-in to have it applied to kA8 text (which chrome can't for a while)
A8 text needs to use Slight hinting to look better, but that is not forced...
git-svn-id: http://skia.googlecode.com/svn/trunk@3277 2bbb7eff-a529-9590-31e7-b0007b416f81
This patch removes static initializers related to static and
global mutexes from the final library's machine code when
building on a pthread-capable system.
We use PTHREAD_MUTEX_INITIALIZER to perform POD-style
initialization. You need a line like the following to declare
a global mutex with it:
SkBaseMutex gMutex = { PTHREAD_MUTEX_INITIALIZER };
We introduce the SK_DECLARE_STATIC_MUTEX and SK_DECLARE_GLOBAL_MUTEX
macros to be able to declare static/global mutexes in the source tree
uniformly.
SkMutex is now defined as a sub-class of SkBaseMutex, with standard
construction/destruction semantics. This is useful if the mutex
object is a member of another C++ class, or allocated dynamically.
We also modify a few places to refer to SkBaseMutex instead of a
SkMutex, where it makes sense. Generally speaking, client code
should hold and use pointers to SkBaseMutex whenever they can
now.
We defined a new built-time macro named SK_USE_POSIX_THREADS
to indicate that we're using a pthread-based SkThread.h
interface. The macro will also be used in future patches
to implement other helper thread synchronization classes.
Finally, we inline the acquire() and release() functions in the
case of Posix to improve performance a bit.
Running: 'bench -repeat 10 -match mutex' on an Android device or
a 2.4GHz Xeon Linux desktop shows the following improvements:
Before After
Galaxy Nexus 1.64 1.45
Nexus S 1.47 1.16
Xoom 1.86 1.66
Xeon 0.36 0.31
This removes 5 static mutex initializers from the library
Review URL: https://codereview.appspot.com/5501066
git-svn-id: http://skia.googlecode.com/svn/trunk@3091 2bbb7eff-a529-9590-31e7-b0007b416f81
