| « | » |
To evaluate CPU performance, two game tests are run at minimum 640x480 resolution with minimum Shaders 2.0. And the vertex shaders are shifted on to CPU. You cannot call it a sterling CPU test, because in real games it will perform other tasks connected with calculating AI and physics in the game instead of software emulation of vertex shaders. Anyhow, parallel tasks are used to generate the initial data and thus multi-CPU, multi-core or HyperThreading systems may get an advantage.
The test is not modified (there are cosmetic changes but the algorithm is the same), it tests texture mapping on large objects (texturing) and multitexturing.
This test calculates a fragment of a canyon wall from the third game test. Note that this test features intensive calculations of pixel shaders, which model many effects on the pixel level by calculating them. However one should take into account that this material is not calculated completely as a procedural texture and uses a lot of various maps, and thus this test depends not only on the performance of pixel shaders but considerably on the memory performance of the video card and texture caching efficiency. To get a more precise evaluation of the unit performance balance of the accelerator, one should use more local synthetic tests, which load precisely a given subsystem.
The test consists of two parts. The first one tests a relatively simple geometry shader on models with a great number of vertices – that is it tests close to peak throughput and typical performance of the accelerator on high detail geometry.
And on the contrary, the second test examines rather complex and long vertex shaders, as a result it analyzes performance of vertex units in complex tasks.
It's a very interesting test, which is necessary rather to game developers than to common enthusiasts of gaming hardware. It checks the dependence of the accelerator efficiency on the average size of data batches. Too many batches – too high load on CPU and additional expenses on synchronizing the accelerator with the program. Too large batch size – limited rendering flexibility, textures and shaders cannot be changed. Optimal balance is up to a developer, it may be different for different accelerators. Anyway, such things are best to check on real engines and games instead of 3DMark05 engine – that's why we think this test is somewhat redundant and making little sense in the context of the overall game test. Especially as we cannot control the content and character of tasks, we can only have preselected parameters and change the batch size.
Let's not be strict though. This test is included into the benchmark, you can use it or skip it as you wish. And you can always interpret its results to your profit. It's much worse when you don't have this test :).
| « | » |