Fractal: CPU Burn Test

This test measures solely the device's CPU performance. It allocates 4 concurrent threads which are used to calculate frames of the famous Mandelbrot fractal set. Each thread calculates every 4th scanline in the image; when all threads have completed the frame, the UI thread is notified and the new image frame is taken into use. The UI thread performs a 2D "zoom" into the rendered image while the next image is being calculated to create an illusion of seamless zooming at 60 FPS. Calculation of each pixel requires heavy complex number math. Naturally the devices with 4 or more cores will benefit most, while devices with a single core will have to do a lot of context switching.

The Mandelbrot set fractal was chosen because it is colorful and pretty and using it is a nod towards the demoscene of the 90s but most importantly because it is the perfect parallelization problem since each and every pixel can be calculated indenpendently from the others. The score from this stage is calculated based on the full Mandelbrot frames calculated, taking into consideration the amount of pixels calculated as well as the depth in the set. The CPU score is downscaled somewhat since the CPUs effect on 3D rendering is rather low.

Fillrate Tests

The fill rate tests are performed by rendering one frame a high number of repetition between glFinish() calls; the time spent is then measured and used as score for each test type. In other words, the textured quad is rendered several times on top of itself within a single frame to provide more accurate timing data than just doing it once.

First, the textured quad is rendered as is, with no lighting (Unlighted fillrate). Then it is rendered through a shader program that calculates the Gouraud-style lighting in the vertex shader (Vertexlighted fillrate); third test calculates the lighting in the fragment shader (Pixellighted fillrate). The final test calculates the lighting per-pixel in the fragment shader with additional specular component; normal/specular maps are also applied (Mapped fillrate).

Chess: GPU Basic Test

This test stage measures GPU performance with pretty standard techniques: multitexturing, per-pixel lighting, reflections and post-processing effects. The polygon count in the scene is not that high (around 1000-2000 per piece) but the post-processing depth-of-field effect applies a lot of load on the GPU. The effect is built with a 4-pass approach: first the scene is rendered into a texture, then gaussian blur is applied in both x/y directions and finally the blurred and original image are blended together using the depth value as the blending factor. The chessboard features planar reflections of the chess pieces; both the pieces and the board also reflect the environment. Everything is per-pixel lighted using the Phong illumination model.

As a curiosity, the game played out by the pieces is an actual game between chess grandmasters Garri Kasparov and Jan Timman in 1991 in Amsterdam. Visualized are the moves from 24th onwards. The game ended in agreed draw at move 29.

Mountains: Game Environment Test

The final test combines the aspects usually present in high-end games; large geometry, realtime shadows, physics, great viewing distances. The landscape mesh consists of about 120000 polygons, and the other models add up to another roughly 10000. The skybox-aligned sunlight is used as the source for lens-flares as well as shadow mapping. Lens-flare occlusion test is done every 100 milliseconds if the source is on the screen; shadow maps are calculated every frame even if no shadow caster movement occurs to keep the GPU stressed and the FPS steady. The shadow map size is 2k x 2k. The landscape is rendered by blending two separate ground textures together, blending factor based on the slope of the polygon. The trees/leaves are sorted and blended, and a alpha-based discard shader trick is used in their shadow map generation. The buggy model is tangent-space normalmapped and per-pixel lighted. The physics engine used is BulletPhysics 2.80, and physics calculations are done in the UI thread. The rigid bodies are the roman columns, the stone wall, the buggy and a planar "ground". Note that on purpose no landscape subdivision / frustum clipping is used to keep the GPU as strained as possible.