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

Discussion in 'Architecture and Products' started by Ante P, Sep 14, 2002.

  1. Ante P

    Veteran

    Joined:
    Mar 24, 2002
    Messages:
    1,448
    Likes Received:
    0
    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?? :roll: )
     
  2. KimB

    Legend

    Joined:
    May 28, 2002
    Messages:
    12,928
    Likes Received:
    230
    Location:
    Seattle, WA
    Support for a 32-bit z-buffer is pointless unless at least 8 bits of alpha are also available.
     
  3. Kristof

    Regular Alpha

    Joined:
    Jan 30, 2002
    Messages:
    733
    Likes Received:
    1
    Location:
    Abbots Langley
    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-
     
  4. KimB

    Legend

    Joined:
    May 28, 2002
    Messages:
    12,928
    Likes Received:
    230
    Location:
    Seattle, WA
    Yes, I meant stencil, sorry.
     
  5. Ante P

    Veteran

    Joined:
    Mar 24, 2002
    Messages:
    1,448
    Likes Received:
    0
    Hehe pointless post.
    The thread didn't have (shouldn't have) anything to do with the "point" of a 32-bit Z-buffer.
     
  6. KimB

    Legend

    Joined:
    May 28, 2002
    Messages:
    12,928
    Likes Received:
    230
    Location:
    Seattle, WA
    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.
     
  7. Luminescent

    Veteran

    Joined:
    Aug 4, 2002
    Messages:
    1,036
    Likes Received:
    0
    Location:
    Miami, Fl
    This 128-bit flexible allocation is only possible on nv-30?
     
  8. KimB

    Legend

    Joined:
    May 28, 2002
    Messages:
    12,928
    Likes Received:
    230
    Location:
    Seattle, WA
    I believe so, but I'm not certain.
     
  9. Dave Baumann

    Dave Baumann Gamerscore Wh...
    Moderator Legend

    Joined:
    Jan 29, 2002
    Messages:
    14,090
    Likes Received:
    694
    Location:
    O Canada!
    FYI - floating point Z-Buffers could be supported by R300. If they do turn up then it will be in the FireGL boards.
     
  10. Basic

    Regular

    Joined:
    Feb 8, 2002
    Messages:
    846
    Likes Received:
    13
    Location:
    Linköping, Sweden
    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).
     
  11. KimB

    Legend

    Joined:
    May 28, 2002
    Messages:
    12,928
    Likes Received:
    230
    Location:
    Seattle, WA
    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?
     
  12. Nagorak

    Regular

    Joined:
    Jun 20, 2002
    Messages:
    854
    Likes Received:
    0
    Couldn't you write early-Z algorithyms in the PS program too? Or would that just be counter-productive?
     
  13. Ante P

    Veteran

    Joined:
    Mar 24, 2002
    Messages:
    1,448
    Likes Received:
    0
    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?
     
  14. Derek Smart [3000AD]

    Regular

    Joined:
    Sep 11, 2002
    Messages:
    271
    Likes Received:
    0
    Location:
    Weston, FL
    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.
     
  15. Basic

    Regular

    Joined:
    Feb 8, 2002
    Messages:
    846
    Likes Received:
    13
    Location:
    Linköping, Sweden
    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? :D

    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?)
     
  16. Derek Smart [3000AD]

    Regular

    Joined:
    Sep 11, 2002
    Messages:
    271
    Likes Received:
    0
    Location:
    Weston, FL
    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.
     
  17. Reverend

    Banned

    Joined:
    Jan 31, 2002
    Messages:
    3,266
    Likes Received:
    24
    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.
     
  18. Derek Smart [3000AD]

    Regular

    Joined:
    Sep 11, 2002
    Messages:
    271
    Likes Received:
    0
    Location:
    Weston, FL
    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. :roll:

    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.
     
  19. KimB

    Legend

    Joined:
    May 28, 2002
    Messages:
    12,928
    Likes Received:
    230
    Location:
    Seattle, WA
    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.
     
  20. Dave Baumann

    Dave Baumann Gamerscore Wh...
    Moderator Legend

    Joined:
    Jan 29, 2002
    Messages:
    14,090
    Likes Received:
    694
    Location:
    O Canada!
    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.
     
Loading...

Share This Page

  • About Us

    Beyond3D has been around for over a decade and prides itself on being the best place on the web for in-depth, technically-driven discussion and analysis of 3D graphics hardware. If you love pixels and transistors, you've come to the right place!

    Beyond3D is proudly published by GPU Tools Ltd.
Loading...