HardOCP and Doom 3 benchmarks

[Ostsol]

I really hope Beyond3D gets a copy of the benchmark and an FX5900 board to take a look at. I'd love to see how much performance in ARB2 mode has been improved.

 

[Humus]

Again there is only one company in the Openg ARB that have Proprietary extensions.

Oh, you mean like:
GL_ATI_separate_stencil
GL_ATI_texture_float
GL_ATI_vertex_array_object
GL_ATI_fragment_shader

Proprietary=vendor specific.

Proprietary != vendor specific

Prorietary = Owned and controlled by said company. To implement you need to licence it or otherwise be granted the rights.

Vendor specific = Controlled by said company. Others are free to implement. GL_ATI_vertex_array_object for instance is implemented by Matrox for the Parhelia.

Read the spec for any of those extensions, you wont find any note about them being proprietary. Open pretty much any GL_NV_ extension and you'll find "IP Status: NVIDIA proprietary" in them. These need to licenced to implement. 3DLabs has for instance licenced the GL_NV_register_combiners.

 

[andypski]

Would you consider this a decent description of what they are doing in SC?-

In this sample, the 3-D object that casts shadows is a bi-plane. The silhouette of the plane is computed in each frame. This technique uses an edge-detection algorithm in which silhouette edges are found. This can be done because the normals of adjacent polygons will have opposing normals with respect to the light vector. The resulting edge list (the silhouette) is protruded into a 3-D object away from the light source. This 3-D object is known as the shadow volume, as every point inside the volume is inside a shadow.

Next, the shadow volume is rendered into the stencil buffer twice. First, only forward-facing polygons are rendered, and the stencil-buffer values are incremented each time. Then the back-facing polygons of the shadow volume are drawn, decrementing values in the stencil buffer. Normally, all incremented and decremented values cancel each other out. However, because the scene was already rendered with normal geometry, in this case the plane and the terrain, some pixels fail the z-buffer test as the shadow volume is rendered. Any values left in the stencil buffer correspond to pixels that are in the shadow.

Finally, these remaining stencil-buffer contents are used as a mask, as a large all-encompassing black quad is alpha-blended into the scene. With the stencil buffer as a mask, only pixels in shadow are darkened

My understanding is that Splinter Cell has two preferred modes for shadows in the game.

In the first mode they use the Shadow buffer technique, where the scene is rendered to a depth texture from the light source POV and then this depth value is transformed into the view space and used as a comparison with the rasterized depth to decide whether a given pixel object is in shadow. This is the mode used on GF cards since it was inherited from the XBox as I recall.

In the second mode they use normal stencil based shadow projection similar to what you describe above. This would be used by default on other vendors cards, such as ATI, Matrox, SIS etc.

I believe they also have a third mode where they just project a shadow texture of the object onto the other objects, so you get no self-shadowing, but I'll have to check.

 

[Joe DeFuria]

Perhaps if you substituted S3 or Matrox that would be a good point. Throwing the demo up on a website likely wouldn't be the best way to avoid leaks if that is the reason they are doing it this way

Already addressed. I'm sure ATI (assuming it was them) has taken measures to avoid further leaks and communicated those measures to id. Like any company would.

In any case, if id thought it was "important at this time" to have some benchmark comparisons, having an IHV sponsor those benchmarks, without the knowledge of the other competing IHVs is simply bad form, don't you agree?

 

[Humus]

For instance, R300 runs the ARB2 path, and from what I understand, ARB2 extensions are standard OGL2 extensions, meaning that any OGL2 card should be able to run ARB2 extensions just fine.

Gah! All these '2's. There are ARB extensions, no "ARB2 extension". OpenGL2 extensions are not yet finalized. DoomIII does not use OpenGL2, except for some experiments Carmack mentioned he did when he got his 3DLabs cards. Since then, GL2 specs has changed a lot.

 

[Ostsol]

Proprietary != vendor specific

Indeed! All one has to do is look at the OpenGL extension registry. It says in NV extensions: "IP Status: NVidia Proprietary". No other company appears to do the same. . .

 

[BenSkywalker]

Andy-

From UbiSoft-

Splinter Cell shadow system is a major part of the game. On NV2x/NV3x hardware, it runs using a technique called Shadow Buffers. This technique is rendering the scene from every shadow casting light and store a depth buffer that represent each pixel viewed by this light source. Each pixel has an X, Y, Z coordinate in the light system and these coordinates can be transformed, per pixel, in the viewer coordinate system. It’s then easy to compare with the actual depth stored in the Z buffer to figure out if the pixel viewed by the camera is the same or is occluded by the pixel viewed by the light. If they are the same, it means the pixel is lighted, if the light pixel is in front of the viewer pixel, it means the pixel is in the shadow.

And for non nV hardware-

On all other current hardware, the game is using another technique called projected shadows (shadow projectors). The technique is somewhat similar, we render the scene from the light point of view but instead of storing the depth, we are storing the color intensity in a texture. That texture is then mapped per vertex on each object that is going to receive the shadow. To be able to have objects casting shadows on other objects that are themselves casting shadows, Splinter Cell is using a 3-depth levels shadow casting algorithm. In general, the first level is used to compute the shadow to be used on the dynamic actors like Sam. The second level is used to compute the shadow used by the static meshes like a table or boxes. The final level is used for the projection on the BSP. This system is allowing Sam to receive the shadow of a gate on him, then Sam and the gate can cast on a box and finally all three objects can cast on the BSP (ground). This system also has a distance check algorithm to determine if Sam’s shadow should be projected on a static mesh (like a box) or if it shouldn’t base on their relative position. Both systems have their own strength/weaknesses. The main advantage of the Shadow Buffer algorithm is how easy it is to work with. Shadow Projectors are tricky and difficult to use."

In the first mode they use the Shadow buffer technique, where the scene is rendered to a depth texture from the light source POV and then this depth value is transformed into the view space and used as a comparison with the rasterized depth to decide whether a given pixel object is in shadow.

In the second mode they use normal stencil based shadow projection similar to what you describe above. This would be used by default on other vendors cards, such as ATI, Matrox, SIS etc.

Another quote-

Stencil buffers are a depth-buffer technique that can be updated as geometry is rendered, and used again as a mask for drawing more geometry. Common effects include mirrors, shadows (an advanced technique), dissolves, and so on.

That isn't supported under DirectX?

 

[Doomtrooper]

For instance, R300 runs the ARB2 path, and from what I understand, ARB2 extensions are standard OGL2 extensions, meaning that any OGL2 card should be able to run ARB2 extensions just fine.

Gah! All these '2's. There are ARB extensions, no "ARB2 extension". OpenGL2 extensions are not yet finalized. DoomIII does not use OpenGL2, except for some experiments Carmack mentioned he did when he got his 3DLabs cards. Since then, GL2 specs has changed a lot.

ARB 2 *

 

[andypski]

That isn't supported under DirectX?

I'm losing track of this discussion now...

To recap -

Initially the conversation about shadows in Splinter Cell was sparked by your assertion that nVidia cards produce higher quality shadows than ATI cards and are thus being penalised in the benchmarks.

I responded that the shadows are the same quality when using the same technique - in this case it appears that this will be projected shadows, and so the results should be comparable provided the sites make sure that both cards use this technique.

I thought that they also supported stencil shadows, but I guess maybe I was mistaken?

As an aside I added that the shadow buffer method on the nV cards actually uses a non-standard extension to DX, so it is unfair to refer to this as a 'missing feature' in ATI cards. Additionally I pointed out that true shadow buffers can be supported in a fully DX compliant way on ATI cards.

I think that provided that we agree on this then things are fine...

 

[LeStoffer]

After thinking a bit about the info we have so far - mainly John Carmack's remark on Anandtech - I would say that it is okay with Id and nVidia showing off the darn demo.

The problem, however, is that ATI's products was benchmarked as well when we don't have a clue about whether ATI was informed or accepted that this was taking place. There is no doubt that nVidia put a lot of driver focus into Doom III while ATI might have decided to wait a bit on the Doom III-optimizations.

My point is that we don't have a freakin' clue but nonetheless these benchmarks are seen as the final score on Judgement Day. Maybe the fault is really with the reviews this time aound? (Sorry the spoil the NV vs ATI war)

 

[MuFu]

Do the Splinter Cell FSAA issues affect the benchmarking in any way?

MuFu.

 

[BenSkywalker]

Andy

I don't see that we agree

http://msdn.microsoft.com/library/d...mplesAndToolsAndTips/Samples/shadowvolume.asp

The conversation went the way it did as I had already dug up the relevant doc from Microsoft and the quotes from Ubi Soft. What is it that they are supposed to be doing that is not supported under DX?

Edit-

Forgot to mention-

Initially the conversation about shadows in Splinter Cell was sparked by your assertion that nVidia cards produce higher quality shadows than ATI cards and are thus being penalised in the benchmarks.

The NV3X boards sit with pixel pipes idle using projected shadows that would be utilized if they ran shadow buffers. Will that allow them to run faster? Can't be sure, but it wouldn't shock me. If they can both run faster and look better then they are being penalized twice.

 

[Joe DeFuria]

The problem, however, is that ATI's products was benchmarked as well when we don't have a clue about whether ATI was informed or accepted that this was taking place.

Agreed. If nvidia / id decided to let some web sites "bench" Doom3 on nVidia cards to showcase the FPS that FX can get, and the image quality it can deliver, that's one thing.

To also subject ATI's products, when ATI had no prior knowledge of this occuring, simply is not "fair." It would be different if either:

1) ATI was aware of the situation and given the opportunity to "prepare" for it

or

2) The Doom benchmark was public domain.

Maybe the fault is really with the reviews this time aound? (Sorry the spoil the NV vs ATI war)

Partly, but I really can't blame reviewers too much given the opportunity they had. Just like I don't even really blame nVidia.

I put the blame on ID SOFTWARE, for allowing such a controlled comparison to take place. ID should have either just not allowed it, produced a public demo or at least a "private" demo available to all IHVs, or even just limited nVidia to showcase it only with nVidia hardware.

 

[andypski]

Andy

I don't see that we agree

http://msdn.microsoft.com/library/d...mplesAndToolsAndTips/Samples/shadowvolume.asp

The conversation went the way it did as I had already dug up the relevant doc from Microsoft and the quotes from Ubi Soft. What is it that they are supposed to be doing that is not supported under DX?

Edit-

Forgot to mention-

Initially the conversation about shadows in Splinter Cell was sparked by your assertion that nVidia cards produce higher quality shadows than ATI cards and are thus being penalised in the benchmarks.

The NV3X boards sit with pixel pipes idle using projected shadows that would be utilized if they ran shadow buffers. Will that allow them to run faster? Can't be sure, but it wouldn't shock me. If they can both run faster and look better then they are being penalized twice.

Shadow volumes as described in the document you have there are fine, but that's not what Splinter Cell uses - they use shadow buffers, which is a different technique altogether and doesn't use the stencil buffer at all.

Shadow buffers implemented the way they do them are not supported in the DX spec. If you read Ubisoft's explanation of shadow buffers you can see that it is very different to the stencil shadows in the document you point to above.

nVidia might be able to render at double their normal pixel rate into the shadow buffer since it is a Z-only operation. However, interestingly enough -

http://www.tomshardware.com/graphic/20030306/radeon9800pro-14.html

- it seems that at least in the past their shadow buffers actually ran slower than the projected ones. Maybe this has changed in newer drivers?

The visual quality of Splinter Cell's projected shadows as described and nVidia's shadow buffers are probably fairly similar, although the projected shadows are more difficult for the application to manage.

However, any benchmark that uses a shadow buffer extension that doesn't even officially exist in the API has to be suspect, and in this case if nVidia are penalised then, frankly, so be it. It seems extremely strange to me that they should be rewarded in any way for fragmenting the specification of the DX API and introducing their own extension mechanism via a backdoor into a language that does not have an extension mechanism... that just seems wrong.

 

[nelg]

I take this to mean that when using non vendor specific paths (ARB) the ATI card is still the fastest.

"The Nvidia card will be fastest with "r_renderer nv30", while the ATI will be a tiny bit faster in the "r_renderer R200" mode instead of the "r_renderer ARB2" mode that it defaults to (which gives some minor quality improvements). The "gfxinfo" command will dump relevant information about the functioning renderer modes and optimizations. At some point, after we have documented all of the options and provided multiple datasets, Doom is going to be an excellent benchmarking tool, but for now you can still make some rough assessments with it."

 

[Ostsol]

So the DirectX spec doesn't have anything in the fixed function pipeline akin to OpenGL's GL_ARB_shadow extension? If NVidia supports some type of proprietary extension that is outside the DirectX specs then it makes sense as to why no support for shadow buffers is available for ATI cards in Splinter Cell. Still, the same thing could have been achieved via pixel shaders. . .

 

[BenSkywalker]

Shadow buffers implemented the way they do them are not supported in the DX spec. If you read Ubisoft's explanation of shadow buffers you can see that it is very different to the stencil shadows in the document you point to above.

Looking for more detail on how it is they(nv and US) are handling it. The only big difference I can see is that they are rendering out to a depth texture instead of to the stencil buffer(which is odd as SC doesn't have soft shadows from what I have seen). Everything they are doing in the samples given by nV is supported by DirectX, although it is an odd approach(utilizing resources in a fashion they weren't designed for).

 

[chavvdarrr]

Doom3 benches

Come on, why ATi should know for every single benchmark?!
Imagine the situation:
AMD releases Barton 3200+, lots of sites make reviews... and here comes Intel saying:
"oh, but its not fair, we didn't know, we could prepare making more optimised CC2003SE benchmark suite...."
AMD replies:
"But iP4 has SSE2 instructions... for apples2apples comparison we demand that no-SSE2 optimised apps be used"
Intel:
"And no 3dnow! too"
AMD:
"P4 has wider bus - 200x4 vs 200x2, NO bandwidth limited tests!"
Intel:
"Barton has more cache (640 vs 512) - no cache limited tests!"
......
......

These are curent results in Doom3 engine, like it or not.
.

 

[andypski]

Shadow buffers implemented the way they do them are not supported in the DX spec. If you read Ubisoft's explanation of shadow buffers you can see that it is very different to the stencil shadows in the document you point to above.

Looking for more detail on how it is they(nv and US) are handling it. The only big difference I can see is that they are rendering out to a depth texture instead of to the stencil buffer(which is odd as SC doesn't have soft shadows from what I have seen). Everything they are doing in the samples given by nV is supported by DirectX, although it is an odd approach(utilizing resources in a fashion they weren't designed for).

Rendering to a depth texture is a completely different technique - there's almost no similarity between the methods at all.

In the stencil method you essentially attempt to find the silhouette of the shadow casting object and extrude the edges of the silhouette away from the lightsource. You then render this extruded silhouette into the stencil buffer incrementing the stencil value for front faces and decrementing them for the back faces (or some similar method). This allows you to determine for other objects where they pass in and out of that object's cast shadow by using the resulting stencil value as a mask and rejecting pixels based on the stencil test. This is all perfectly standard behaviour.

In the shadow buffer technique you render the scene into a texture from the POV of the light source, rendering only the depth information. When you then light the scene from that source you transform the depth value that you are currently rasterising into the same space as that stored in the texture and compare these values - if the current depth value is further away than that stored in the texture then there is obviously an object in front of this pixel from the light's POV and so the pixel is in shadow.

There is no commonality between these techniques at all, except that they are both used to generate shadows. The stencil buffer technique uses no special methods. The shadow buffer technique requires creation of a texture that uses a depth buffer format (not generally available, and not supported by the reference rasterizer). nVidia's implementation also apparently detects the format of this depth texture when it is attached to the shader, and uses a type of texture filtering not specified anywhere in D3D, as well as setting up other implicit, undocumented behaviour.

Here is a link to nVidia's white paper on the subject:

http://developer.nvidia.com/docs/IO/1830/ATT/shadow_mapping.pdf


The following call from that document :

HRESULT hr = pD3D->CheckDeviceFormat(
D3DADAPTER_DEFAULT, 	//default adapter
D3DDEVTYPE_HAL, 		//HAL device
D3DFMT_X8R8G8B8, 		//display mode
D3DUSAGE_DEPTHSTENCIL, 	//shadow map is a depth/s surface
D3DRTYPE_TEXTURE, 		//shadow map is a texture
D3DFMT_D24S8			//format of shadow map
);

Will fail on all versions of the reference rasterizer (change D3DDEVTYPE_HAL to D3DDEVTYPE_REF), and everything other than nVidia hardware.

Note also just below this paragraph:

Note that since shadow mapping in Direct3D relies on “overloadingâ€￾ the meaning of an existing texture format, the above check does not guarantee hardware shadow map support, since it’s feasible that a particular hardware / driver combo could one day exist that supports depth texture formats for another purpose. For this reason, it’s a good idea to supplement the above check with a check that the hardware is GeForce3 or greater.

nVidia themselves understand that this is not supported in the spec. In fact, I don't think they are quite clear enough here - they're not really overloading an existing texture format, they are using a depth format which is unsupported as a texture format in the API. Even in DX9 depth formats are not supported as textures to my knowledge.

Note a bit later on the pixel shader used for the actual shadow mapping -

tex t0   // normal map
tex t1   // decal texture
tex t2   // shadow map
dp3_sat r0, t0_bx2, v0_bx2  //light vector is in v0
mul r0, r0, t2   //modulate lighting contribution by shadow result
mul r0, r0, t1   //modulate lighting contribution by decal

There is no code in this shader that actually does any depth comparison to decide if something is in shadow!

This line :

tex t2

would normally just load data from the texture, but in some way it is instead loading the result of some implicit depth comparison occurring somewhere outside the shader.

It's all undefined behaviour, achieved by binding the depth texture to a certain texture stage - this doesn't remotely conform to anything in the API.

I'm sorry - I can't make this any clearer. If you still don't understand the difference in the techniques, and what makes one legal while the other isn't, then there's nothing I can do.

- Andy.

 

[BenSkywalker]

This allows you to determine for other objects where they pass in and out of that object's cast shadow by using the resulting stencil value as a mask and rejecting pixels based on the stencil test.

There is no commonality between these techniques at all, except that they are both used to generate shadows.

For the particular implementation utilized in SC there are no color values nor are there any soft shadows used which differ considerably from the particular example that nVidia has in that doc. For instance-

nVidia's implementation also apparently detects the format of this depth texture when it is attached to the shader, and uses a type of texture filtering not specified anywhere in D3D

That doesn't appear to be happening in SC, nor are there color values being utilized for the shadow maps generated which changes D3DFMT_24S8 to D3DFMT_D16.

tex t0   // normal map 
tex t1   // decal texture 
tex t2   // shadow map 
dp3_sat r0, t0_bx2, v0_bx2  //light vector is in v0 
mul r0, r0, t2   //modulate lighting contribution by shadow result 
mul r0, r0, t1   //modulate lighting contribution by decal

There is no code in this shader that actually does any depth comparison to decide if something is in shadow!

The depth comparison is done prior, although I see what you are saying in terms of it not being the same as in Stencil Buffer implementations.

In terms of what SC in particular is doing, it appears to be rather considerably simplified from what is possible using shadow buffers under D3D on nV hardware and removes some of the out of spec functionality versus the sample code. I see what you are saying now in terms of the differences, although the example you are using seems to be quite a bit beyond what is happening in SC in particular.

How does ATi support shadow buffers under OpenGL? If they have the hardware, why can't they support it under D3D? Is it the automatic compare for the depth texture v the projection?[/code]