3DMark06 Under the Magnifying Glass

CPU Tests Mandatory For A Final Score

Futuremark has changed its overall score calculation by requiring CPU tests in order to generate an overall score. Every version prior to 3DMark06 produced its final score from the graphics subsystem alone. In retrospect, 3DMark01SE would allow a final score if only one game test was selected. In 3DMark06, the score produced depends on how the graphics subsystem and the CPU perform together. This implementation turns the application into a system benchmark, in addition to it being a graphics benchmark. Of course applications are taxing the performance of the entire system, as the artificial intelligence of non-player characters interacts with the player. Also, as we have seen recently, physics is now demanding more out of the system.

The two CPU tests run in a game feature called Red Valley. The valley is defended by a single, slow defense tank with rockets that attempt to destroy fast incoming targets racing through tight long ravines heading up the valley floor to the base entrance. Futuremark states that the "game scene yields three types of load in the CPU tests: game logic, physics and path finding AI." The loads are broken out into threads. The game logic and graphics engine are in one thread, while physics simulations run on a separate one. At each physics step, the physics is synched back to the main thread.

The frame rates remain low, at two frames per second or less, depending on your system. The AI for each "worker" thread is scalable based on the number of available processors. This means that the more CPUs (or cores) that you have, the better the CPU workload can be handled. Since there are 87 bots in the test, this scales up to 87 processors.

Futuremark used the Ageia software development kit (SDK) and library to handle physics. It describes the physics demands in this test as "simulating the game world with its 87 units and their rigid bodies, at 20 ms physics steps. Some physics operations, like traces into collision meshes, and some overhead are also included in the main thread load."

Interestingly, after speaking with Havok and Ageia at Game Developers Conference (GDC), both made comments that 3DMark06 does not test physics, but rather graphics. So don't think that this will truly test the hardware acceleration of physics. We will have to wait for another benchmark to do this, but Futuremark did include some physics acceleration in a new feature test that is not included in the default settings for scoring.

Futuremark made a short game based on the CPU test. If you are tired of benchmarking, you can take a load off your mind by blowing things up for a while.

We asked Nick about Futuremark's implementation of physics in 3DMark06.

Tom's Hardware: We know you switched from Havok to the PhysX SDK. Why did you make the change? Was it because the Ageia solution was free, or were there other factors?

Nick: AGEIA's PhysX was optimally suited for our needs in 3DMark06.

Tom's Hardware: Can you comment on the implementation of this physics content?

Nick: In the CPU test, we have a static world collision mesh, and convex dynamic low-poly meshes for each game unit. We apply forces and torques according to various game logic calculations to propel the units along, and react to collision events by triggering sound and particle effects and unit destruction. We do ray traces to the physics world to simulate the laser projectile flight and detonation, and for basic motion control of the units and camera (proximity to terrain, occlusion).

Tom's Hardware: Do you do any physics testing or only graphics performance?

Nick: We use physics in the CPU tests, but we don't have any dedicated physics feature tests in our current products. Also note that the tests are not hooked up to take advantage of physics hardware that might be present in the system.

Tom's Hardware: In what tests have you used the SDK?

Nick: The CPU tests in 3DMark06 are the only tests where we use the AGEIA PhysX physics library.