3DMark06 features a series of tests that have different functions within 3DMark. The graphics tests and the CPU tests are used to produce the 3DMark score, the overall measurement of your system's 3D gaming performance. The feature tests are used to highlight the performance of specific functionality of your 3D hardware.
For more technical information about the tests please refer to the 3DMark06 Whitepaper document which can be downloaded from here.
Note: In all tests a higher result (usually presented in Frames Per Second (FPS)) is better.
The engine in 3DMark06 dynamically builds shaders for each material in HLSL format. These shaders are then runtime compiled to best fit the installed hardware, or the user may manually set which compilation profile to use. A professional hardware reviewer can compare the performance difference using different shader compiler profiles for the same hardware.
HDR
One of the next big things in real-time 3D is High Dynamic Range, or also known as HDR. 3DMark06 features two HDR/SM3.0 graphics tests which are prime examples of how HDR rendering looks like. There are several approaches to achieve some level of HDR, but in 3DMark06 the HDR/SM3.0 graphics tests wouldn't have been possible by cutting corners. The approach used in 3DMark06 is technically very taxing on the hardware, and very complex. The two HDR/SM3.0 graphics tests require a lot of precision in the lower end of the brightness range, while still having extremely bright values in specific places, such as the sun. To achieve the level of quality you see in 3DMark06 wouldn’t be possible with any other approach, unless giving up on the quality and accuracy.
The HDR/SM3.0 graphics tests require both 16 bit floating point texture, and 16 bit floating point blending support. The HDR/SM3.0 graphics tests also use 16 bit floating point filtering, but use a very efficient shader emulation fallback for hardware with no support for 16 bit floating point filtering.
The HDR/SM3.0 graphics tests use a more advanced post-processing bloom effect to really bring get the most out of HDR rendering. The post-process also include a star shaped glow effect which simulates the six edge shutter of traditional cameras with exposure control. In addition that a ghost/lens reflection effect is being done, and finally the whole image is being processed by tone-mapping in order to get the correct light values for normal displays.
Shader Model 3.0
Key features of Shader Model 3.0 used in 3DMark06:
Dynamic Shadows
3DMark06 uses a type of depth shadow maps called Cascaded Shadow Maps (CSM). The implementation is a new approach to achieve angle independent quality on dynamic shadows for all objects on screen. This method works by dividing the view frustum in to 5 sections along the z-axis. Each section gets shadowed by a standard uniform 2048x2048 shadowmap. If the hardware supports depth textures, a D24X8 or DF24 depth map is used. If Depth Textures are not supported, an R32F single component 32 bit floating point texture will be used as a depth map. Hardware shadow mapping can be disabled, if a more exact rendering performance comparison is desired, but the hardware shadow mapping is on by default (with the exception of D24X8 in the HDR/SM3.0 graphics tests). A single buffer will be reused for all 5 sections.
Shadows from point light sources use a 1024x1024x6 cube map of the format R32F as depth map, unless the hardware supports D24X8 with hardware bilinear PCF or DF24 with FETCH4 depth textures.
The two HDR/SM3.0 graphics tests in 3DMark06 use a 16 sample kernel that is randomly rotated for each pixel. By using the 16 sample rotated kernel, we are able to produce very high quality smooth edges for the shadows. Point sampling is currently used both for hardware shadow mapping and R32F depth maps.
The SM2.0 graphics tests will use a 4 sample rotated grid kernel to produce relatively smooth edges for the shadows, unless the hardware supports D24X8 with percentage closer filtering (PCF) or DF24 with FETCH4. For hardware with support for hardware PCF or FETCH4, only one 1 sample is fetched though hardware bilinear PCF does the filtering in the hardware, and FETCH4 in the shader.
Most color maps in the graphics tests are DXT1 compressed, the alpha maps are DXT3 compressed, and normal maps are DXT5 compressed.
There are 4 graphics tests (two SM2.0 graphics tests (SM2.0) and two HDR/SM3.0 graphics tests (SM3.0, FP16 Textures, FP16 Blending)) - each one is designed to represent a certain type of 3D game, and thereby offering a variety of 3D game graphics workloads. 3DMark06 records the total number of frames rendered. Using the length of time for the test, an average frame rate is calculated. A higher average framerate is better.
SM2.0 Graphics Test 1 - Return to Proxycon (requires full SM2.0 support or better)
Game Test 1 from 3DMark05 is being re-used in 3DMark06, but will be using the updated engine, improved artwork and the new shadow-technique. This test will still only require SM2.0. In this test a crew of space pirates attack and board a transport vessel with valuable cargo. There will be a ‘full story’ in the demo and a shorter version as the graphics test. Please watch the 3DMark06 demo for the whole story.
It should be obvious that this test reflects the 3D performance of shooter games, which most frequently take place indoors. The indoor areas are a bit larger in this test, opposed to the narrow corridors that are typical for first and third person shooters. The larger area allows a larger number of characters fighting in the same room, which is desirable especially in multiplayer games.
Most surfaces of the space ship interior are of a metal material using a Blinn-Phong reflection. The exponent calculations are implemented to use lookups rather than calculating them mathematically.
The numerous lights in the ceiling of the hangar are approximated with a directional lights from behind and above. Only one of the directional lights cast CSM. Additionally there are a number of point lights filling the total lighting nicely, and most of them cast shadows. The corridor has point lights throwing shadows, using a 1024x1024x6 cube depth map/hardware shadow map each, and some are masked and animated such as the rotating warning lights at the doorway, and at the end of the corridor. There are all in all 26 light sources in the graphics test level, two directional, 12 small non-overlapping shadowmapped spot lights and the rest are point lights.
SM2.0 Graphics Test 2 - Firefly Forest (requires full SM2.0 support or better)
Again, 3DMark06 re-uses the test from 3DMark05, but using the updated engine, improved artwork and new shadow-technique. This test will still only require SM2.0. The test has also another “firefly” flying in the forest, in order to create more graphics load. In this test a forest is inhabited by magic fireflies that fly around at night. The moon is nearly full, illuminating the forest with a bluish faint light. The magic fireflies have flickering bright green lights that playfully move around the forest. The graphics test only shows a part of this scene. Please watch the demo for the whole story.
This scene is a nice example of a smaller scale outdoor scene with rich vegetation. Immediate visibility is limited, and there is a skybox surrounding the whole scene. There are a large number of trees, all swaying in the light breeze, the branches swinging separately, and there is dense vegetation on the ground. The vegetation on the ground is actually one of the key interests in this test. It is dynamically distributed where needed, according to the camera movements. Its level of detail is also dynamically altered depending on the distance to the camera. The other key interest in this scene is the amazing lighting and dynamic shadow system. This scene really is ideal for showing the benefits of CSM and high resolution shadow mapped point lights.
The ground material is similar to the metals in graphics test one, but with added diffuse, diffuse detail, normal and normal detail maps. The rock surfaces also have a specular map. The tree branches are also a modified metal material without a specular map and with a diffuse cube map and no bump mapping. The sky is created using a procedural light scattering shader.
The moonlight is directional, generating CSM. The illuminating fireflies are shadow mapped point lights with a cubemap mask.The illuminating fireflies are masked point lights, throwing shadows using a 1024x1024x6 cube depth map/hardware shadow maps.
HDR/SM3.0 Graphics Test 1 - Canyon Flight (requires full SM3.0, FP16 Texture and FP16 Blending support)
Canyon Flight from 3DMark05 has been updated with the improved engine, HDR rendering, use of SM3.0, a new shadow-technique and a completely new shadow filtering technique. A lot of the artwork has also been improved. In this test a Jules Verne type airship flies through a canyon guarded by a giant sea monster. The airmen defend their ship using heavy cannons, but these seem to have no effect on the huge sea monster. Finally the crew manages a narrow escape using the 'last resort' afterburners of the airship. The graphics test only shows a part of this adventure. Please watch the demo for the whole story.
This test gives an example of a large scale outdoor scene with HDR rendering, massive use of smooth shadows and complex SM3.0 shaders. The scene is very complex with large areas of water reflecting the high canyon walls. The HDR rendering is one of the key points of interest in this scene, proving the increasing importance of floating point rendering to achieve realistic scenes. The water in this scene not only features realistic looking HDR reflections and HDR refractions, but it also has a depth fog, making the sea monster swimming under the airship actually look deep down in the water. The surface of the water is distorted using 2 scrolling normal maps and four Gerstner wave functions. This scene also uses a complex heterogeneous fog to make the whole canyon appear humid. The air in this scene also uses the same atmospheric light scattering algorithm as in 3DMark05, making distant cliffs of the canyon really look far away. The sky uses a more complex atmospheric light scattering algorithm than in 3DMark05, with cloud blending.
The ship and the crewmen are shaded using Strauss shading model, making them look more realistic than in 3DMark05. The canyon material has three color maps, three normal maps and Lambertian diffuse shading. The water is a further developed version of the water shader in 3DMark05. The monster uses Blinn-Phong shading model and has 2 normal maps, 1 color map and introduces a visually impressive subsurface scattering effect.
Since it is a sunny day, there is only one single directional light source - the sun. This scene is very challenging for dynamic shadows because of the large area and the round shapes of the canyon walls, but thanks to the CSM technique this is now possible.
HDR/SM3.0 Graphics Test 2 - Deep Freeze (requires full SM3.0, FP16 Texture and FP16 Blending support)
Deep Freeze is a completely new graphics test, introducing an Antarctic research base. The mood in this test is very movie-like, and has a pinch of horror in it. The graphics test only shows a part of this wonderful scene, so please run the demo for the whole story.
This test is a good showcase for using HDR effects in vast landscapes, and stunning dynamic long soft shadows for daytime -> nighttime scenarios. As the sun goes down, the shadows increase in length and really show off the robustness of CSM. The snow uses Blinn-Phong shading model, 2 normal maps and 1 color map. The metallic and other surfaces use Strauss shading model. This test also uses the heterogeneous fog, along with heavy use of particles, to create a nice snow-storm effect. The snow also uses the subsurface scattering effect.
The sky uses the simpler atmospheric light scattering algorithm. The change in ambient lighting when the sun is setting, is achieved by blending two pairs of cubemaps - one for diffuse, and another for specular light. In this scene the HDR values are hovering around 11.000, which would not be feasible without floating point rendering.
CPU Test 1 & 2 - Red Valley (requires full SM2.0 support or better)
The 3DMark06 CPU tests consist of a game scene with a maze of canyons, and 87 fast-moving game units ("bots", speeder bikes and hovering tanks). The speeders attempt to navigate to a goal position at a castle at the other end of the canyon system, all the while avoiding the defending tanks, and collisions with other speeders. The tanks attempt to hunt down the speeders, and shoot them.
The game scene yields three types of load in the CPU tests: game logic, physics and path finding AI. The game logic, including the graphics engine operation, runs in a single main thread that also drives the other two tasks. The physics simulation runs in a single separate thread, and is synched with the main thread at each physics step. The pathfinding AI runs in a number of worker threads (the number of threads is scaled with available processors), and is synched with the main thread at set intervals, generally some multiple of the physics step interval. The path finding algorithm used is D* Lite (http://www.cc.gatech.edu/fac/Sven.Koenig/) and the physics are using the AGEIA PhysX library (http://www.ageia.com).
The CPU tests are run in fixed frame rate (2fps) to make a more equal CPU load for all systems. The resolution is locked to 640x480 and the tests use no dynamic shadows to decrease the graphics performance influence on the result.
Test 1:
Higher path finding task complexity
Tighter AI synchronization intervals
Duration 40 frames
Shader Profile 2_0
Test 2:
Lower path finding task complexity
Laxer AI synchronization intervals
Duration 60 frames
Shader Profile 2_0
Both CPU tests are forward looking, since CPU technology is clearly is moving towards either virtual or physical dual core technology. The CPU tests are mainly designed for dual systems, either with an on-chip solution or with two separate CPUs, but are an excellent CPU test for single core processors as well. Professional reviewers can disable the other CPU or the other core of a virtual or physical dual core system, and compare the results.
Feature test - Fill Rate
Single Texturing. This test works just like in 3DMark05. The size of the texture used is 2x2 in order to decrease bandwidth limitation of the performance. 64 quads cover the screen and are single textured and additively blended.
Multi-Texturing. This test works just like in 3DMark05. The size of the texture used is 2x2 in order to decrease bandwidth limitation of the performance. 8 quads cover the screen and each quad has 8 textures additively blended.
Feature Test - Pixel Shader
One of the more complex materials in the graphics tests is the rock face shader. This is separated to a feature test, showing the lighting change on the rough surface. There are no dynamic shadows, which makes some space for additional instructions compared to the similar shader in Canyon Flight. There is also no water surface, just the rock face. Filling the screen with a rock face is naturally fairly fast, compared to the graphics test showing huge amounts of that rock face in addition to water, the air ship and sea monster. This test will be somewhat bandwidth dependent, since any game like material with a complex shader like this will also have a number of lookups to large textures. It seems like most PC games will mainly utilize to normal color maps that have been made during development, instead of burdening the pixel shader with creating procedural textures.
Feature test - Vertex Shader
Vertex Shader - Simple
This test does simple transformation and single light lighting on four high polygon sea monster models. Each sea monster has over one million vertices to transform and illuminate, so the total workload is quite substantial. The vertex shader used here could quite well fit into a shader model 1 vertex shader, but since 3DMark06 still uses SM2.0 and offers different SM2.0 (and SM3.0) profiles to choose from, the shader is declared in HLSL as SM2.0.
Vertex Shader - Complex
This illuminates, but above all transforms a large number of grass straws. Each straw is skinned and bent separately, more towards the tip of the straw, like real grass straws waving in the wind. The straws are waved according to a fractal noise calculated on the CPU, but it is highly optimized to decrease the influence of the CPU performance on the measurement. The grass is kept at a distance from the camera, offering a less interesting visual effect, but this is necessary to decrease the influence of fill rate to the measurement.
SM3.0 Feature tests
Shader Particles
This test runs simple particle physics in the pixel shader and then uses the results through vertex texture fetches. The use of graphics hardware for physics computations in games is increasing. Simple physics computations are inherently parallelizable, which allows them to be implemented on graphics hardware fairly effortlessly. As a result a game developer is able to use far more particles than would be feasible on a CPU while the CPU becomes free to perform other computations. This test requires SM3.0 with hardware Vertex Texture Fetch (VTF) support.
Perlin Noise
TThis test computes six octaves of 3-dimensional Perlin simplex noise using a combination of arithmetic instructions and texture lookups. Perlin noise is a basic building block in many procedural texturing and modelling techniques, which are expected to increase in popularity in future games due to both reduced memory and bandwidth requirements as well as the increasing computation power in graphics hardware. This test requires SM3.0.
Batch Size tests
The batch size tests basically render a very simple scene that is un-optimized, revealing a weakness in most graphics drivers available today. Graphics IHV's have for years educated game developers to render as large batches as possible. However, it would be beneficial if the rendering of smaller batches were to be optimized too. There are six runs of this test, where 128 meshes of 128x128 quads are draw with 8, 32, 128, 512, 2048 and 32768 triangles per batch. The last two batch sizes should be considered optimized sizes for most drivers today, but the smaller the batch sizes get, the slower the rendering will be. Color change state changes are done between the rendering batches to make sure DX doesn't collapse the whole rendering into a single or very few batches. Early versions of this test without the state changes caused this, and gave quite obscure results. The test therefore also is somewhat dependent on how fast the driver does rendering state changes.
