Getting hardware floating point with android NDK

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 functions, 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.

Update: NDK r9b added support for -mhard-float. This allows you to build NDK libraries with hard-float API conventions for armeabi-v7a targets.