ref: ef7e05d47d4c002d5a22dbd2aaba33bdedd32964
parent: adb27ff0b1d407ad467ed53811a481bf1199db91
author: Martin Storsjö <martin@martin.st>
date: Fri Feb 28 20:35:21 EST 2014
Use the __ARM_NEON__ built-in compiler define for identifying neon capability on iOS This avoids having to hardcode the names of devices that don't support neon. The devices that don't support neon don't run the armv7 variants of iOS binaries at all - they would need to be built for the armv6 architecture. (Building for armv6 isn't supported at all in modern iOS SDKs.) Therefore we can simply use the __ARM_NEON__ built-in compiler define to check if NEON code is allowed in the current build, and have the WelsCPUFeatureDetect function return flags accordingly. The only thing this disallows is doing an armv6 build which would optionally enable neon code at runtime if run on an armv7 capable device, but since Apple allows you to build the same binary for armv7 separately in the same app bundle, and since armv6 building isn't even possible in the current iOS SDKs, this isn't really a loss. This is in contrast to the android builds where the armv7 baseline does not include NEON.
--- a/codec/common/cpu.cpp
+++ b/codec/common/cpu.cpp
@@ -42,9 +42,6 @@
#ifdef ANDROID_NDK
#include <cpu-features.h>
#endif
-#ifdef APPLE_IOS
-#include <sys/utsname.h>
-#endif
#include "cpu.h"
#include "cpu_core.h"
@@ -245,18 +242,12 @@
uint32_t WelsCPUFeatureDetect (int32_t* pNumberOfLogicProcessors)
{
uint32_t uiCPU = 0;
- struct utsname sSystemInfo;
- uname (&sSystemInfo);
- if ((0 != strcmp(sSystemInfo.machine, "iPhone1,1")) && //iPhone 2G
- (0 != strcmp(sSystemInfo.machine, "iPhone1,2")) && //iPhone 3G
- (0 != strcmp(sSystemInfo.machine, "iPod1,1")) && //iPod 1G
- (0 != strcmp(sSystemInfo.machine, "iPod2,1"))) //iPod 2G
- {
- uiCPU |= WELS_CPU_ARMv7;
- uiCPU |= WELS_CPU_VFPv3;
- uiCPU |= WELS_CPU_NEON;
- }
+#if defined(__ARM_NEON__)
+ uiCPU |= WELS_CPU_ARMv7;
+ uiCPU |= WELS_CPU_VFPv3;
+ uiCPU |= WELS_CPU_NEON;
+#endif
return uiCPU;
}
#elif defined(__linux__)