One feature that has seen a lot of publicity over the past year is High Dynamic Range rendering. With graphics hardware that have good support for float textures and PS2.0, HDR effects can be achieved reasonably effectively, and more recently GeForce 6800 has introduced floating point filtering and blending which should enable a simpler method to high quality HDR. What are your thoughts on these techniques and will you be featuring HDR in the next benchmark?

Patric: HDR is a great thing! We would like to use HDR in all game tests, but the lack of fully supporting hardware prevents us from doing that in this next 3DMark. All (or at least most) DX9 hardware have floating point support, but in order to really utilize HDR, you also need full support for blending and filtering of float textures. Those are still rarely supported features.

Although Normal mapping, for generation models that appear higher detailed than they actually are, has been with us for some time, the technique appears to be only recently becoming more ubiquitous. ATI has introduced 3Dc normal map compression which should allow for high detail normal maps (hence higher detail appears on the rendered output) at a lower performance overhead - there is also a fallback method that requires a tweak to the DXT5 compressor. Will you be featuring tests with normal map compression?

Patric: DXT5 is commonly supported by today’s DX9 hardware. We will therefore most likely be using DXT5 compression for normal maps. This is still work in progress, so we’ll see what we end up doing in the final product. 3Dc is still ATI specific AFAIK, so that is not so interesting for us regarding 3DMark.

PCI Express is a new technology that has arisen over the past few months, and while not being a core 3D feature it does affect graphics boards by giving a much larger downstream and upstream bandwidth for the graphics interface to the host. Will you be taking advantage of this increased bandwidth at all? Will there even be specific tests to see the transfer rates afforded by different implementations?

Patric: This is also still work in progress. PCI-Express is indeed one of the latest hypes in PC hardware, so it would be nice to utilize that somehow.

In previous version of 3DMark we saw numerous feature tests that had lots of specific feature tests, such as EMBM or Dot3, or Pixel Shaders, however this was cut back in 3DMark03. Will we see more feature tests in the next version?

Patric: 3DMark is a very ambitious project for a small company like ours. There is so much that could yet be added when it’s time to launch. We have a mile long list on what cool feature test ideas, but we usually have so little time to actually implement some of them. By far most our efforts go into making the game tests. They are the most important part of 3DMark and the tests that offer the best measurements. When there is time, we try to add as many feature tests as possible, but once the game tests are done, there usually is way too little time left.

Nick: We dropped the sound tests for the next 3DMark simply because there isn’t such a big demand for a new sound test right now. If people want to benchmark their soundcards we suggest to use the sound tests found in 3DMark03. Of course if the demand for new sound tests grows substantially, we might add sound tests to the next 3DMark via a patch or an update, but the benchmark won’t ship with sound tests.

Due to some of the issues that arose with 3DMark03 and some disagreements with the spirit of your benchmarking guidelines, you introduced a set of optimization guidelines and an approved driver scheme which you tested to validate whether the driver stuck to you guidelines. Will you optimization policy change at all with 3DMark04? Will you still be monitoring things in a similar fashion as you are at the moment? Is there even items you can code within the benchmark itself to assist in user spotting potential issues?

Nick: Our benchmarking guidelines and optimization guidelines will stay as they are. The same rules will apply for the next 3DMark as they do for 3DMark03. We will keep on monitoring new driver releases in order to ensure reliable results, but I am not yet sure if we will have some monitoring capabilities in the benchmark itself. As most of you know, it is very difficult (if not next to impossible) to create a detection mechanism for detecting all application specific optimizations, and any detection system built-in into 3DMark isn’t really a viable option because it would be outdated in an instant. Any such mechanism could get detected in the driver, re-routed and thus making it pointless. We will however continue to research different approaches on how to “fool” the drivers in case of any application specific optimizations, and if we come up with a working solution, it will be implemented into the benchmark.