cpufeatures returns ANDROID_CPU_FAMILY_ARM on x86

[Simon Taylor]

Hi,

I'm trying to use cpufeatures to determine if neon is supported so I can use some optimized implementations at runtime.

As an intermediate stage, I'm using my runtime detection code but where APP_ABI is set to only armeabi and armeabi-v7a. I've installed this to the x86-based Hudl 2 tablet.

I understand some dynamic recompilation happens at install time to translate the armeabi-v7a binary to x86. As android_getCpuFamily is implemented with preprocessor defines, this actually returns ANDROID_CPU_FAMILY_ARM in this case. More surprising was that the check for if((android_getCpuFeatures() & ANDROID_CPU_ARM_FEATURE_NEON)) returns true as well.

As it turns out, the neon functions have been correctly translated anyway, and do in fact give a speedup over the C implementations, but I know the dynamic recompilation code sits in the device, and older devices might have more bugs around this feature. Therefore I think it would be sensible to avoid the neon code paths in this case. So, is there any way to tell if dynamic recompilation has happened?

Thanks,

Simon

[Philippe Simons]

not sure if it's possible.

but you could still build your code for x86 arch (without the NEON code ofcourse)

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-ndk...@googlegroups.com.
To post to this group, send email to andro...@googlegroups.com.
Visit this group at http://groups.google.com/group/android-ndk.
For more options, visit https://groups.google.com/d/optout.

[Simon Taylor]

On Monday, July 27, 2015 at 9:13:07 PM UTC+1, Philippe Simons wrote:

not sure if it's possible.

but you could still build your code for x86 arch (without the NEON code ofcourse)

 

Yes, in the end I will ship this with an x86 build. It just seemed interesting that cpufeatures, whose entire purpose is for runtime CPU detection, gets thwarted by the binary translation. This is also a library, so if 3rd parties have other binary dependencies without x86 builds they may be forced to rely on the binary translation for intel devices.

There is a possibility that this behaviour is correct, and cpufeatures is returning the features that are supported by the translation layer. There is a slight difference in the feature mask on my x86 tablet vs my native armeabi-v7a phone: The phone reports all arm features apart from ANDROID_CPU_ARM_FEATURE_iWMMXt, and the tablet reports all of them apart from ANDROID_CPU_ARM_FEATURE_IDIV_THUMB2. I guess the question is can these feature masks be trusted if binary translation has happened?

As an aside I get better performance from the binary-translated neon implementations than from the version compiled for x86 using the neon->SSE intrinsics header wrapper (although as expected the C version performs better when compiled directly for the target arch).

This is a YUV conversion function (converting 640x480 YUV image to RGB565 and a half-sampled Y, data in L2):

armeabi, binary translated

C: 2400us

armeabi-v7a, binary translated

C: 2500us

Neon: 870us (very similar performance from what started as neon inline asm and neon intrinsics versions)

x86, neon->SSE header wrapper

C: 1780us

Neon Intrinsics (translated to SSE): 1140us

Simon