DD Tech-talk 1: Nexus versus iPhone 3GS

First things first, just like UK MP’s have to declare any outside interests, I should mention that we were given the Nexus One by Google for no cost. That said, I have tried to have no bias whatever.

The test I’m showing here is a pretty typical 3D game scene. It contains a 3D environment and multiple animated 3D characters. The GPU is stress tested due to the high number of polygons in the scene and the CPU is stress tested as it is calculating the bone & skinning of the animation.

Let’s look at the results first and then some technical details to frame these results.

Starting up the test on both devices shows that the iPhone 3GS runs at 60 frames per second (fps) and the Nexus at between 30 to 35fps. As we add more woman models until we get to 8 models we see that the frame rate has dropped to 29fps on the iPhone and approx 21fps on the Nexus. Therefore, on the face of it, it seems the iPhone is 138% faster in this scene.

So, what is causing the difference in frame rate.

One of the most important differences between these two devices is the fact that the Nexus has a much higher resolution screen, which means that the GPU has to fill 2.5 times as many pixels on the Nexus than it does on the iPhone. OK, so let’s change the viewport on the Nexus to the same size as the iPhone just so we can compare the two equally. With just two characters on screen, switching the viewport size to 480×320 on the Nexus, give a frame-rate improvement from 30fps to 40fps but with 8 characters on screen there is no difference; with the frame-rate remaining the same at 21fps.

This reveals that the bottleneck to performance must be elsewhere. The next logical test is to see if the bottleneck is CPU related. We can test this by turning off the animation bone & skinning calculations. Doing this reveals that drawing to the full screen on the Nexus with the animation disabled has no effect on the frate-rate yet when only drawing to the same screen area as the iPhone then the frame rate increases from 20fps up-to 25fps.

The conclusion is that the Nexus is primarily GPU fill-rate limited and the lack of access to the Neon float-point instructions means the CPU is only just keeping pace with the fill-rate.

We would therefore strongly advise the Android team at Google to update the NDK to a new version of GCC so Neon floating-point code can be written to take full advantage of the CPU in the Driod & Nexus. It may only be used by a handful of developers but it is these developers that will push the boundaries of Android games development and show what the platform can do.

With any benchmark it’s important to understand some of the detail behind what is going on.

In this test the 3D engine code running on both devices is the identical with one major exception – the Nexus isn’t using Neon floating-point optimisation – but more on this later. The Android code is 95% C++ code compiled using the Android Native Development Kit (NDK) in ARM mode (rather than Thumb mode).

VFP floating-point optimisation is switched on and it is using the VFP optimisations in the vertex skinning sub-system. However, the Cortex A8 core that the Nexus has at the heart of its CPU would run the Neon floating-point code much quicker than VFP but currently the NDK doesn’t provide a compiler that can compile Neon assembly instructions (apparently there is a way to update the compiler but that requires that the whole Android OS is recompiled with a new version of GCC).