NDK floating-point support

[Roderick Colenbrander]

Hi,

As I mentioned in another post I have ported Quake3 to Android. The
game makes heavy use of floating-point and its performance is hold
back a lot by software floating point emulation which is what the NDK
uses by default.

Is there a way already to take advantage of an FPU? I noticed that the
gcc shipped by the NDK also supports VFP, is the -mfpu=vfp option
really doing anything? I don't mind that the app will only work on
modern CPUs (the armv6 qualcomm which is used in the G1, Hero and
other phones is too weak) or that it can only run on Android 2.x
devices. So is there a way already?

Thanks,
Roderick Colenbrander

[Doug Schaefer]

I think we probably need a new identifier different than 'armeabi' for hardware float to ensure the Market doesn't download apps like this on hardware that doesn't have hardware float.

--

You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to andro...@googlegroups.com.
To unsubscribe from this group, send email to android-ndk...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.

[Roderick Colenbrander]

The NDK build system hints at a new mechanism but at this point I'm
not worried about such things. I'm just looking for a way to use the
FPU to see how much it helps Quake3. I'm not planning on shipping it
yet. Even if I would and there was no mechanism I would add some
basic /proc/cpuinfo detection to see if the instruction set I want is
around and load the right libquake3.so from my JNI wrapper lib.

Roderick

On Jan 4, 5:59 pm, Doug Schaefer <cdtd...@gmail.com> wrote:
> I think we probably need a new identifier different than 'armeabi' for
> hardware float to ensure the Market doesn't download apps like this on
> hardware that doesn't have hardware float.
>
> On Mon, Jan 4, 2010 at 11:46 AM, Roderick Colenbrander <
>

> thunderbir...@gmail.com> wrote:
> > Hi,
>
> > As I mentioned in another post I have ported Quake3 to Android. The
> > game makes heavy use of floating-point and its performance is hold
> > back a lot by software floating point emulation which is what the NDK
> > uses by default.
>
> > Is there a way already to take advantage of an FPU? I noticed that the
> > gcc shipped by the NDK also supports VFP, is the -mfpu=vfp option
> > really doing anything? I don't mind that the app will only work on
> > modern CPUs (the armv6 qualcomm which is used in the G1, Hero and
> > other phones is too weak) or that it can only run on Android 2.x
> > devices. So is there a way already?
>
> > Thanks,
> > Roderick Colenbrander
>
> > --
>
> > You received this message because you are subscribed to the Google Groups
> > "android-ndk" group.
> > To post to this group, send email to andro...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > android-ndk...@googlegroups.com<android-ndk%2Bunsu...@googlegroups.com>

[Jack Palevich]

I can't help you with which GCC compiler flags to set, but I wanted to
give some background info:

For what it's worth, Android uses the softfp calling convention, which
means that it calls C runtime subroutines to implement floating point
math operations.

Because the subroutines are in a shared library supplied by the
device, they are implemented using whatever code runs the fastest on
the platform. So your NDK code is in fact using VFP hardware floating
point when it runs on Droid or Nexus One. It's true that there is
overhead for copying the floating point data to and from integer
registers and jumping to the subroutines. But performance is better
than pure software fp would be.

Also be aware that many ARM CPUs do not pipeline VFP floating
operations. So you may not see a significant speed improvement by
switching to direct use of VFP instructions.

I did some experiments with generating VFP code directly on Droid,
compared to calling the C runtime subroutines, and the performance
gains were quite small. On the order of 3%. But that was for my code,
and your milage may vary. (I generated the code myself, so I can't
help you with gcc compiler flag settings. Sorry!)

If you want really fast floating point you may have to write your own
NEON SIMD routines.

On Jan 5, 12:46 am, Roderick Colenbrander <thunderbir...@gmail.com>
wrote:

[Doug Schaefer]

On Wed, Jan 6, 2010 at 6:54 AM, Jack Palevich <jack.p...@gmail.com> wrote:

If you want really fast floating point you may have to write your own
NEON SIMD routines.

Ah, yes, that's the puppy you're looking for. NEON is the floating point solution of the day. It should be available on the Droid and other Cortex-A8 machines. I'm not sure if the Snapdragon in the Nexus has this, though.

 

[Roderick Colenbrander]

So you are saying that I'm already taking advantage of the FPU. From
what I understood those floating point functions are in libgcc.a which
is compiled into my code. Sure libc/libm on my milestone might be
compiled with float but I think the main issue is the libgcc stuff.
What do you think?

Right now I'm using the NDK which uses gcc 4.2.1 which doesn't have
any NEON support. I believe if you compile android from scratch and
build 2.0 or 2.1 you now get a 4.4.1 compiler which supports more ARM
architectures and has more flags.

On a normal PC quake3 is compiled with -ffast-math which breaks in
combination with softfloat. A better compiler might be able to support
this properly in combination with FPU support. This option doubled the
fps in a lot of cases.

Roderick

[Jack Palevich]

Err, scratch the 3% improvement figure, that was for a code generator
that didn't keep variables in registers. Gcc should do better than
that.

[Roderick Colenbrander]

I have compiled the android source in order to obtain a better
compiler. After that I compiled quake3 using gcc 4.4.0 using the flags
'-march=armv7-a -mfloat-abi=softfp -mfpu=neon' and some other flags I
used before.

Before the framerate was around 22fps and now it is 27fps, so a boost
of more than 20%. I wanted to optimize some known slow parts of q3
using NEON instructions (rsqrt is a known bottleneck) but even when I
made that function return 1 by default I didn't gain anything more.
The same for some other optimizations, so I think I'm hitting a
bottleneck somewhere.

Is there a way to profile apps without using a rooted phone?