Getting hardware floating point with android NDK

Question

Hi All,

I've begun playing with the android NDK. One of the things I've just learnt is about creating an application.mk file to specify the armv7 abi.

I'm building the san-angeles example with the following parameters.

APP_MODULES      := sanangeles
APP_PROJECT_PATH := $(call my-dir)/../
APP_OPTIM        := release
APP_ABI          := armeabi-v7a

However this seems to run at exactly the same speed as it did before (ie badly). Am I just GL limited and not CPU limited or is something wrong here?

I have noticed when I compile that I get the following command line options emitted:

-march=armv7-a -mfloat-abi=softfp -mfpu=vfp -mthumb 

The thing that worries me there is the "softfp". There IS mention of the v7 abi, the VFP fpu stuff and I'm guessing the "thumb" refers to the "thumb-2" instructions (Though I don't know what exactly these are). However that "softfp" does concern me. Shouldn't it be "hardfp"?

Anyone got any ideas on these questions? I think I'm probably about ready to start implementing some GL ES 2.0 code for my HTC Desire but I'd like to make sure I'm getting the best possible speed out of it :)

Cheers in advance!

Answer 1

The options you supply to the NDK will only affect the way your code is compiled. It won't change the GL libs or anything else that's part of the platform, which are always generated in an appropriate fashion. If you're just throwing geometry at the GL hardware, you're not going to see a difference.

If you want to see if your options are having an effect, download (or create) a simple benchmark that does a bunch of operations with double-precision floating point values, and time how long it takes to execute before and after.

The -mfloat-abi=softp argument determines how floating-point values are passed between functions. softfp means they're always passed in integer registers or on the stack. If Android didn't specify softfp, the ARMv7-A version of the library would expect floats to show up in hardware registers, and any code built for ARMv5TE would break.

"softfp" adds a little overhead to some funtions, but the instructions for moving values in and out of fp registers are cheap on ARM, and the ABI compatibility provided makes it worthwhile.

The "-mthumb" enables generation of Thumb/Thumb2 code. Thumb code tends to be a bit slower but a bit smaller than equivalent ARM; sometimes smaller means you'll fit better in the CPU i-cache and will actually run faster. Size is always a concern on these devices, so Thumb is enabled by default.

When in doubt, "arm-eabi-objdump -d whatever.o" will show you a disassembly of your code.