New Page 1

# Test Programs

This section describes test programs included with Chromium.

## tiletest

The tiletest program verifies that the tilesort SPU is working correctly. It can also be used to visually experiment with simple tile layouts and load balancing.

The tiletest program verifies that tilesorting is working correctly by doing the following:

- Ask the Chromium tilesort SPU for the number of servers, the number of tiles per server, and the size and location of all tiles.
- Draw a colored square corresponding to each tile. The tile color indicates the server. Each tile is also labeled 'sXtY' to indicate server number X and tile number Y.
- Draw a cube centered in each tile.
- As the cubes are drawn, the tilesort SPU records the number of vertices sent to each render server.
- Query the servers to determine how many vertices each received.
- Print a report of the results and compare the number of vertices received to the number expected.

Three tests are performed by changing the granularity of the glBegin/glEnd primitives:

- Per-face: glBegin and glEnd are called for each face of each cube.
- Per-cube: glBegin and glEnd are called once for each cube.
- Per-scene: glBegin and glEnd are called just once for the whole test.

In the first two cases each tile should receive 24 vertices (the number of vertices per cube). So if a server has T tiles, the server should receive 24T vertices.

In the last case all cube vertices should be sent to all servers since Chromium bins only whole glBegin/glEnd primitives. Therefore, if C cubes are drawn, each server should receive 24C vertices.

The tiletest program can also be used to experiment with tile layouts. Run tiletest with the -t option. You'll see a matrix of colored squares. Each color represents a different server. The number of servers, tile rows and tile columns can be changed with the keyboard:

- s/S = decrease/increase number of servers
- r/R = decrease/increase rows of tiles
- c/C = decrease/increase columns of tiles

The following shows a configuration with 3 servers and a 4x4 array of tiles. It's a good configuration because the tiles are evenly distributed.

If we increase the number of servers to 4 and use a naive tile allocation then we'll get the following configuration:

The point is that the tile configuration for a given number of servers is important and determines how well the rendering load is balanced among the servers.