Vertex texture fetching seems to be big news at the moment (see ATI's Radeon X1000 series for more details); do you have plans to make use of this feature or test it separately in some way? If so, then would this not require you to use something like ATI's R2VB as this could be supported by all SM3.0 implementations currently on the market, whereas sticking to SM3.0 vertex texture fetching would only be supported by one IHV?

Unfortunately I’m not able to comment on this one as the new feature tests for the next 3DMark are still in development (at the time of writing this) and I can’t say for sure if they will make it to the final product.

Geometry Instancing. There are now several native hardware implementations available on the market for this feature, plus there are also various indirect / alternative methods that achieve the same result. Given that it has already appeared in a best selling game, the function has some merit to it - what are your thoughts on using it in 3DMark and have you experimented with it recently?

We thought about it already in 3DMark05, but none of our scenes really required geometry instancing. I presume that the game you are referring to is Crytek’s Far Cry and yes in that game GI really works. In 3DMark we don’t have that vast landscape which would benefit of GI or any other situations where it would improve quality or performance.

Of course we have made some research into it, and will use it if we create something that would benefit from it but not for the next 3DMark.

If you're sticking with shadow maps for the next 3DMark, will we see a greater use of SM3.0 functionality for the filtering - e.g. using branching for deciding which pixels need to be filtered? What about raising the number of samples, etc. instead?

The current implementation in the next 3DMark is using shadow maps, but we are using a different technique than we did in 3DMark05. In 3DMark05 we used something called LiSPSM (Light Space Perspective Shadow Maps), whereas in the next 3DMark we use something called CSM (Cascaded Shadow Maps). In the next 3DMark we use 5 pieces of 2048x2048 shadow maps (in 3DMark05 we only use 2). The two approaches are great, but CSM seems to be even better and more robust than LiSPSM.

To make those shadows smooth, we use 16 samples of a randomly rotated kernel for every pixel. I am not sure if anyone has done this before in any games/apps, but it works great and you really get smooth edged shadows for every pixel. Of course we would like to use even higher numbers of samples, but when we did some research in using higher amounts, it really killed the performance. 16 seem to be the sweet spot for today’s high-end graphics card, for which the next 3DMark is targeted. This smoothing technique wasn’t possible to do in SM2.0.

In 3DMark03 you kept the number of lights per surface in GT2 and 3 deliberately low in order to prevent the vertex processing load for going too high. Since the use of PSM removes this need, what ratio of dynamics lights per surface, on average, have you been working with for the next game tests?

For the next 3DMark we wanted to increase the number of lights/scene, and it really shows (in terms of quality, and performance)! Basically we use 1 (or 2) directional lights in every scene (usually the sun/moon), since that’s the only light that uses CSM. Any other lights (point and spotlights) use standard shadow maps.

While I won’t disclose now how many lights we use per scene, I can tell that in one of the scenes we are using a bunch of them.

A long-held criticism, by some people at least, of 3DMark is the balance between the vertex and pixel processing workloads, in that it hasn't matched the typical ratios seen in games since the introduction of the very first 3DMark (i.e. 3DMark is vertex heavy, games aren't). You've explained the reasoning behind this to be along the lines of you've needed do to this, to ensure that graphics cards are suitable stressed - there is surely now enough scope and possibility within SM2.0/3.0 capable cards to produce a benchmark that is far more pixel (or pixel shader) limited, so are we likely to see a cap on the vertex count for the last two 3DMark versions? What are current thoughts about how 3DMark and games have compared in the area of vertex count and vertex processing?

In the next 3DMark we have upped the pixel load a lot! It was one of our main targets with the next 3DMark – to get the pixel load up and as much as possible. To simply create pixel load isn’t that easy though. Of course it isn’t that hard to come up with complex math to create more work, but the question is, is it really worth it? When we create new visual effects for 3DMark, we always try to optimize the shaders as much as possible, since keeping long shaders in there just for the fun of it, isn’t feasible. I don’t think that going crazy with the shaders is the best approach. We need to keep in mind that no game developers would do so.

Personally I think that it is a shame that the amount of vertex processing isn’t on the same level as pixel processing. Currently we have amazing pixel processing power in the latest hardware, but we are still very limited with vertex pipes. Developers need to come up with new tricks (such as parallax mapping) in order to get somewhat great detail levels without adding too much geometry into the scene. I am not sure if that’s a really great idea. As I pointed out earlier, parallax mapping works nicely in certain situations, but it doesn’t make objects round, and it doesn’t work in corners/near the edges. There are plenty of papers & screen shots on the net of several approaches to parallax mapping, and though I have seen some which are impressive, none of them solves all the inherent shortcomings.

3DMark is known to use a pretty high amount of polygons, and we will keep on doing so. In the next 3DMark we have upped the amount of polygons a little bit, but not as much as compared to 3DMark03 -> 3DMark05.