Texture calculation benchmarks

Hi All,

With L3DT release 2.6 only a few weeks away, I thought this might be a good time to run some head-to-head comparisons of the new release (v2.6) against the previous release (v2.5c). In particular, I'm going to show you just how far we have come in optimising the multi-core, mosaic-mapped calculations in L3DT Professional Edition.

Before we get to the numbers, I should describe how the tests were conducted. Basically, I generated a complete map (heightmap, lightmap, etc.), and then I ran the texture generation algorithm repeatedly with 1, 2, 3, and 4 cores enabled, using mosaic and non-mosaic texture generation.

The results will be presented in terms of the texture pixel throughput, measured in pixels per millisecond. Larger values are better, and imply faster texture generation.

All of the benchmark tests were conducted on the same map, with the following settings:

For the mosaic tests, the attributes, normal, light map and texture map were all mosaics, with a tile size of 512×512 pixels. For the non-mosaic tests, all these maps were in-RAM, with mosaic mapping disabled.

The benchmarking system was setup as follows:

The graph below shows the performance of the previous release of L3DT Professional, version 2.5c, for both mosaic and non-mosaic texture generation.

These results show two very bad things about the mosaic system in v2.5c:

1. The first problem was that the speed of the mosaic map calculation (blue bars) simply did not increase when more cores were added. This indicates that the the mosaic map cache manager was very inefficient at handling concurrent requests from multiple threads, and was making threads wait for one-another far too often.
2. The second problem was that even for a single-core calculation, the mosaic map calculation was only ~35% as fast as the non-mosaic (RAM only) texture calculation. This implies that there was a huge overhead in reading/writing pixels in a mosaic map, even when the tiles were already loaded into RAM.

If you described these results for the mosaic map system “appalling”, I would be inclined to agree. Fortunately, I'm very pleased to say that these two problems have now been solved in version 2.6, as shown by the next section.

The graph below shows the performance of the forthcoming release of L3DT Professional, version 2.6, for both mosaic and non-mosaic texture generation:

Here you can see that the mosaic map results (blue bars) scale up with the number of cores. In fact, the mosaic map calculation is now faster than the non-mosaic calculation (red bars), by about 10% for any number of cores (up to four, anyway). This huge improvement in the mosaic system was brought about by a smarter mosaic cache manager with far fewer thread locks, and by optimising the texture calculation to bypass some of the overheads in the mosaic system.

Now I'm going to directly compare the results for the old release (v2.5c) with the forthcoming release (v2.6).

First up is the comparison of non-mosaic texture generation:

Across the board, v2.6 (light green) is about 25% faster than v2.5c (dark green) for non-mosaic texture generation. Not bad.

However, the big news is the improvements in mosaic map texture generation:

Version 2.6 (light green) is monumentally faster than v2.5c (dark green) for mosaic texture generation, ranging from an impressive 275% improvement for single-core calculations, to an absurd 1100% improvement for quad core calculations (yes, one thousand and one hundred percent faster).

The mosaic map system in L3DT 2.6 is a colossal improvement over that of v2.5c, providing a speed-up of better than a thousand percent for texture generation on quad-core processors. Speaks for itself, really.

The release date for L3DT 2.6 is mid-September.

Disclaimer: These benchmark results apply only to the texture generation algorithm. You should not expect the heightfield, water-mapping or attributes map algorithms to improve by comparable amounts. Similar improvements may be occur with the normal map and light map calculations, as these algorithms are structured identically to the texture algorithm. However, this is not guaranteed, as the benchmark tests have not yet been conducted for those algorithms.