3dMark2001SE - Nature test with AA

[Randell]

Is the Nature test typical or atypical for how VS and PS coded games should run on >=DX8 hardware?

I ask this because it appeasr to me to be oen of the biggest tests for AA on modern hardware, taking hefty hits on Gf3/8500/R300 and NV30. i.e to the levels of unplayability.

 

[Dave Baumann]

I don't think anything is typical or atypical of PS/VS titles out there at the moment, there's insufficient titles that utilise them to say either way.

The Nature test in particular though uses lots of alpha textures, so quite a lot of performance is taken up with the alpha blending, AFAIK.

 

[Tagrineth]

Is the Nature test typical or atypical for how VS and PS coded games should run on >=DX8 hardware?

I ask this because it appeasr to me to be oen of the biggest tests for AA on modern hardware, taking hefty hits on Gf3/8500/R300 and NV30. i.e to the levels of unplayability.

You find that the Nature test becomes unplayable huh?

 

[Randell]

oh ha

You know what I mean. Out of the 7 'game' tests it is the least CPU limited and most GPU dependant test but after almost 2 years, AA results are still pretty low comapred to raw results, which if translated in to a real game engines performance woudl mean use of AA for games using that engine would be untenable.

Now if it i spurely down to lots of alpha-blended textures (leaves and grass I take it) and not the minor PS water effects, then would we expect a true DX8+ engined game to perform similarly? (excluding effects of AI/physics which woudl tend to CPU limit any game anyway).

 

[PSarge]

Dave's right. Nature isn't a VS or PS test (yes it has them, but not in enough quantity to matter), it's a "how long does it take to draw 1000's of alpha tested leaves?" test.

The thing with alpha-testing is that it often renders things like hierarchical Z rejection impotent, so it takes a heavier hit on fill-rate.

 

[Randell]

Thats OK then, interesting that a game that does use lots of alpha blending (say UT2003 Antalus) doesn't show anywhere near the similar AA hit in Flyby mode as the alpha thats are used are only a samllish part of what is rendered.

 

[PSarge]

Thats OK then, interesting that a game that does use lots of alpha blending (say UT2003 Antalus) doesn't show anywhere near the similar AA hit in Flyby mode as the alpha thats are used are only a samllish part of what is rendered.

Alpha-blending, and alpha-testing are slightly different things. With Alpha-blending the z-buffer is still updated even if a fragment is transparent. With Alpha-testing the fragment is killed from progressing further down the pipeline than the texture stage, so the depth buffer isn't updated.

This is why alpha-test screws up early z-rejects, because it's impossible for the hardware before the texture stage to know if the z-buffer should be updated. That's only known once the texture fetch has been done.

Edit: Poor sentence structure.

 

[Randell]

ooh OK, I didnt understand the difference. So youwouldnt expect any 'game' coders to use alpha testing as heavily as Nature does?

 

[PSarge]

ooh OK, I didnt understand the difference. So youwouldnt expect any 'game' coders to use alpha testing as heavily as Nature does?

Actually...I'd expect 'game' coders to do it, and not to understand why their performance sux, and all the while the IHV devrel guys are crying into their hands.

...but to answer your question, I wouldn't want them to do it, nor would I suggest it to anyone. Richard Huddy's presentations that he gives to developers are good sources for this sort of stuff. I lot of the things he highlights are problems he's seen in actual games and applications. (Although he doesn't mention this one)

http://www.ati.com/developer/Mojo_RH_Optimization.pdf

 

[arjan de lumens]

The main use of alpha test seems to be to fake complex geometry, particularly for plants. So I would expect it to continue to be used until mainstream gpus are capable of doing the real geometry at a reasonable rate. Even though it screws up early Z-test, Z compression and produces lots of edges that are difficult to antialias properly.

 

[Kristof]

Actually...I'd expect 'game' coders to do it, and not to understand why their performance sux, and all the while the IHV devrel guys are crying into their hands.

No kidding, this one scores high on the PVR Developer Support list as well, all too often we see games that leave Alpha Test enabled for all geometry... sigh !

 

[Bambers]

Nature is alpha blending not alpha testing...

 

[Hyp-X]

Alpha-blending, and alpha-testing are slightly different things.

Different: yes
Exclusive: no

With Alpha-blending the z-buffer is still updated even if a fragment is transparent.

Not necessarily, or I should say no.
Develepers tend to use alpha-testing along with alpha-blending to discard the fully transparent fragments.
And this is a performance optimization.
Nature does that, you can see it from the typical artifacts of unsorted alpha-blending.

Actually if you sort by depth (back-to-front) you can disable z-writes completely.

With Alpha-testing the fragment is killed from progressing further down the pipeline than the texture stage, so the depth buffer isn't updated.

True.

This is why alpha-test screws up early z-rejects, because it's impossible for the hardware before the texture stage to know if the z-buffer should be updated. That's only known once the texture fetch has been done.

Why would it screw up the reject?
It can still reject pixels.
Only some of the non-rejected pixels might turn out not appearing on the screen at the end.

The only difference is that with alpha-test it can't do early-Z update (I'm not sure if any card does that in the first place...)

 

[PSarge]

Develepers tend to use alpha-testing along with alpha-blending to discard the fully transparent fragments.
And this is a performance optimization.

It only buys you one memory write, the one that would have put the fragment in the framebuffer. All of the texture reads, shader ops, etc have still happened because the fragment flows all the way to the end of the pipeline. As optimiziations go, it's not a big win, but it's better than nothing.

This is why alpha-test screws up early z-rejects, because it's impossible for the hardware before the texture stage to know if the z-buffer should be updated. That's only known once the texture fetch has been done.

Why would it screw up the reject?
It can still reject pixels.
Only some of the non-rejected pixels might turn out not appearing on the screen at the end.

The only difference is that with alpha-test it can't do early-Z update (I'm not sure if any card does that in the first place...)

Agreed, if it has a Z-buffer to reject against, it can still reject. There's 3 ways of doing this (that I'm aware of):

1) If the mode is such that it's definate that a fragment won't be killed by a texture op (e.g. alpha test) some chips re-arrange the pipeline so that the z-test is done before the texture ops (i.e. depth-texture). In this case just enabling a feature like alpha-test is a performance loss, as the pipeline must be switch back to texture-depth order.

2) Some chips haves two depth tests, one pre texture, and one post. The one post also does the depth update. The pre-texture depth test can use the same depth buffer, but it's always looking at a buffer thats slightly out of date (there are some fragments still in the pipeline between the two depth units), therefore it's not quite as efficent as it could be (difference is probably small though). Also means you're doing twice as many z-reads.

3) Some other chips keep a second (less accurate, maybe reduced resolution to keep bandwidth down) depth buffer pre-texture (i.e. still two depth tests, but with their own buffers). The pre-texture buffer can not be guarenteed to be correct if alpha testing is enabled. This means it must be switched off and you get a performance loss.

4) and then (as I understand it) PVR does all of it occlusion calculation based on plane equations, and I sure having a hole in your plane can screw that up royally.

btw: I was pretty sure nature was using alpha-test (alpha-blending or not), but my word is not gospel on the subject.

 

[Nick[FM]]

GT4 (Nature) uses both Alpha Blending and Alpha Testing.

 

[PSarge]

]GT4 (Nature) uses both Alpha Blending and Alpha Testing.

His word probably is gospel on the subject

 

[Nick[FM]]

]GT4 (Nature) uses both Alpha Blending and Alpha Testing.

His word probably is gospel on the subject

Well, I went over and asked our coders and they said that simply put it, it (Nature) uses both.

edit:

The technical details of GT4:

The leaf and grass movement is done using a vertex shader.
The fisherman animation uses morphing done with a vertex shader.
The butterfly flight and wing movements is done with a vertex shader.
The lake surface uses a pixel shader for per-pixel reflection and cube mapping
(it uses 4 texture render states, which corresponds to 4 texture layers)
The small river has two separate water surfaces, both using two texture layers (color map and light map).
The landscape, the house and the bridge has two texture layers (color map and light map).
The leaves, grass and the fisherman have a single texture layer.

High detail statistics:

Rendered triangles per frame (min/avg/max): 55601/81722.5/180938
Rendered textures per frame with 16 bit textures (min/avg/max): 14.9/17.4/20.7 MB
Rendered textures per frame with 32 bit textures (min/avg/max): 28.4/33.4/40.0 MB
Rendered textures per frame with texture compression (min/avg/max): 10.4/12.0/14.6 MB
Rendered textures per frame with DXT1 compressed textures and 32 bit transparent textures (min/avg/max): 13.0/15.0/17.8 MB

 

[Hyp-X]

Develepers tend to use alpha-testing along with alpha-blending to discard the fully transparent fragments.
And this is a performance optimization.

It only buys you one memory write, the one that would have put the fragment in the framebuffer. All of the texture reads, shader ops, etc have still happened because the fragment flows all the way to the end of the pipeline. As optimiziations go, it's not a big win, but it's better than nothing.

No, it buys you a memory read and a write. (Remember I talked about test with blend - the thing Nature does too.)
The read and the write alone can saturate a 128bit DDR bus on 4 pipe card (this even more so with R300/NV30 as they have 8 pipes).
With testing enabled you might get up to being fillrate limited - a big win indeed.

Actually on GF3 nVidia implemented a shader trick in their drivers to use alpha-test to discard black pixels when blending is set to addition.
Addition is used a lot for lighting / flare / glow effects.
I guess they wouldn't do that if it caused slowdown, would they?