2014-02-05 16:35:12 +00:00
|
|
|
# Gyp file for opts projects
|
2011-05-31 13:50:51 +00:00
|
|
|
{
|
|
|
|
'targets': [
|
|
|
|
# Due to an unfortunate intersection of lameness between gcc and gyp,
|
|
|
|
# we have to build the *_SSE2.cpp files in a separate target. The
|
|
|
|
# gcc lameness is that, in order to compile SSE2 intrinsics code, it
|
|
|
|
# must be passed the -msse2 flag. However, with this flag, it may
|
|
|
|
# emit SSE2 instructions even for scalar code, such as the CPUID
|
|
|
|
# test used to test for the presence of SSE2. So that, and all other
|
|
|
|
# code must be compiled *without* -msse2. The gyp lameness is that it
|
|
|
|
# does not allow file-specific CFLAGS, so we must create this extra
|
|
|
|
# target for those files to be compiled with -msse2.
|
|
|
|
#
|
|
|
|
# This is actually only a problem on 32-bit Linux (all Intel Macs have
|
|
|
|
# SSE2, Linux x86_64 has SSE2 by definition, and MSC will happily emit
|
|
|
|
# SSE2 from instrinsics, while generating plain ol' 386 for everything
|
|
|
|
# else). However, to keep the .gyp file simple and avoid platform-specific
|
|
|
|
# build breakage, we do this on all platforms.
|
|
|
|
|
|
|
|
# For about the same reason, we need to compile the ARM opts files
|
|
|
|
# separately as well.
|
|
|
|
{
|
|
|
|
'target_name': 'opts',
|
2012-10-10 19:45:51 +00:00
|
|
|
'product_name': 'skia_opts',
|
2011-05-31 13:50:51 +00:00
|
|
|
'type': 'static_library',
|
2012-10-10 19:45:51 +00:00
|
|
|
'standalone_static_library': 1,
|
2013-07-22 14:39:45 +00:00
|
|
|
'dependencies': [
|
|
|
|
'core.gyp:*',
|
2014-01-24 15:43:50 +00:00
|
|
|
'effects.gyp:*'
|
2013-07-22 14:39:45 +00:00
|
|
|
],
|
2011-05-31 13:50:51 +00:00
|
|
|
'include_dirs': [
|
|
|
|
'../src/core',
|
2012-01-09 14:38:25 +00:00
|
|
|
'../src/opts',
|
2011-05-31 13:50:51 +00:00
|
|
|
],
|
|
|
|
'conditions': [
|
2012-09-20 15:45:41 +00:00
|
|
|
[ 'skia_arch_type == "x86" and skia_os != "ios"', {
|
2012-02-14 18:28:54 +00:00
|
|
|
'conditions': [
|
2013-07-31 20:09:25 +00:00
|
|
|
[ 'skia_os in ["linux", "freebsd", "openbsd", "solaris", "nacl", "chromeos", "android"]', {
|
2012-02-14 18:28:54 +00:00
|
|
|
'cflags': [
|
|
|
|
'-msse2',
|
|
|
|
],
|
|
|
|
}],
|
|
|
|
],
|
2013-07-09 21:37:14 +00:00
|
|
|
'include_dirs': [
|
|
|
|
'../include/utils',
|
|
|
|
],
|
2013-07-31 20:09:25 +00:00
|
|
|
'dependencies': [
|
|
|
|
'opts_ssse3',
|
|
|
|
],
|
2011-11-03 13:08:29 +00:00
|
|
|
'sources': [
|
Cleanup of SSE optimization files.
General cleanup of optimization files for x86/SSEx.
Renamed the opts_check_SSE2.cpp file to _x86, since it's not specific
to SSE2. Commented out the ColorRect32 optimization, since it's
disabled anyway, to make it more visible.
Also fixed a lot of indentation, inclusion guards, spelling,
copyright headers, braces, whitespace, and sorting of includes.
Author: henrik.smiding@intel.com
Signed-off-by: Henrik Smiding <henrik.smiding@intel.com>
R=reed@google.com, mtklein@google.com, tomhudson@google.com, djsollen@google.com, joakim.landberg@intel.com
Author: henrik.smiding@intel.com
Review URL: https://codereview.chromium.org/264603002
git-svn-id: http://skia.googlecode.com/svn/trunk@14464 2bbb7eff-a529-9590-31e7-b0007b416f81
2014-04-30 14:58:46 +00:00
|
|
|
'../src/opts/opts_check_x86.cpp',
|
2011-11-03 13:08:29 +00:00
|
|
|
'../src/opts/SkBitmapProcState_opts_SSE2.cpp',
|
2013-07-09 21:37:14 +00:00
|
|
|
'../src/opts/SkBitmapFilter_opts_SSE2.cpp',
|
2011-11-03 13:08:29 +00:00
|
|
|
'../src/opts/SkBlitRow_opts_SSE2.cpp',
|
2012-03-19 13:49:50 +00:00
|
|
|
'../src/opts/SkBlitRect_opts_SSE2.cpp',
|
2013-11-08 20:49:04 +00:00
|
|
|
'../src/opts/SkBlurImage_opts_SSE2.cpp',
|
2013-10-30 21:57:04 +00:00
|
|
|
'../src/opts/SkMorphology_opts_SSE2.cpp',
|
2011-11-03 13:08:29 +00:00
|
|
|
'../src/opts/SkUtils_opts_SSE2.cpp',
|
2014-04-09 15:43:46 +00:00
|
|
|
'../src/opts/SkXfermode_opts_SSE2.cpp',
|
2011-11-03 13:08:29 +00:00
|
|
|
],
|
|
|
|
}],
|
2013-07-31 12:57:27 +00:00
|
|
|
[ 'skia_arch_type == "arm" and arm_version >= 7', {
|
2011-11-03 13:08:29 +00:00
|
|
|
# The assembly uses the frame pointer register (r7 in Thumb/r11 in
|
|
|
|
# ARM), the compiler doesn't like that.
|
|
|
|
'cflags!': [
|
|
|
|
'-fno-omit-frame-pointer',
|
2012-11-29 15:09:58 +00:00
|
|
|
'-mapcs-frame',
|
|
|
|
'-mapcs',
|
2011-11-03 13:08:29 +00:00
|
|
|
],
|
|
|
|
'cflags': [
|
|
|
|
'-fomit-frame-pointer',
|
2012-11-29 15:09:58 +00:00
|
|
|
'-mno-apcs-frame',
|
2011-11-03 13:08:29 +00:00
|
|
|
],
|
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
|
|
|
'variables': {
|
|
|
|
'arm_neon_optional%': '<(arm_neon_optional>',
|
|
|
|
},
|
2011-11-03 13:08:29 +00:00
|
|
|
'sources': [
|
2012-01-09 14:38:25 +00:00
|
|
|
'../src/opts/memset.arm.S',
|
2011-11-03 13:08:29 +00:00
|
|
|
'../src/opts/SkBitmapProcState_opts_arm.cpp',
|
2013-08-28 15:07:58 +00:00
|
|
|
'../src/opts/SkBlitMask_opts_arm.cpp',
|
2011-11-03 13:08:29 +00:00
|
|
|
'../src/opts/SkBlitRow_opts_arm.cpp',
|
2014-02-10 15:01:05 +00:00
|
|
|
'../src/opts/SkBlurImage_opts_arm.cpp',
|
|
|
|
'../src/opts/SkMorphology_opts_arm.cpp',
|
|
|
|
'../src/opts/SkUtils_opts_arm.cpp',
|
2013-10-09 14:39:46 +00:00
|
|
|
'../src/opts/SkXfermode_opts_arm.cpp',
|
2011-11-03 13:08:29 +00:00
|
|
|
],
|
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 or arm_neon_optional == 1', {
|
|
|
|
'dependencies': [
|
|
|
|
'opts_neon',
|
|
|
|
]
|
2012-09-20 15:45:41 +00:00
|
|
|
}],
|
|
|
|
[ 'skia_os == "ios"', {
|
|
|
|
'sources!': [
|
2012-09-24 19:33:57 +00:00
|
|
|
# these fail to compile under xcode for ios
|
2012-09-20 15:45:41 +00:00
|
|
|
'../src/opts/memset.arm.S',
|
2012-09-24 19:33:57 +00:00
|
|
|
'../src/opts/SkBitmapProcState_opts_arm.cpp',
|
|
|
|
'../src/opts/SkBlitRow_opts_arm.cpp',
|
2012-09-20 15:45:41 +00:00
|
|
|
],
|
|
|
|
}],
|
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
|
|
|
],
|
2011-11-03 13:08:29 +00:00
|
|
|
}],
|
2014-06-11 13:56:10 +00:00
|
|
|
[ 'skia_arch_type == "mips"', {
|
|
|
|
'sources': [
|
|
|
|
'../src/opts/SkBitmapProcState_opts_none.cpp',
|
|
|
|
'../src/opts/SkBlitMask_opts_none.cpp',
|
|
|
|
'../src/opts/SkBlurImage_opts_none.cpp',
|
|
|
|
'../src/opts/SkMorphology_opts_none.cpp',
|
|
|
|
'../src/opts/SkUtils_opts_none.cpp',
|
|
|
|
'../src/opts/SkXfermode_opts_none.cpp',
|
|
|
|
],
|
|
|
|
'conditions': [
|
|
|
|
[ '(mips_arch_variant == "mips32r2") \
|
|
|
|
and (mips_dsp == 1 or mips_dsp == 2)', {
|
|
|
|
'sources': [
|
|
|
|
'../src/opts/SkBlitRow_opts_mips_dsp.cpp',
|
|
|
|
],
|
|
|
|
}, {
|
|
|
|
'sources': [
|
|
|
|
'../src/opts/SkBlitRow_opts_none.cpp',
|
|
|
|
],
|
|
|
|
}],
|
|
|
|
],
|
|
|
|
}],
|
|
|
|
[ '(skia_arch_type == "arm" and arm_version < 7) \
|
2014-02-05 16:35:12 +00:00
|
|
|
or (skia_os == "ios") \
|
2014-05-22 13:42:34 +00:00
|
|
|
or (skia_os == "android" and skia_arch_type not in ["x86", "arm", "mips", "arm64"])', {
|
2011-11-03 13:08:29 +00:00
|
|
|
'sources': [
|
|
|
|
'../src/opts/SkBitmapProcState_opts_none.cpp',
|
2013-08-28 15:07:58 +00:00
|
|
|
'../src/opts/SkBlitMask_opts_none.cpp',
|
2011-11-03 13:08:29 +00:00
|
|
|
'../src/opts/SkBlitRow_opts_none.cpp',
|
2013-11-08 20:49:04 +00:00
|
|
|
'../src/opts/SkBlurImage_opts_none.cpp',
|
2013-10-30 21:57:04 +00:00
|
|
|
'../src/opts/SkMorphology_opts_none.cpp',
|
2011-11-03 13:08:29 +00:00
|
|
|
'../src/opts/SkUtils_opts_none.cpp',
|
2013-10-09 14:39:46 +00:00
|
|
|
'../src/opts/SkXfermode_opts_none.cpp',
|
2011-11-03 13:08:29 +00:00
|
|
|
],
|
|
|
|
}],
|
2014-02-28 16:07:39 +00:00
|
|
|
[ 'skia_android_framework', {
|
|
|
|
'cflags!': [
|
|
|
|
'-msse2',
|
|
|
|
'-mfpu=neon',
|
|
|
|
'-fomit-frame-pointer',
|
|
|
|
'-mno-apcs-frame',
|
|
|
|
]
|
|
|
|
}],
|
2014-05-22 13:42:34 +00:00
|
|
|
[ 'skia_arch_type == "arm64"', {
|
2014-04-02 15:03:56 +00:00
|
|
|
'sources': [
|
|
|
|
'../src/opts/SkBitmapProcState_arm_neon.cpp',
|
|
|
|
'../src/opts/SkBitmapProcState_matrixProcs_neon.cpp',
|
|
|
|
'../src/opts/SkBitmapProcState_opts_arm.cpp',
|
|
|
|
'../src/opts/SkBlitMask_opts_arm.cpp',
|
|
|
|
'../src/opts/SkBlitMask_opts_arm_neon.cpp',
|
2014-06-03 17:08:07 +00:00
|
|
|
'../src/opts/SkBlitRow_opts_arm.cpp',
|
|
|
|
'../src/opts/SkBlitRow_opts_arm_neon.cpp',
|
2014-04-02 15:03:56 +00:00
|
|
|
'../src/opts/SkBlurImage_opts_arm.cpp',
|
|
|
|
'../src/opts/SkBlurImage_opts_neon.cpp',
|
|
|
|
'../src/opts/SkMorphology_opts_arm.cpp',
|
|
|
|
'../src/opts/SkMorphology_opts_neon.cpp',
|
|
|
|
'../src/opts/SkUtils_opts_none.cpp',
|
|
|
|
'../src/opts/SkXfermode_opts_arm.cpp',
|
|
|
|
'../src/opts/SkXfermode_opts_arm_neon.cpp',
|
|
|
|
],
|
|
|
|
}],
|
2011-05-31 13:50:51 +00:00
|
|
|
],
|
|
|
|
},
|
2012-02-14 18:28:54 +00:00
|
|
|
# For the same lame reasons as what is done for skia_opts, we have to
|
|
|
|
# create another target specifically for SSSE3 code as we would not want
|
|
|
|
# to compile the SSE2 code with -mssse3 which would potentially allow
|
|
|
|
# gcc to generate SSSE3 code.
|
|
|
|
{
|
|
|
|
'target_name': 'opts_ssse3',
|
2012-10-10 19:45:51 +00:00
|
|
|
'product_name': 'skia_opts_ssse3',
|
2012-02-14 18:28:54 +00:00
|
|
|
'type': 'static_library',
|
2012-10-10 19:45:51 +00:00
|
|
|
'standalone_static_library': 1,
|
2013-07-22 14:39:45 +00:00
|
|
|
'dependencies': [
|
|
|
|
'core.gyp:*',
|
2014-01-24 15:43:50 +00:00
|
|
|
'effects.gyp:*'
|
2013-07-22 14:39:45 +00:00
|
|
|
],
|
2012-02-14 18:28:54 +00:00
|
|
|
'include_dirs': [
|
|
|
|
'../src/core',
|
|
|
|
],
|
|
|
|
'conditions': [
|
2014-02-28 16:07:39 +00:00
|
|
|
[ 'skia_os in ["linux", "freebsd", "openbsd", "solaris", "nacl", "chromeos", "android"] \
|
|
|
|
and not skia_android_framework', {
|
2012-02-14 18:28:54 +00:00
|
|
|
'cflags': [
|
|
|
|
'-mssse3',
|
|
|
|
],
|
|
|
|
}],
|
2013-08-06 18:13:01 +00:00
|
|
|
# (Mac has -mssse3 globally.)
|
2012-06-28 16:08:05 +00:00
|
|
|
[ 'skia_arch_type == "x86"', {
|
2012-02-14 18:28:54 +00:00
|
|
|
'sources': [
|
|
|
|
'../src/opts/SkBitmapProcState_opts_SSSE3.cpp',
|
|
|
|
],
|
|
|
|
}],
|
|
|
|
],
|
|
|
|
},
|
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
|
|
|
# NEON code must be compiled with -mfpu=neon which also affects scalar
|
|
|
|
# code. To support dynamic NEON code paths, we need to build all
|
|
|
|
# NEON-specific sources in a separate static library. The situation
|
Revert of Add SSE4 optimization of S32A_Opaque_Blitrow (https://codereview.chromium.org/289473009/)
NOTREECHECKS=true
NOTRY=true
Reason for revert:
Valgrind bot's seeing this code use uninitialized memory, and it's somehow blocking our roll into Chrome too:
> ld: warning: could not create compact unwind for
S32A_Opaque_BlitRow32_SSE4_asm:
> stack subq instruction is too different from dwarf stack size
> [10339/10982 | 3247.792] PACKAGE FRAMEWORK "Chromium Framework.framework",
> POSTBUILDS
> FAILED: ./gyp-mac-tool package-framework "Chromium Framework.framework" A &&
> (export
> BUILT_PRODUCTS_DIR=/Volumes/data/b/build/slave/mac_gpu/build/src/out/Release;
> export CONFIGURATION=Release; export CONTENTS_FOLDER_PATH="Chromium
> Framework.framework/Versions/A"; export
> DYLIB_INSTALL_NAME_BASE=@executable_path/../Versions/37.0.2056.0; export
> EXECUTABLE_NAME="Chromium Framework"; export EXECUTABLE_PATH="Chromium
> Framework.framework/Versions/A/Chromium Framework"; export
> FULL_PRODUCT_NAME="Chromium Framework.framework"; export
> INFOPLIST_PATH="Chromium Framework.framework/Versions/A/Resources/Info.plist";
> export
LD_DYLIB_INSTALL_NAME="@executable_path/../Versions/37.0.2056.0/Chromium
> Framework.framework/Chromium Framework"; export MACH_O_TYPE=mh_dylib; export
> PRODUCT_NAME="Chromium Framework"; export
> PRODUCT_TYPE=com.apple.product-type.framework; export
>
SDKROOT=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.6.sdk;
> export
>
SRCROOT=/Volumes/data/b/build/slave/mac_gpu/build/src/out/Release/../../chrome;
> export SOURCE_ROOT="${SRCROOT}"; export
> TARGET_BUILD_DIR=/Volumes/data/b/build/slave/mac_gpu/build/src/out/Release;
> export TEMP_DIR="${TMPDIR}"; export
UNLOCALIZED_RESOURCES_FOLDER_PATH="Chromium
> Framework.framework/Versions/A/Resources"; export WRAPPER_NAME="Chromium
> Framework.framework"; (cd ../../chrome && ../build/mac/tweak_info_plist.py
> "--breakpad=1" "--breakpad_uploads=0" "--keystone=0" "--scm=1"
> "--branding=Chromium" && ln -fns Versions/Current/Libraries
> "${BUILT_PRODUCTS_DIR}/${WRAPPER_NAME}/Libraries" &&
> tools/build/mac/verify_order _ChromeMain
> "${BUILT_PRODUCTS_DIR}/${EXECUTABLE_PATH}"); G=$?; ((exit $G) || rm -rf
> 'Chromium Framework.framework') && exit $G) && touch "Chromium
> Framework.framework"
> tools/build/mac/verify_order: unordered symbols in
> /Volumes/data/b/build/slave/mac_gpu/build/src/out/Release/Chromium
> Framework.framework/Versions/A/Chromium Framework:
> S32A_Opaque_BlitRow32_SSE4_asm
> _S32A_Opaque_BlitRow32_SSE4_asm
> ninja: build stopped: subcommand failed.
Original issue's description:
> Add SSE4 optimization of S32A_Opaque_Blitrow
>
> Adds optimization of Skia S32A_Opaque_Blitrow blitter using SSE4.2 SIMD
> instruction set. Special case for when alpha is zero or opaque.
>
> Performance increase of 10%-400% compared to the existing SSE2
> optimization (measured on Silvermont architecture).
> Noticeable in ~25 different skia bench subtests, especially in
> bitmap_8888_*, repeatTile_*, and morph_*.
>
> bitmap_8888_A - 100% faster
> bitmap_8888_A_source_transparent - 250% faster
> bitmap_8888_A_source_opaque - 25% faster
> bitmap_8888_A_scale_bicubic - 75% faster
>
> Signed-off-by: Henrik Smiding <henrik.smiding@intel.com>
>
> Committed: https://skia.googlesource.com/skia/+/e2527b147679b0c43019fae7d59cc3777d2d097e
>
> Committed: https://skia.googlesource.com/skia/+/b5c281e1e06af3be804309877de1dac6145686b9
R=reed@google.com, tomhudson@google.com, djsollen@google.com, joakim.landberg@intel.com, henrik.smiding@intel.com, mtklein@chromium.org
Author: mtklein@google.com
Review URL: https://codereview.chromium.org/336413007
2014-06-18 00:37:05 +00:00
|
|
|
# is very similar to the SSSE3 one.
|
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',
|
2012-10-10 19:45:51 +00:00
|
|
|
'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',
|
2012-10-10 19:45:51 +00:00
|
|
|
'standalone_static_library': 1,
|
2013-07-22 14:39:45 +00:00
|
|
|
'dependencies': [
|
|
|
|
'core.gyp:*',
|
2014-01-24 15:43:50 +00:00
|
|
|
'effects.gyp:*'
|
2013-07-22 14:39:45 +00:00
|
|
|
],
|
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': [
|
|
|
|
'../src/core',
|
2012-08-01 14:25:07 +00:00
|
|
|
'../src/opts',
|
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',
|
|
|
|
],
|
2014-02-28 16:07:39 +00:00
|
|
|
'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
|
|
|
],
|
2013-01-23 18:56:38 +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
|
|
|
'sources': [
|
|
|
|
'../src/opts/memset16_neon.S',
|
|
|
|
'../src/opts/memset32_neon.S',
|
2012-08-13 14:06:34 +00:00
|
|
|
'../src/opts/SkBitmapProcState_arm_neon.cpp',
|
2012-08-01 14:25:07 +00:00
|
|
|
'../src/opts/SkBitmapProcState_matrixProcs_neon.cpp',
|
2014-01-28 15:18:54 +00:00
|
|
|
'../src/opts/SkBitmapProcState_matrix_neon.h',
|
2013-12-02 13:50:38 +00:00
|
|
|
'../src/opts/SkBlitMask_opts_arm_neon.cpp',
|
2012-08-08 22:06:29 +00:00
|
|
|
'../src/opts/SkBlitRow_opts_arm_neon.cpp',
|
2013-12-04 18:19:45 +00:00
|
|
|
'../src/opts/SkBlurImage_opts_neon.cpp',
|
2013-11-11 16:48:51 +00:00
|
|
|
'../src/opts/SkMorphology_opts_neon.cpp',
|
2013-10-17 16:29:34 +00:00
|
|
|
'../src/opts/SkXfermode_opts_arm_neon.cpp',
|
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
|
|
|
],
|
|
|
|
},
|
2011-05-31 13:50:51 +00:00
|
|
|
],
|
|
|
|
}
|