What use of FP texture or buffers are you looking at for the next 3DMark? Specifically which do you feel is likely to be used more in near-future games? Do you feel that the choice you're making is influenced more by technical reasons or by hardware support?

All of our FP textures also act as render targets. We do not use FP formats for things like surface textures within the scenes. We believe that conventional texture formats, especially compressed ones, are still the best option for such use. This is because reflectance values, surface normals, etc. have a very constrained range. The higher precision and range provided by FP formats are much more useful when dealing with actual light values.

Are we likely to see FP buffer/textures used throughout all of the new tests or just select ones?

Well, for the HDR tests we use them of course, but also in the SM2.0 tests for the shadow maps.

FP textures can have quite a large memory footprint and, for certain hardware, they were used significantly throughout 3DMark05 for the PSM. Is the lack of compression formats for FP textures a big deal right now or do you think they aren't used enough for it to matter? Could you use something like 3Dc+ for this?

Current hardware does not support using compressed formats for render targets. Since our use of FP textures is limited to render targets, we cannot use any compressed formats anyway. At the moment we don't see it as that big a deal.

Although 3DMark05 only required 128MB of video memory as a minimum requirement, in testing we found that many driver/hardware combinations allocated far more than this for the 3 games tests. Does this mean that you will increase the minimum requirement to 256MB for the next release or stay with 128MB? If it's the former, how would this affect such cards as Radeon 9800s or GeForce 6600 GT’s, which have reasonable shader performance, but only 128MB of local memory?

The next 3DMark will require 256MB to ensure that there is no unnecessary swapping going on (System RAM <-> Video RAM). According to our mission of producing forward looking benchmarks to show performance of new hardware, we wanted to take a leap forward, and let the artists have more freedom to create visually stunning content. This doesn’t mean that the next 3DMark won’t run on 128MB hardware, but the performance hit can be quite severe. Several games are already limited by the amount of VRAM (at very high detail settings, which is comparable to the detail level in the next 3DMark), so I don’t see any problems with our decision. It is a known fact that VRAM has an impact on performance if the game is using a load of huge textures & data. Enable AA & AF on top of that and you need 512MB to have acceptable fps. The way we see it is that 256MB is nowadays the standard/default amount of VRAM for relatively high-end cards. 128MB was still a pretty decent amount 1-2 years ago, but things have changed pretty rapidly since. I wouldn’t be surprised if 512MB would be seen as a new standard/default in less than 2 years. Bring on 1GB cards!

Texture filtering - for the last few 3DMark versions, Futuremark has employed an unusual method of mixing the filtering used in a scene; however most review bodies tend to force a standard texture filtering (typically trilinear). Are you still planning on using the old approach or are you removing this variance?

We are still using the mix of bilinear and trilinear as we have been using since 3DMark03. We don’t think it’s sensible to use trilinear filtering where it is not really needed. In the next 3DMark we use bilinear for example for the water, since we didn’t notice any big visual differences between trilinear and bilinear, but performance-wise there was a difference.

Another thing that we need to keep in mind is that not even trilinear (not to mention anisotropic) is controllable from the application. For benchmarking purposes, it is simply too risky to blindly trust the drivers and hope that they render the trilinear as it should. All these new "brilinear" "trylinear" etc. driver optimizations have made it more difficult for us.

Of course we will have the options in the benchmark settings to force bilinear, trilinear and anisotropic filtering.

The benchmark graph tool - this was introduced in 3DMark05. How well do you think this feature has been received? Are you planning on increased the number of recording variables for the next 3DMark, to include examples such as memory allocation, number of render targets used or driver idle time?

The Graph tool was introduced in 3DMark05 by the request from the media professionals. I am not really sure how well it was received, but I guess pretty well since we have got a bunch of feedback about it.

We are not sure about adding new recording variables to the next 3DMark. It all depends on how much time we have to do such additions. Our main priorities are the graphics tests, and the CPU tests.

The good thing with the additional tools such as the graph tool is that we can add more options to it in a patch/update. As long as it doesn’t affect the performance, it is doable.