Radeon 9700: FSAA, 24-bit Z-buffer and no W-buffer

DaveBaumann said:
However, they may not have any room do expose this level of Z buffer under DX until DX9 anyway.

EXACTLY!!

Now you see why I was astonished that they removed W buffer support from the 9xxx series and did'nt take the Z buffer precision precison any further than it already is.
 
Nagorak said:
Couldn't you write early-Z algorithyms in the PS program too? Or would that just be counter-productive?

Such an approach would not be able to quickly discard large number of pixels, such as HyperZ is culling whole 8x8 blocks in a single cycle.
 
Chalnoth said:
Ante P said:
The POINT of the topic was the relationship between a (pure) 32-bit Z-buffer/W-buffer and FSAA did you all manage to miss that?

You mean as it deals with z-buffer compression? Of course more modes (particularly floating point modes) would require more transistors for compressing/decompressing the z-buffer, so it can be an issue, but doesn't need to be.

Yeah and how about W-buffer compression? (Does the 7x00 and 8x00 support compression of the W-buffer or is it restrected to Z? I'm sorry if these are inane questions, I'm still learning here hehe)
How would that effect FSAA?

Maybe it didn't work properly or performance was too bad.

BTW getting lots of "buffer fighting" in Mafia which uses the W-buffer. (shadows and decals sorta remind me of FableMark on the 8500)
Not that it's relevant ;)
Haven't bothered trying to run it with a Z-buffer yet..
Really impressed by this engine btw apart from shadows and decals flickering it looks great and runs great too
looks like crap with aniso though
 
Yeah, Mafia is a pretty cool game with a kick-ass graphics engine. The crappy 9xxx series are 100% responsible for all the artifacts you see in the game. I've run it on my 9700 Pro and GF4 Ti4600 and the decals are just fine on the nVidia board.

There is definitely some Z fighting going on with the decals. And again, it all boils down to things I have had to deal with : zbias, z precision, *busted* MT.
 
Depth precision will improve with future drivers, as far as zbuffer goes.

At current, 24-bit zbuffer displays artifacts in just about everything, just your average Joe doesn't really notice it that much. 16-bit zbuffer is totally broken, as a quick round of Half-Life, Quake3 or even most D3D games in 16-bit will quickly indicate. Decals and the like are showing through walls completely in 16 bit.

Funny thing is, this isnt much worse than the zbuffer artifacts early on with the GF4. They fixed this, although it still has a handful of zbuffer errors/artifacting left (missing trees, polys in the distance that dissappear/reappear, etc.etc.).

It just goes to show that all the newer zbuffer/occlusion technology likely has a big impact on the complexity of driver development given the bazillion different software titles out there. Adding additional depth precision comes in time, but usually has some cost in terms of performance. Seems IHV's would rather schmooze through faster benchmarks on product launch with less than perfect depth precision... and add precision later once other performance optimizations are found to help "balance out" the toll taken by fixing these issues.

That's my opinion anyways. The single most important thing to an IHV at product launch seems to be 3DMark and Quake3 scores, the second most important thing is releasing drivers to the people that rushed out and bought these cards due to those scores that do not drop them, while at the same time fixing things.
 
That's my opinion anyways. The single most important thing to an IHV at product launch seems to be 3DMark and Quake3 scores, the second most important thing is releasing drivers to the people that rushed out and bought these cards due to those scores that do not drop them, while at the same time fixing things.

Seriously.

Amongst the review community there always seems to be a desire for some more D3D benchmarks. A real D3D game, not the "synthetic" 3DMark application. To that end quite a few people have snapped up Commanche 4 and I suspect that UT2K3 will be quite popular as well.

If Derek really wanted his engine to take higher priority, he would only need to create a benchmark demo out of his commercial engine. Watch the review sites start using it as an extra tool and then watch how ATI and the like will scramble to fix the problems.
 
Derek Smart [3000AD said:
]Yeah, Mafia is a pretty cool game with a kick-ass graphics engine. The crappy 9xxx series are 100% responsible for all the artifacts you see in the game. I've run it on my 9700 Pro and GF4 Ti4600 and the decals are just fine on the nVidia board.

There is definitely some Z fighting going on with the decals. And again, it all boils down to things I have had to deal with : zbias, z precision, *busted* MT.

Hehe actually I'm playing it on a 8500 using a w-buffer. So I don't think we can hold the 9x00 series responsible here. :D

BTW the readme says that you absolutely should use "Clip Always" on ATi-cards. Anyone mind explaining..?
I didn't notice a difference at all, no performance gain/loss, no difference in stability and no impact on visuals as far as I can see.
 
Sharkfood said:
16-bit zbuffer is totally broken, as a quick round of Half-Life, Quake3 or even most D3D games in 16-bit will quickly indicate. Decals and the like are showing through walls completely in 16 bit.quote]

Doesn't forcing a 24 bit Z-buffer help?

Anyone tried toying with the old registry settings that forces a 32 bit Z-buffer in Open GL? (I think there's two different keys to force a 32 bit Z-buffer and one to force a 24 bit as well as one to force 16 bit)
Or the key that enabled the W-buffer in D3D?
 
Ante P said:
Yeah and how about W-buffer compression? (Does the 7x00 and 8x00 support compression of the W-buffer or is it restrected to Z? I'm sorry if these are inane questions, I'm still learning here hehe)
How would that effect FSAA?

Since the w-buffer does not store data linearly, I doubt the same compression techniques would work. Still, it might be possible to go ahead and store the values as w-buffer values, and then convert those to high-precision z-buffer values (such as 32-bit z or something to that effect) for decompression.
 
Ryu Connor said:
If Derek really wanted his engine to take higher priority, he would only need to create a benchmark demo out of his commercial engine. Watch the review sites start using it as an extra tool and then watch how ATI and the like will scramble to fix the problems.
I think you're on to something.... :)

Good to see you posting here, BTW, Ryu.
 
Ryu Connor said:
If Derek really wanted his engine to take higher priority, he would only need to create a benchmark demo out of his commercial engine. Watch the review sites start using it as an extra tool and then watch how ATI and the like will scramble to fix the problems.

You know, thats the second time I've heard that this month and now I'm beginning to seriously consider it.

Man, just imagine me throwing up one massive space and planetary battle, with all the fixums running. You'd need to install heat sinks on your memory cards.

Problem is, I don't have the foggiest idea how* to design/develop a benchmarking app. So, if you folks want us to start it as a project here, let me know and I'll kick up a new topic and we'll get working on it.

*What I mean is, what would I need to do differently than what I'm doing in the actual game code. If you see what I mean. I'm working on a demo for BCG, so now would be a good time to start thinking about this. This way, once the demo is out (Dec/Jan) timeframe, it can double as a benchmarking app.
 
A benchmark would be great Derek. That is a useful benchmark I might add. I hope it isn't only a FPS type benchmark but maybe a benchmark where someone can adjust parameters as in the number of polygons (could just be objects such as debri or asteroids present), maybe the texture sizes applied to surfaces, different switches to turn on different filtering schemes and anti-anliasing. Obviously a good way to analize the data would also be beneficial. Checking accuracy of the Z-buffer would also be cool as well as the bandwidth ability of AGP and internal memory. Stressing the cpu by doing more physics calculations could also be useful.

One the biggest problems with a benchmark like 3dMark2001 I see is the inability of the person testing to control the parameters and measuring the effect. Also verefying that what your card is rendering is what surpose to be rendered as in an IQ assessment (which I've havn't a clue in how that could be done). PS and VS shader performance is just another area that may be measured and will become more important as time goes on. Just some thoughts.

Been looking for some of your games and I havn't found any in my local area, I will have to order over the internet. A benchmark which no one can fool with is one that would be very valuable. Also it could be good as a tool to promote your games as well :).
 
Derek,

You raise an interesting point. Do you wish to make a pure graphics benchmark, or a Battlecruiser benchmark?

The difference being (of course :)) that the graphics benchmark doesn't neccessarily have to have much in common with the game other than the basic engine. What I miss with timedemos in quake and such is that they only re-draw stored movements, there's no actual physics or AI calculations or such as far as I can tell.

It would be cool if a game could store all variables used, including whatever random seeds used for its AI calculations etc in a timedemo file, and then have the timedemo run EXACTLY as if someone was playing the game, except substituting all variables with those pre-recorded in the timedemo so that all movements were replicated precisely.

Does any game really DO this? If not, then you could be a first here, heh heh!


*G*
 
If the Z-buffer precision is really a problem why not divide your scene rendering up over smaller Z-buffer sections, such as 0-1000, 1000 - 2000, etc.
 
That benchmark idea is a terrific one I think. And a thread on this board covering the specific features to implement would make the idea outright phenomenol...the input should be terrific.

The key to benchmarking, I think, besides stressing features for comparison, is to make it easy to know exactly WHAT features are being stressed at a given time, and to ensure that comparisons are valid and equivalent.

For example, I think part of the goal should be to offer a way to achieve equivalent output between cards in the optimal way available to each...exactly the way 3dmark 2001 does not (in the final score) between DX 8 and DX 7 cards.

The W Buffer issue and the 9700 offers an interesting dilemna ...you haven't had a chance to see where you can go from here yet. In the meantime, the difference in output and its significance should also be highlighted...i.e., remember that speed isn't the only criteria for a benchmark.

Bah, all this will come out in such a thread if you start it, and in better detail.
 
790 said:
If the Z-buffer precision is really a problem why not divide your scene rendering up over smaller Z-buffer sections, such as 0-1000, 1000 - 2000, etc.

Why not try reading ALL the posts in which I have decribed what I'm currently doing? If you do a search on my name, it shouldn't be that hard.
 
demalion said:
That benchmark idea is a terrific one I think. And a thread on this board covering the specific features to implement would make the idea outright phenomenol...the input should be terrific.

Indeed

The key to benchmarking, I think, besides stressing features for comparison, is to make it easy to know exactly WHAT features are being stressed at a given time, and to ensure that comparisons are valid and equivalent.

Noted

For example, I think part of the goal should be to offer a way to achieve equivalent output between cards in the optimal way available to each...exactly the way 3dmark 2001 does not (in the final score) between DX 8 and DX 7 cards.

That, I don't have time for. If I'm going to do this, it will be for DX8/9 only, depending on which one is currently installed on the machine.

The W Buffer issue and the 9700 offers an interesting dilemna ...you haven't had a chance to see where you can go from here yet. In the meantime, the difference in output and its significance should also be highlighted...i.e., remember that speed isn't the only criteria for a benchmark.

Well, right off the bat, the ATI 9xxx series will fail because they don't have a W buffer and I do NOT intend to use a shader to get around it. At all. For one thing, in my initial tests - everything you've heard is RUBBISH it doesn't work. On paper, it looks like it should work. But in practice it doesn't.

Nevertheless, I'm still petitioning the ATI bigwigs to consider enabling it in the display properties tab (compatiblity section) and registry, since the card still supports W buffer in hardware. There's just no way to turn it ON.


Bah, all this will come out in such a thread if you start it, and in better detail.

Indeed
 
Back
Top