We've been making a lot of additions to our mobile benchmarking suite lately in an effort to get the best picture possible of the performance landscape out there for tablets and smartphones alike. First it was GLBenchmark 2.0, now it's Basemark. This new test benchmarks OpenGL ES 1.0 or 2.0 performance on devices through a suite of five feature tests and one overall 3D user interface test. In its current incarnation, we've been given binaries for the Android platform, however Basemark's Kanzi 2.0 engine, which is written entirely in ANSI-C, will be ported to other platforms in the future. For now however, we're focusing on testing Android hardware with Basemark and using the OpenGL ES 2.0 render pipelines since all of the Android devices we have (and coming in the future) are of the 2.0 sort.
First up among those feature tests is animation, which animates a graphics element (in this case, a robot moving through a set of actions) by stepping through a table of keyframes and interpolating the character's movement between using splines. This particular benchmark uses ES 2.0 APIs and per vertex lighting, but the purpose of this test is to be as CPU-bound as possible and specifically stress floating point performance.
Next are the vertex and texture streaming tests, both of which measure asset streaming performance - according to RightWare, effectively memory bandwidth. The vertex test loads geometry data into GPU memory and frees it when no longer needed. The scene itself involves a lot of geometry - ten repeating city blocks which the camera moves through with increasing speed and draw distance. The test ramps from around 3k vertices to 15k vertices per frame, and 190k to 250k triangles per frame. There's a single texture material, fog, two lights, and OpenGL ES 2.0 shaders which use per vertex lighting.
The texture test is a bit more straightforward, quickly loading images from RAM into the GPU memory and discarding them.
Blend testing - as its name implies - tests alpha blended rendering by drawing a number of semi-transparent contact cards atop each other. These are overlaid sequentially until we reach a desired number of layers. This test actually runs twice, first with front to back ordering of these contact cards, and then with back to front ordering.
This ordering difference shouldn't be confused with the fact that feature test actually runs in both back to front and front to back rendering orders and are combined later.