aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/core/SkUtilsArm.cpp
Commit message (Collapse)AuthorAge
* Result of running tools/sanitize_source_files.py (which was added in ↵Gravatar rmistry@google.com2012-08-23
| | | | | | | | | https://codereview.appspot.com/6465078/) This CL is part I of IV (I broke down the 1280 files into 4 CLs). Review URL: https://codereview.appspot.com/6485054 git-svn-id: http://skia.googlecode.com/svn/trunk@5262 2bbb7eff-a529-9590-31e7-b0007b416f81
* arm: dynamic NEON support for SkBitmapProcState matrix operations.Gravatar digit@google.com2012-08-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch implements dynamic ARM NEON support for the functions implemented by src/core/SkBitmapProcState_matrixProcs.cpp. - Because the SkBitmapProcState_matrix_{clamp,repeat}.h headers are NEON-specific, they are renamed with a _neon.h suffix, and moved to src/opts/ (from src/core/) - Add a new file src/opts/SkBitmapProcState_matrixProcs_neon.cpp which implements the NEON code paths for all builds, and add it to the 'opts_neon' static library. - Modify SkBitmapProcState_matrixProcs.cpp to select the right code-path depending on our build configuration. Note that in the case where 'arm_neon == 1', we do not embed regular ARM code paths in the final binary. Only 'arm_neon_optional == 1' builds will contain both regular and NEON code paths at the same time. Note that there doesn't seem to be a simple way to put the NEON-specific selection from that currently is in SkBitmapProcState_matrixProcs.cpp into src/opts/. Doing so would require much more drastic restructuring. This is also true of the other SkBitmapProcState source files that will be touched in a future patch. Review URL: https://codereview.appspot.com/6453065 git-svn-id: http://skia.googlecode.com/svn/trunk@4888 2bbb7eff-a529-9590-31e7-b0007b416f81
* arm: First step towards dynamic NEON support.Gravatar digit@google.com2012-05-30
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