[Ante P]

All this talk about the loss of the 32 bit Z-buffer and the W-buffer got me thinking. (And please don't laugh at me since I'm not a techie guy so this might be very silly hehe.)

The Radeon 9700 samples the Z-buffer when using FSAA.
Maybe there's some problem with sampling/compressing the W-buffer when using FSAA?
The same might apply to a 32-bit Z-buffer, or maybe the reason is performance?

As for a "pure" 32-bit Z-buffer: I saw that someone stated that no consumer card has support for it but that's crap. The Radeon 7x00 and 8x00 has support for a 32 bit Z-buffer as well as a "24+8" bit Z-buffer.

Also what bitdepth does a W-buffer have? I think I recall some Nv-Tweaker having options for 16, 24 AND 32? (I have no idea if a stencil buffer is viable when using a W-buffer though.)

Share your thoughts.

(BTW if it's a simple matter of FSAA not working properly/at all when using a W-buffer it sure seems strange since ATi apparently thinks that it's worthless to use FSAA in 16 bpp modes, so why care about the few games that use a W-buffer?? )

[Chalnoth]

Support for a 32-bit z-buffer is pointless unless at least 8 bits of alpha are also available.

[Kristof]

Originally Posted by Chalnoth

Support for a 32-bit z-buffer is pointless unless at least 8 bits of alpha are also available.

Do you mean "stencil" rather than "alpha" since I don't really see the link between Depth Accuracy and spread and alpha values 8)

K-

[Chalnoth]

Yes, I meant stencil, sorry.

[Ante P]

Hehe pointless post.
The thread didn't have (shouldn't have) anything to do with the "point" of a 32-bit Z-buffer.

[Chalnoth]

I don't think you're understanding me correctly. Regardless of hardware support for a 32-bit z-buffer, that support is essentially useless unless a stencil buffer is also available.

As a side note, with the NV30's packed floating point pixel format, it should be possible to allocate 128 bits per pixel however the programmer chooses. There's already been note of the possibility of doing a w-buffer in the shaders, but the only obstacle to a 32-bit z-buffer is the absolute accuracy of the z calculations, though there would likely be a substantial performance hit, as you would, presumably, need to read in the 128-bit final scene for the final output.

Here's an example of a way that a programmer might be able to use the 128-bit pbuffer: 64-bit floating point RGBA, 32-bit z-buffer, 8-bit stencil, and 24-bits either unused, or put to some other purpose. If I scanned the CineFX specs properly, then this should definitely be possible.

[Luminescent]

This 128-bit flexible allocation is only possible on nv-30?

[Chalnoth]

I believe so, but I'm not certain.

[Dave Baumann]

FYI - floating point Z-Buffers could be supported by R300. If they do turn up then it will be in the FireGL boards.

[Basic]

Doing Z yourself in PS would kill all early z-stuff. So you realy want to avoid it as much as possible.

R300 doesn't pack different types into one 128 bit buffer, but can save pretty much the same data into separate buffers. With the addition that it can store up to 512 bit data per pixel (four buffers with 4x(24+8) bits).

[Chalnoth]

Oh, that's right, Basic, I hadn't thought of that.

On the other hand, if the hardware supports 32-bit z and no stencil, perhaps a packed format could be used to put the stencil back in, while retaining the efficiency of the early-z stuff?

[Nagorak]

Couldn't you write early-Z algorithyms in the PS program too? Or would that just be counter-productive?

[Ante P]

Did anyone even read the topic?
It has little or nothing to do with a 32/24+8 Z-buffer per se.

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?

[Derek Smart [3000AD]]

Originally Posted by Chalnoth

Oh, that's right, Basic, I hadn't thought of that.

On the other hand, if the hardware supports 32-bit z and no stencil, perhaps a packed format could be used to put the stencil back in, while retaining the efficiency of the early-z stuff?

Not really, because you'd still have to write it back out. And arrive at the same point (precision loss) you'd get with a 24 bit Z + 8 bit stencil. I hope I did'nt misunderstand the question.

I asked ATI to remove those settings from their control panel (heh, and they actually did) because of this kind of confusion. At one point in the driver life, you could specify if you wanted a 16 or 24 bit Z + 8 bit stencil among other settings. It was causing a lot of problems and users were pissing around with it and causing all manner of problems. As if the drivers been bad wasn't bad enough.

Just do a search for Radeon in this FAQ and you'll see what I mean.

[Basic]

I think Chalnoth proposed that if you had hardware with a real 32 bit z-buffer with working early z, and wanted to add a 8 bit stencil buffer, then you wouldn't need to go down to 24+8 bit z+stencil. You could keep the 32 bit z-buffer as usual, still have working early z. The stencil operations could be done in the PS, and the stencil buffer is stored in a separate buffer. The hardware wouldn't know that it's a stencil buffer, you'd do everything yourself and a "stencil" test would include a 'KILL'-instruction.

There's of course no chance to have an "early stencil" check (I don't know if that's available in any hardware though), and the stencil operations will cost you PS cycles.


Ante P:
Who cares about the topic? :P Since when did the topic say anything about the discussion in the thread?

Just kidding.
Let's see if I remember this right. A Z-buffer doesn't store real Z, but a value that can be interpolated linearely in screen space. This makes the hardware simpler, and it certainly makes it easier to implement some z-buffer compression. Adding the possibility for a W-buffer means more hardware.

(Was that enough on topic to avoid your wrath?)

[Derek Smart [3000AD]]

Originally Posted by Basic

I think Chalnoth proposed that if you had hardware with a real 32 bit z-buffer with working early z, and wanted to add a 8 bit stencil buffer, then you wouldn't need to go down to 24+8 bit z+stencil. You could keep the 32 bit z-buffer as usual, still have working early z. The stencil operations could be done in the PS, and the stencil buffer is stored in a separate buffer. The hardware wouldn't know that it's a stencil buffer, you'd do everything yourself and a "stencil" test would include a 'KILL'-instruction.

There's of course no chance to have an "early stencil" check (I don't know if that's available in any hardware though), and the stencil operations will cost you PS cycles.

I quite agree and thats why I was expecting that they'd gone and implemented a true 32bit Z buffer (as I mentioned here), having removed the W buffer support entirely. I could'a sworn that I saw mention of a 32 Bit Z buffer support somewhere during the 9xxx series hyping. Maybe they just either disabled or removed it, at the last minute. One will never know I suppose.

[Reverend]

Originally Posted by DaveBaumann

FYI - floating point Z-Buffers could be supported by R300. If they do turn up then it will be in the FireGL boards.

Did you ask ATI why this is so (i.e. could be supported on a R300 but even if such is the case, why only in FireGL?)? What, useless feature for game developers? I don't think so.

[Derek Smart [3000AD]]

Originally Posted by Reverend

Did you ask ATI why this is so (i.e. could be supported on a R300 but even if such is the case, why only in FireGL?)? What, useless feature for game developers? I don't think so.

I did ask ATI this question in the past (and I have the original email and the reply from dev relations) but they simply told me that it wasn't the direction they were going in. Yes, I found that odd, even for the cards/drivers that were out at the time.

I suspect that not supporting floating point Z is another one of those cases where they don't want to jeapardize the speed of the card/driver - similar to that lame excuse about removing W buffer support.

I dunno, but I still see NO reason why they removed W buffer support. I simply don't get it. They're more concerned about speed than the quality of the drivers and games that run the drivers. This much started being obvious back when they blatantly hacked their drivers in order to improve benchmark scores on QuakeIII. Pitiful.

[Chalnoth]

Originally Posted by Ante P

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.

[Dave Baumann]

Originally Posted by Reverend

Did you ask ATI why this is so (i.e. could be supported on a R300 but even if such is the case, why only in FireGL?)? What, useless feature for game developers? I don't think so.

No, I didn't actually. If it is FGL only then it will likey be due to reasons of speed. However, they may not have any room do expose this level of Z buffer under DX until DX9 anyway.

[Derek Smart [3000AD]]

Originally Posted by DaveBaumann

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.

[Humus]

Originally Posted by Nagorak

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.

[Ante P]

Originally Posted by Chalnoth

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

[Derek Smart [3000AD]]

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.

[Dave]

I'd say blame MS, to a large extent on W-buffer removal. They suggested it.