3DMark 2006
YOM: 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: Among the fundamentally new features, we note support for HDR, Uniform Shadow Maps, support for multi-core CPU and a focus on using Shader Model 3.0, although not exclusively – 2 out of 2.0 graphics tests run within Shader Model XNUMX.
The rest of the changes are quantitative in nature: once again the detail of the test scenes, the number of light sources, the complexity of the shaders used, texture resolution, etc. have been increased. Thus, the overall concept of 3DMark06 is to target SM3.0-compatible GPUs.
3DMark06: graphics engine features
As you know, a new graphics engine was developed for 3DMark05, which had nothing in common with the previously used MAX-FX engine, and was much more similar to real game engines. The 3DMark06 engine is its modification, which has received full support for Shader Model 3.0, as well as textures and blending in the FP16 format. The last two points mean nothing more than the possibility of using HDR. Futuremark predicts that support for high dynamic range will be common in next-gen games, although the number of such games is very small at the moment. As in 3DMark05, the shaders that make up a particular material are generated dynamically, in HLSL format. They are then compiled to optimally match the GPU installed in the system, either automatically or according to a user-defined profile.
FP16 texture and blending support is required exclusively for the SM3.0 graphics tests. These tests also use FP16 filtering, but if GPU does not support this feature, a special shader is used to emulate it, which allows Radeon X3.0-based cards to pass SM1000/HDR tests, since these GPUs do not support floating-point texture filtering. SM3.0/HDR graphics tests use post-processing, which involves applying a bloom effect, a "star" effect that emulates a six-blade shutter in cameras, and a reflection effect that occurs in lenses. Finally, the resulting image undergoes a tone-mapping process 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, with the exception of the vFace register:
-vPos register
-Derived instructions
-Dynamic flow control
-A large number of interpolators
-A large number of constants
-More number of instruction slots
-Texture instructions with explicit LODVertex
-Fetching textures from the vertex shader (required to pass the Shader Particles test)
Dynamic shadows have appeared in Futuremark graphics test suites since 3DMark2001. Back 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 onto the floor of a room several floors below. 3DMark03 used a different technique for creating dynamic shadows, the so-called stensile shadows. This method works differently: the edges of the object, visible from the side of the light source, are highlighted as a polygon devoid of lighting. Everything that is within the volume of this polygon is in the shadow. This technique does not have the disadvantages of the previous one and allows the object to cast a shadow on itself, but it is not universal and is only good for certain types of scenes and for low-poly objects.
The fact is that sampling the edges of an object, which will become the shadow volume, is a fairly resource-intensive operation, and the polygons that form these volumes consume a considerable share of the scene’s filling rate, although they are invisible.
3DMark05 introduced a new method for generating dynamic shadows using so-called LiSPSM maps (Light Space Perspective Shadow Maps). 3DMark has taken this technique further 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 splitting the view frustum into 5 sections along the Z axis. Each section is shaded using a standard 2048x2048 uniform shadow map. If GPU supports depth textures, a depth map in D24X8 or DF24 format is used, otherwise, the R32F component of the texture in 32-bit floating-point representation is used as a depth map. Hardware shading is enabled by default (except for D24X8 in SM3.0/HDR tests), but can be disabled at the user's discretion.
Any method has its drawbacks. Although the resolution of the depth maps is very high, sometimes this is not enough, and, as in 3DMark05, in some cases flickering can occur at the edges of the shadow - so-called projection aliasing. This phenomenon can occur in cases where 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 losses in performance.
To smooth the edges of shadows in the new engine, the SM3.0/HDR tests use an array consisting of 16 samples (4x4). For each shadow edge pixel, this array is rotated by a random angle. Having 16 sample points improves the quality of shadow smoothing, but requires additional hardware resources. Point-by-point sampling is used for both hardware shadow mapping and R32F shadow maps. The SM2.0 tests use a smaller kernel consisting of 4 pixels (2x2), but if GPU hardware supports sampling from the depth buffer in D24X8, DF24 or Fetch4 format, only one bilinear sample is taken. The quality of anti-aliasing varies slightly. In case the user wants to compare the rendering performance of different architectures, hardware shadow mapping can be turned off; in this case, dynamic shadows are always created using R32F depth maps, and their anti-aliasing is performed with four samples.
Generating dynamic shadows using depth maps makes sense in the case of 3DMark06, since this method, according to Futuremark, is already used by game developers and will be used more widely. As for texture compression, all color maps in 3DMark06 are compressed using the DXT1 algorithm, alpha maps - using the DXT3 algorithm, and normal maps - using the DXT5 algorithm. The 3Dc method, which is specific to ATI Radeon X700 and higher cards, is not supported.
3DMark06: graphics tests
There are a total of four graphics tests in the new Futuremark package, which are divided into two groups. The first works within SM2.0, the second is designed to be supported by the SM3.0 graphics accelerator. Let's start in order, with the SM2.0 tests. The first graphics test, SM2.0, is a remake of the first gaming test, "Return to Proxycon", which was part of 3DMark05. The scene shown during the test belongs to the genre of sci-fi XNUMXD shooters. A group of space marines, supported by heavy armored infantry, attacks and captures the Proxycon space station in order to obtain a certain artifact (a scene with it can be seen in the mode Demo). Compared to the original, the number of light sources has increased significantly (26 versus 8), the resolution of shadow maps has increased, and the scene detail 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 openings of any spacious rooms. Exceptions in the SF (Sci-Fi) shooter genre are rare today, but they still do occur. For example, in Starship Troopers you can see larger scenes with 200-300 enemy models in the frame
The second graphics test, SM2.0, is also not new – its ancestor is the second game test of 3DMark05, "Firefly Forest". As before, the basis of the test is dynamically generated vegetation, of which there is a lot 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 performance GPU 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, the test has one more "firefly", the shadow application method has been changed, and the resolution of depth maps/hardware shadow maps has been increased.
The next two tests use exclusively the SM3.0 profile and, accordingly, only work on video adapters that support Shader Model 3.0. The first SM3.0 graphics test is nothing more than a significantly redesigned and improved version of the third 3DMark03 gaming test called "Canyon Flight". This test scene uses HDR, including when testing reflections/refractions (refraction).
As before, the water surface uses a depth fog to create the illusion of depth, but in addition, its surface is distorted using two scrolling normal maps and four Gerstner wave functions, resulting in water looks very realistic. Complex heterogeneous fog is used to simulate a humid climate. Also, the algorithm for drawing the sky is more complicated. The scene still only has one light source, the sun, but the large scale and complex shape of the canyon walls makes it very difficult to apply dynamic shadows.
The second graphics test, SM3.0, has no analogues in previous versions of 3DMark and is completely new. Using an abandoned Arctic station as an example, it demonstrates the use of HDR and dynamic shadows over large areas. The main feature of the test is the change of day, during which one can observe the lengthening of shadows cast by objects, which demonstrates the flexibility of the CSM method. The snow uses the Blinn-Phong shading model, 2 normal maps and 1 color map, as well as a subsurface scattering effect, making 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: CPU tests
One of the features of the new 3DMark06 is the new ideology used to calculate 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 tests. That is, the final score given by the test depends on both the speed of the video card and the performance CPU.
This innovation is caused by the desire of the 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 from the point of view of modern 3D games. This approach has a completely logical justification: modern gaming applications have begun to place quite high demands not only on graphics performance, but also on the processing power of the central processor. It is expected that this trend will worsen in the future, as game software developers begin to 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.
So the test CPU in 3DMark06 has become its integral and important part. In light of this, Futuremark programmers have made this test more relevant to reality. It is no secret that, for example, the test CPU in 3DMark05 had little to do with gaming performance. This is not surprising at all: it measured processor performance using contrived algorithms that had nothing to do with reality. In particular, the processor index in 3DMark05 was calculated based on the results of the processor executing vertex shaders. The usual CPU a game task, isn't it?
The problem with evaluating processor performance in previous 3DMark tests was that they did not have specialized algorithms similar to those used in real games. In the new 3DMark06 test, this shortcoming has been corrected. 3DMark06 processor tests are based on special algorithms that are directly related to the load CPU in 3D games.
Processor performance is measured in 3DMark06 by simulating a real game situation, called the Red Valley benchmark by the designers. 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 vehicles rush, whose task 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. There are a total of 87 bots of these two types participating in the Red Valley scene.
Graphics output during the processor benchmark is entirely handled by the video subsystem. To reduce the impact of graphics performance on the results of processor tests, a resolution of 640x480 is used, and, in addition, dynamic shadows are disabled. 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 should not be like modern games. The objectives of this benchmark include modeling future gaming applications, which, as Futuremark developers believe, will feature a much larger number of active intellectual 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 and 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, the calculations in the processor test are divided into threads as follows: one thread calculates the game logic and controls the counting process, the second thread is used to simulate the physics of the environment, the remaining threads (their number depends on the number of computing cores in the system) solve the problems of finding optimal paths.
When testing processors in 3DMark06, the Red Valley scene takes place twice with different algorithm settings. The first time, more resources are allocated to modeling artificial intelligence, the second time, the emphasis is on calculating the physics of the environment.
3DMark06: theoretical tests
As part of this category, 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 test for processing particle systems 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 rendered using the texture sampling function from vertex shaders. The trajectories of 409600 particles in a simple gravitational field in the presence of environmental resistance are calculated using Euler integration, and the collision of these particles with the height field is also checked. In addition to supporting Shader Model 3.0, the test requires the GPU to be able to fetch textures from vertex shaders (vertex texture fetch), so it only works on cards with GeForce 6/7 architecture - ATI Radeon X1000 does not support VTF.
Perlin Noise (SM3.0) - uses so-called three-dimensional Perlin noise to simulate realistic changing clouds. Perlin noise is often the basis for procedural textures and some modeling techniques, and its popularity will only increase in the future, since the effects created with its help, although they require high computing power, are relatively light on the video adapter memory subsystem, the performance of which grows much more slowly than mathematical performance GPU. 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 texture with a resolution of 256x256. Its size is only 64 KB, so the test is undemanding to the size and frequency of video memory.
All other tests, including batch size tests, remain the same.