3DMark 2006

Released: 2006
Developer: Futuremark Corporation
Platform: PC
Minimum system requirements:
Operating system: Microsoft Windows 2000 or XP operating system
Processor: x86 compatible processor with MMX support, 2000MHz
RAM: (512MB recommended)
DIRECT X: DirectX9.0c or later (required)

This is also indicated by the fact that three of the four so-called "graphics tests" of this package are nothing more than improved versions of the 3DMark05 gaming tests. In fact, the differences between the new version and the old one are not so much qualitative as quantitative: Of the radically new, we note support for HDR, Uniform Shadow Maps, support for multi-core CPUs and a focus on using Shader Model 3.0, although not exclusive - 2 out of four graphics tests work within Shader Model 2.0.

The rest of the changes are quantitative in nature: once again the detail of test scenes, the number of light sources, the complexity of the shaders used, the resolution of textures, etc. have been increased. Thus, the general concept of 3DMark06 is to focus on SM3.0-compatible GPUs.

3DMark06: graphics engine features

As you know, a new graphics engine was developed for 3DMark05, which has nothing in common with the previously used MAX-FX engine, and had much more similarity with real game engines. The 3DMark06 engine is its modification, which received full support for Shader Model 3.0, as well as textures and blending in FP16 format. The last two points mean nothing more than the possibility of using HDR. Futuremark predicts that high dynamic range support will be widely used in next-generation games, although the number of such games is very low at the moment. As in 3DMark05, the shaders that make up a particular material are dynamically generated in HLSL format. They are then compiled to optimally match the GPU installed in the system - either automatically,

Texture and blending support in FP16 format is only required for SM3.0 graphics benchmarks. These tests also use FP16 filtering, but if the GPU does not support this feature, then a special shader is used to emulate it, which allows cards based on Radeon X1000 to pass SM3.0 / HDR tests, since these GPUs do not support texture filtering in format with floating point. The SM3.0/HDR graphic tests use post-processing, during which the image is superimposed: the bloom effect, the star effect that emulates a six-bladed camera shutter, and the reflection effect that occurs in the lenses. Finally, the resulting image goes through a tone-mapping process in order to obtain the correct color values ​​for traditional displays.

According to the developer, the new test package uses all the key features of SM3.0, except for the vFace register.:

- vPos register
- Derived instructions
- Dynamic flow control
- Large number of interpolators
- Large number of constants
- More instruction slots LODVertex - Fetch textures from the vertex shader (required to pass the Shader Particles test)



Dynamic shadows have appeared in Futuremark's graphics test suites since 3DMark2001. Then they were created using projection shadow maps, which was a fairly undemanding method that had a number of limitations, in particular, the object could not cast a shadow on itself. In addition, the shadow was projected onto all surfaces below the object, even the floor of the room several floors below. 3DMark03 uses a different technique for creating dynamic shadows, the so-called stencil shadows. This method works differently: the edges of the object, seen from the side of the light source, are highlighted as a polygon devoid of illumination. Everything that is in the volume of this polygon is in shadow. This technique is devoid of the shortcomings of the previous one and allows the object to cast a shadow on itself,

The fact is that sampling the edges of the object, which should become the volume of the shadow, is a rather resource-intensive operation, and the polygons that form these volumes consume a large proportion of the scene filling speed, although they are invisible.

In 3DMark05, a new method for generating dynamic shadows was applied, using the so-called LiSPSM-maps (Light Space Perspective Shadow Maps). 3DMark has improved this technique by using a different type of shadow map called Cascaded Shadow Maps, or CSM. Using CSM allows you to get shadows for all objects on the screen, regardless of their angles.

This method works by dividing the view frustum into 5 sections along the Z axis. Each section is shaded using a standard 2048x2048 uniform shadow map. If the GPU supports depth textures, a depth map in D24X8 or DF24 format is used, otherwise, the R32F component of the 32-bit floating point texture is used as the depth map. Hardware shading is enabled by default (except for D24X8 in SM3.0/HDR tests), but can be disabled by user preference.

Any method has its drawbacks. Although the resolution of depth maps is very high, sometimes this is not enough, and, as in 3DMark05, flickering can occur at the edges of the shadow in some cases - the so-called projection aliasing (projection aliasing). This phenomenon can occur when the direction of the normals is perpendicular or almost perpendicular to the direction of illumination. Currently, it is almost impossible to get rid of it without significant performance losses.

To smooth the edges of the shadows in the new engine in the SM3.0 / HDR tests, an array consisting of 16 samples (4x4) is used. For each of the shadow's edge pixels, this array is rotated by a random angle. The presence of 16 reference points improves the quality of shadow smoothing, but requires additional hardware resources. Point sampling is used for both hardware overlay shadow maps and shadow maps in R32F format. The SM2.0 tests use a smaller 4-pixel (2x2) core, but if the GPU hardware supports D24X8, DF24, or Fetch4 depth buffer samples, only one bilinear sample is taken. The quality of smoothing is somewhat different. In case the user wishes to compare the rendering performance of different architectures, hardware overlay of shadow maps can be turned off; in this case, dynamic shadows are always created using R32F depth maps, and their anti-aliasing is done with four samples.

Generating dynamic shadows with depth maps makes sense with 3DMark06, as this method is already being used by game developers and will continue to be used, according to Futuremark. As for texture compression, all color maps in 3DMark06 are compressed using the DXT1 algorithm, alpha maps are compressed using the DXT3 algorithm, and normal maps are compressed using the DXT5 algorithm. The 3Dc method, which is specific to ATI Radeon X700 and higher cards, is not supported.

3DMark06: graphics benchmarks

There are four graphics tests in the new Futuremark package, which are divided into two groups. The first one works within the framework of SM2.0, the second is designed to be supported by the SM3.0 graphics accelerator. Let's start in order, with SM2.0 tests. The first SM2.0 graphics test is a reworked version of the first game test, "Return to Proxycon", which was part of 3DMark05. The scene shown during the test belongs to the genre of sci-fi 3D shooters. A group of Space Marines, supported by heavy armored infantry, attack and capture the Proxycon space station in order to extract some kind of artifact (a scene with it can be seen in Demo mode). Compared to the original, the number of light sources has increased significantly (26 versus 8), the resolution of shadow maps has increased, and the detail of the scene has become higher.

The test is somewhat atypical when compared with modern shooters - in the latter, such large-scale open spaces and battles are rare. The most striking example of this is Doom III with its numerous narrow corridors and rare gaps of any spacious rooms. Exceptions in the sci-fi shooter genre are rare today, but still do occur. For example, in Starship Troopers you can also see larger scenes with 200-300 enemy models in the frame.

The second SM2.0 graphics test is also not new - its progenitor is the second 3DMark05 gaming test, "Firefly Forest". As before, the basis of the test is dynamically generated vegetation, which is very abundant in the test. Although the scene space in this case is very limited, due to the huge amount of vegetation, it can serve as a good testing ground for testing GPU performance when applying shadows and working with lighting, evaluating the efficiency of vertex processors, as well as the system's central processors;). Compared to the similar 3DMark05 test, another "firefly" appeared in the test, the shadow overlay method was changed, and the resolution of depth maps / hardware shadow maps (hardware shadow maps) increased.

The following two tests exclusively use the SM3.0 profile and therefore only work on video adapters that support Shader Model 3.0. The first SM3.0 graphics test is nothing more than a significantly revised and improved version of the third 3DMark03 game test called "Canyon Flight". In this test scene, HDR is used, including when working out reflections / refractions (refraction).

As before, the water surface uses depth fog to create the illusion of depth, but in addition to this, its surface is distorted using two scrolling normal maps and four four Gerstner wave functions, resulting in water looks very realistic. Complex heterogeneous fog is used to simulate a humid climate. Also, the algorithm for rendering the sky is complicated. The scene still has only one light source - the sun, but due to the large scale and complex shape of the canyon walls, it is very difficult to apply dynamic shadows.

The second SM3.0 graphics test is unparalleled in previous versions of 3DMark and is completely new. It demonstrates the use of HDR and dynamic shadows in large areas using the example of an abandoned arctic station. The main feature of the test is the change of day, during which one can observe the lengthening of the shadows cast by objects, which is a demonstration of the flexibility of the CSM method. Snow uses a Blinn-Phong shading model, 2 normal maps and 1 color map, and a subsurface scattering effect that makes it almost indistinguishable from the real thing. Also, the test can serve as an indicator of the performance of the graphics adapter when working with particle systems - with their help, a snowstorm is simulated in the scene.

3DMark06: processor tests

One of the features of the new 3DMark06 is the new ideology used in calculating the final index. While the previous version of this benchmark gave a final result based only on the performance of the graphics subsystem, the 3DMark06 index is calculated based on both the readings taken during the graphics test and the CPU test. That is, the final score given by the test depends on both the speed of the video card and the speed of the CPU.

This innovation is caused by the desire of developers to make 3DMark06 not just a benchmark for determining the relative performance of the video subsystem, but also a measure of the performance of the platform as a whole in terms of modern 3D games. This approach has a completely logical justification: modern gaming applications have begun to make rather high demands not only on graphics performance, but also on the power of the computing resources of the central processor. This trend is expected to continue in the future, as game software developers will pay more and more attention to the issues of high-quality modeling of the physical environment and artificial intelligence of objects operating in the game.
Thus, the CPU test in 3DMark06 has become an integral and important part of it. In light of this, the Futuremark programmers have made this test more in line with reality. It's no secret that, for example, the CPU test in 3DMark05 had little to do with performance in games. This is not at all surprising: the measurement of processor performance in it took place using far-fetched algorithms that have nothing to do with reality. In particular, the processor index in 3DMark05 was calculated based on the results of vertex shader execution by the processor. A common game task for the CPU, isn't it?
The problem with evaluating processor performance in previous tests of the 3DMark family was that they did not have specialized algorithms similar to those used in real games. In the new 3DMark06 test, this defect has been corrected. 3DMark06 CPU benchmarks are based on special algorithms that are most directly related to CPU load in 3D games.
The measurement of processor performance in 3DMark06 is performed by simulating a real game situation, called the designers of the Red Valley benchmark. The action in this test takes place around a fortress sandwiched between two mountains. The foot of these mountains is dotted with ravines, along which high-speed cars rush, the task of which is to break through to the fortress, avoiding collisions and defending enemy forces. The defense of this outpost uses a kind of flying tanks, which, although slow, are equipped with short-range missiles. In total, 87 bots of these two types participate in the Red Valley scene.
The output of graphics during the processor benchmark is entirely handled by the video subsystem. To reduce the impact of graphics performance on the result of processor tests, a resolution of 640x480 is used, and, in addition, dynamic shadows are turned off. At the same time, the processor is occupied exclusively with its typical functions: it is entrusted with game logic, modeling the physical environment and endowing bots with artificial intelligence. Physics in Red Valley is calculated using the AGEIA PhysX library, which is currently quite popular among game developers, while the intelligence of bots is achieved by solving problems of finding paths in a graph.


It should be noted that due to the large number of intelligent bots inhabiting Red Valley, the processor test is somewhat reminiscent of a real-time strategy. However, it should be understood that 3DMark06 is not supposed to be like modern games. The purpose of this benchmark is to simulate future gaming applications, which Futuremark developers believe will feature a much larger number of active smart objects than modern games.
Focusing on the games of tomorrow required the creators of 3DMark06 to optimize the processor test for the most modern dual-core processors. Moreover, this test is able to efficiently load a CPU with a large number of cores, especially since the task of finding optimal paths for a large number of objects is easily parallelized. In general, calculations in the processor test are divided into threads as follows: one thread calculates the game logic and manages the calculation process, the second thread is involved in modeling the physics of the environment, the remaining threads (their number depends on the number of computing cores in the system) solve the problem of finding optimal paths.
When testing processors in 3DMark06, the Red Valley scene takes part twice with different algorithm settings. The first time more resources are devoted to artificial intelligence modeling, the second time the emphasis is on the calculation of the physics of the environment.

3DMark06: Theory Tests

This category in 3DMark06 contains all the theoretical tests that were part of 3DMark05, as well as two new tests - Shader Particles Test (SM3.0) and Perlin Noise (SM3.0). As the name suggests, both tests require Shader Model 3.0 support to work.

Shader Particles Test (SM3.0)- somewhat reminiscent of the particle systems test from 3DMark 2001, but unlike it, it uses the capabilities of Shader Model 3.0. The physical model of particle behavior is calculated using pixel shaders, then their visualization is carried out by using the texture sampling function from vertex shaders. The trajectories of 409600 particles in a simple gravitational field in the presence of medium resistance are calculated using Euler integration, and a check is made for the collision of these particles with the height field. In addition to Shader Model 3.0 support, the test requires the GPU to be able to fetch textures from vertex shaders (vertex texture fetch), so it only works on cards with the GeForce 6/7 architecture - ATI Radeon X1000 does not support VTF.

Perlin Noise (SM3.0)- uses the so-called 3D Perlin noise to simulate realistic changing clouds. Perlin noise is often the basis for procedural textures and some modeling techniques, and in the future its popularity will only increase, since the effects created with its help, although they require high computing power, but relatively lightly load the memory subsystem of the video adapter, the performance of which is growing much slower than GPU math performance. The pixel shader used in this test consists of 495 instructions, 447 of which are arithmetic and 48 are texture lookups. For reference: the minimum specifications that fit into the SM3.0 standard require support for shaders with a length of up to 512 instructions. All texture instructions create a single 32-bit 256x256 texture. Its volume is only 64 KB, so the test is undemanding to the amount and frequency of video memory.


All other tests, including batch size tests, remain the same.