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

[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?? )

 

[KimB]

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

 

[Kristof]

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-

 

[KimB]

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.

 

[KimB]

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?

 

[KimB]

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).

 

[KimB]

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]]

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? 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]]

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]

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]]

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.

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.

 

[KimB]

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]

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.