facebook rss twitter

Review: Futuremark 3DMark06 Analysis

by Ryszard Sommefeldt on 4 March 2006, 10:14

Quick Link: HEXUS.net/qaepx

Add to My Vault: x

3DMark06 Breakdown

3DMark06 was released on the 18th of January, just under 2 weeks ago at the time of writing. Futuremark used 3DMark05 as a reference point, building on the work done there to create 06. The result is a benchmark that features the same game three game tests as 05, updated with new rendering technology, along with an exclusive new test just for 06.

Those four tests were then segmented into two Shader Model 2.0 and two Shader Model 3.0 tests.

The first two game tests from 05, which previously took advantage of an SM3.0 compile target if available, are now strictly SM2.0. Game test three - Canyon Flight - and the new test will only run on SM3.0 compile targets. So there's some rejigging of what Shader Model is used per test. However, and somewhat hilariously, there's use of features only available on SM3.0 products in the SM2.0 tests, used outside of the strict API. More on that later.

On top of that, Futuremark have re-engineered the renderers used. Note the plural.

Shader Model 3.0

Futuremark claim support for all the main Shader Model 3.0 features, including the vPos register (holds screenspace coords per pixel, masked), derivative instructions (ddx/ddy), dynamic flow control, vertex texture fetch and friends. Only the vFace register (tells the shader program whether the current fragment is back or front facing) is unused, according to Futuremark.

In addition to the apparent thorough use of SM3.0 shader program features in their SM3.0 tests, especially in the pixelshader, Futuremark make heavy use of high dynamic range surface formats. FP16 textures are required for the HDR rendertargets, being able to blend them in hardware is a requisite for the tests running and, additionally, if the hardware is also able to filter FP16 surfaces that's made use of too. A pixelshader program is used for filtering otherwise.

Shader Model 2.0

Futuremark make no claims about how they use Shader Model 2.0 in 3DMark06, in terms of specific features, which is a shame.

New shadowing engine

I talked a little bit about 3DMark06's shadowing engine in our initial article, but I'll go over it again here. From the 3DMark06 whitepaper, Futuremark claim the following for the shadowing engine.

Futuremark call the technique Cascaded Shadow Mapping, which splits the shadow map rendering up across 5 chunks of the screen, split via depth. Each main shadow map is a 2Kx2K texture, created using a number of formats depending on what's supported by the hardware. This is where it gets a bit scary.

If the hardware supports a format called DF24, a single channel format currently supported only by R5-series ATI chips that aren't R520, 3DMark06 will create its 2K² maps using that surface format. The format is tied to ATI's Fetch4 feature, and the test for DF24 is the test for Fetch4. More on that shortly.

If DF24 isn't available, the hardware will use D24X8, a 32-bit unpacked single-channel format with 24 bits for depth. D24X8 is a specific depth texture format, meaning the hardware must advertise support for depth textures, and 3DMark needs to detect that support properly. If neither DF24 or D24X8 are available, the hardware will use R32F, a 32-bit single-channel format.

So there's three codepaths there, depending on what the hardware advertises and what 3DMark detects. For point lights, 1K² surfaces are used, again using the same format 'detection' as with the main shadow map. First DF24, then D24X8, then R32F.

Then we move on to shadowmap filtering, where the 3DMark06 renderer samples from the shadowmap to determine if it needs to filter and soften an umbra/penumbra boundary, where the fragments being rendered blend from being fully shadowed, to partially shadowed, to fully lit.

Shadowmap filtering

In the SM3.0 tests, 3DMark06 uses a custom 16 sample filter kernel, point sampling from the shadowmap, agnostic of surface. The kernel is randomised per pixel, too. The engine rotates the filter kernel to achieve the randomisation. There's no hardware acceleration of the filtering here, using PCF or Fetch4 or otherwise, due to the tap count.

In the SM2.0 tests, 3DMark06 uses a 4 sample filter instead. If NVIDIA hardware PCF (percentage closer filtering) is present, the engine uses that (sample and filter performed by the hardware). If ATI Fetch4 is available, the engine uses that for the sampling and filters bilinearly in a pixelshader.

If no hardware support for accelerated 4-sample single-channel texel fetch and/or filtering is available, 3DMark06 uses a 4-tap rotated kernel with point sampling. Those choices fit in with the codebase maintenance Futuremark have to perform with the main shadowmaps.

Futuremark assert the codebase maintenance is what games developers have to tackle in all of their games, therefore it's fine for them to to undertake the same task for their benchmark.

High Dynamic Range Rendering

Futuremark have added high dynamic range rendering to their Shader Model 3.0 graphics tests. They use a 64-bit, 4-channel FP surface for all HDR rendertargets, post-process the final blended rendertarget surface for a lens effect and exaggerated bloom, before tone-mapping to bring the values into the right range for display on your monitor.

The result is a good one, Canyon Flight and Deep Freeze generally looking fantastic as far as lighting and shadowing goes. In the Deep Freeze test Futuremark use a pixelshader to simulate the light being refracted and scattered by the ice cover, adding an extra dimension to the realism it aims to achieve.

Other renderer details worthy of note

The engine compresses all normal maps with DXT5, a two-channel alpha+colour format giving 4:1 input:output compression on pixels, and the Shader Particles feature test textures in its vertex shader program.

Graphics test split and CPU test additions

3DMark06 introduces specifically named CPU tests, brought into the mix to highlight the increasing reliance on the host processors for more than just simple game logic and driver interaction. Games are increasingly moving towards using multiple processor cores for more advanced game logic, physics, artificial intelligence and other CPU-intensive tasks.

Therefore 3DMark06's inclusion of CPU tests makes sense if it's to live up to its name as the Gamer's Benchmark.

Futuremark have also split what they previously called game tests up into new graphics tests. Two each to test Shader Model 2.0 and Shader Model 3.0 graphics hardware, the SM3.0 tests are also called SM3.0/HDR graphics tests, by virtue of the lighting model.

Feature Tests

3DMark06 retains the majority of 05's feature tests, including the useful fillrate test (well improved versus what shipped with 03, with less memory bandwidth pressure). The vertex shader tests are untouched, too.

There are two new Shader Model 3.0 tests, though. The Shader Particles test uses vertex texturing and a fairly complex pixel shader to display around 400,000 particles in real-time (or as close as your system will allow!). The test requires SM3.0 hardware that supports VS3.0 vertex texturing, Futuremark maintaining just a single codepath.

The Perlin Noise test uses a pixelshader declared as PS3.0, requiring the use of Shader Model 3.0 hardware. There's a simple vertexshader to setup the fragments and Futuremark claim a 9:1 ALU:TEX ratio for the ~500 instruction PS program.

Scoring

I'd analyse the scoring system for 3DMark06 in depth if it wasn't so inherently broken, simply because it weights SM2.0 and SM3.0 tests separately. 3DMark06 can end up ranking slow SM3.0 hardware ahead of fast SM2.0 hardware, which doesn't reflect the reality of how games are played, and will be played in the time period that 3DMark06 is supposed to address, on those parts. Urgh.

Futuremark also fail to address the issue of FP16 MSAA support in only one vendor's parts, in the SM3.0 tests. Instead of having hardware that doesn't support MSAA in the SM3.0 tests report a score that reflects that (which can do MSAA in the SM2.0 tests), it doesn't report a score at all. Feature variation across vendors results in a situation that Futuremark don't address, which would let 06 better reflect a real-world reality about what gamers have to do depending on the hardware they own.

Summary

Reuse of old art assets, one new test and a substantial rework to the lighting and shadowing facets of the rendering engine are the major highlights, graphics wise. The rework sees 06 push graphics hardware to a greater extent than 05, as expected, Futuremark moving things on nicely in that respect.

Futuremark's research undoubtedly shows them that cascaded shadowmaps will see good adoption in coming games, making them suitable for what they've done for 3DMark06.

The addition of the new CPU tests sees Futuremark position 3DMark06 as a complete system test more in tune with the Gamer's Benchmark moniker, and the new SM3.0 feature tests claim to exercise compliant hardware outside of what can be done in SM2.0.