skia2/gyp/opts.gyp

232 lines
7.0 KiB
Plaintext
Raw Normal View History

# Copyright 2015 Google Inc.
#
# Use of this source code is governed by a BSD-style license that can be
# found in the LICENSE file.
# Gyp file for building opts target.
{
# Source lists live in opts.gypi. This makes it easier to maintain our Chrome GYP/GN setup.
# (To be honest, I'm not sure why we need to include common.gypi. I thought it was automatic.)
'variables': {
'includes': [ 'common.gypi', 'opts.gypi' ],
},
# Generally we shove things into one 'opts' target conditioned on platform.
# If a particular platform needs some files built with different flags,
# those become separate targets: opts_ssse3, opts_sse41, opts_neon.
'targets': [
{
'target_name': 'opts',
'product_name': 'skia_opts',
'type': 'static_library',
'standalone_static_library': 1,
'dependencies': [
'core.gyp:*',
'effects.gyp:*'
],
'include_dirs': [
'../include/private',
'../src/core',
'../src/opts',
'../src/utils',
'../include/utils',
],
'conditions': [
[ '"x86" in skia_arch_type and skia_os != "ios"', {
'cflags': [ '-msse2' ],
'dependencies': [ 'opts_ssse3', 'opts_sse41', 'opts_sse42', 'opts_avx', 'opts_hsw' ],
'sources': [ '<@(sse2_sources)' ],
}],
[ 'skia_arch_type == "mips"', {
'conditions': [
[ '(mips_arch_variant == "mips32r2") and (mips_dsp == 1 or mips_dsp == 2)', {
'sources': [ '<@(mips_dsp_sources)' ],
},{
'sources': [ '<@(none_sources)' ],
}],
]
}],
[ '(skia_arch_type == "arm" and arm_version < 7) \
or (skia_os == "ios") \
or (skia_os == "android" \
and skia_arch_type not in ["x86", "x86_64", "arm", "mips", \
"arm64"])', {
'sources': [ '<@(none_sources)' ],
}],
[ 'skia_arch_type == "arm" and arm_version >= 7', {
# The assembly uses the frame pointer register (r7 in Thumb/r11 in
# ARM), the compiler doesn't like that.
'cflags!': [ '-fno-omit-frame-pointer', '-mapcs-frame', '-mapcs' ],
'cflags': [ '-fomit-frame-pointer' ],
'sources': [ '<@(armv7_sources)' ],
arm: First step towards dynamic NEON support. 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
2012-05-30 13:54:41 +00:00
'conditions': [
[ 'arm_neon == 1', {
'dependencies': [ 'opts_neon' ]
}],
arm: First step towards dynamic NEON support. 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
2012-05-30 13:54:41 +00:00
],
}],
[ 'skia_arch_type == "arm64"', {
'sources': [ '<@(arm64_sources)' ],
'dependencies': [ 'opts_crc32' ]
}],
[ 'skia_android_framework', {
'cflags!': [
'-msse2',
'-mfpu=neon',
'-fomit-frame-pointer',
]
}],
],
},
{
'target_name': 'opts_crc32',
'product_name': 'skia_opts_crc32',
'type': 'static_library',
'standalone_static_library': 1,
'dependencies': [ 'core.gyp:*' ],
'include_dirs': [
'../include/private',
'../src/core',
'../src/utils',
],
'sources': [ '<@(crc32_sources)' ],
'conditions': [
[ 'not skia_android_framework', { 'cflags': [ '-march=armv8-a+crc' ] }],
],
},
{
'target_name': 'opts_ssse3',
'product_name': 'skia_opts_ssse3',
'type': 'static_library',
'standalone_static_library': 1,
'dependencies': [ 'core.gyp:*' ],
'include_dirs': [
'../include/private',
'../src/core',
'../src/utils',
],
'sources': [ '<@(ssse3_sources)' ],
'conditions': [
[ 'skia_os == "win"', { 'defines' : [ 'SK_CPU_SSE_LEVEL=31' ] }],
[ 'not skia_android_framework', { 'cflags': [ '-mssse3' ] }],
],
},
{
'target_name': 'opts_sse41',
'product_name': 'skia_opts_sse41',
'type': 'static_library',
'standalone_static_library': 1,
'dependencies': [ 'core.gyp:*' ],
'include_dirs': [
'../include/private',
'../src/core',
'../src/utils',
],
'sources': [ '<@(sse41_sources)' ],
'xcode_settings': { 'GCC_ENABLE_SSE41_EXTENSIONS': 'YES' },
'conditions': [
[ 'skia_os == "win"', { 'defines' : [ 'SK_CPU_SSE_LEVEL=41' ] }],
[ 'not skia_android_framework', { 'cflags': [ '-msse4.1' ] }],
],
},
{
'target_name': 'opts_sse42',
'product_name': 'skia_opts_sse42',
'type': 'static_library',
'standalone_static_library': 1,
'dependencies': [ 'core.gyp:*' ],
'include_dirs': [
'../include/private',
'../src/core',
'../src/utils',
],
'sources': [ '<@(sse42_sources)' ],
'xcode_settings': { 'GCC_ENABLE_SSE42_EXTENSIONS': 'YES' },
'conditions': [
[ 'skia_os == "win"', { 'defines' : [ 'SK_CPU_SSE_LEVEL=42' ] }],
[ 'not skia_android_framework', { 'cflags': [ '-msse4.2' ] }],
],
},
{
'target_name': 'opts_avx',
'product_name': 'skia_opts_avx',
'type': 'static_library',
'standalone_static_library': 1,
'dependencies': [ 'core.gyp:*' ],
'include_dirs': [
'../include/private',
'../src/core',
'../src/utils',
],
'sources': [ '<@(avx_sources)' ],
'msvs_settings': { 'VCCLCompilerTool': { 'EnableEnhancedInstructionSet': '3' } },
'xcode_settings': { 'OTHER_CPLUSPLUSFLAGS': [ '-mavx' ] },
'conditions': [
[ 'not skia_android_framework', { 'cflags': [ '-mavx' ] }],
],
},
{
'target_name': 'opts_hsw',
'product_name': 'skia_opts_hsw',
'type': 'static_library',
'standalone_static_library': 1,
'dependencies': [ 'core.gyp:*' ],
'include_dirs': [
'../include/private',
'../src/core',
'../src/utils',
],
'sources': [ '<@(hsw_sources)' ],
'msvs_settings': { 'VCCLCompilerTool': { 'EnableEnhancedInstructionSet': '5' } },
'xcode_settings': {
'OTHER_CPLUSPLUSFLAGS': [ '-mavx2', '-mbmi', '-mbmi2', '-mf16c', '-mfma' ]
},
'conditions': [
[ 'not skia_android_framework', {
'cflags': [ '-mavx2', '-mbmi', '-mbmi2', '-mf16c', '-mfma' ]
}],
],
},
arm: First step towards dynamic NEON support. 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
2012-05-30 13:54:41 +00:00
{
'target_name': 'opts_neon',
'product_name': 'skia_opts_neon',
arm: First step towards dynamic NEON support. 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
2012-05-30 13:54:41 +00:00
'type': 'static_library',
'standalone_static_library': 1,
'dependencies': [
'core.gyp:*',
'effects.gyp:*'
],
arm: First step towards dynamic NEON support. 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
2012-05-30 13:54:41 +00:00
'include_dirs': [
'../include/private',
arm: First step towards dynamic NEON support. 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
2012-05-30 13:54:41 +00:00
'../src/core',
'../src/opts',
'../src/utils',
arm: First step towards dynamic NEON support. 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
2012-05-30 13:54:41 +00:00
],
'sources': [ '<@(neon_sources)' ],
arm: First step towards dynamic NEON support. 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
2012-05-30 13:54:41 +00:00
'cflags!': [
'-fno-omit-frame-pointer',
'-mfpu=vfp', # remove them all, just in case.
'-mfpu=vfpv3',
'-mfpu=vfpv3-d16',
],
'conditions': [
[ 'not skia_android_framework', {
'cflags': [
'-mfpu=neon',
'-fomit-frame-pointer',
],
}],
arm: First step towards dynamic NEON support. 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
2012-05-30 13:54:41 +00:00
],
'ldflags': [
'-march=armv7-a',
'-Wl,--fix-cortex-a8',
],
arm: First step towards dynamic NEON support. 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
2012-05-30 13:54:41 +00:00
},
],
}