32Bits Z-buffer
- Thread starter Ozo
- Start date
The October 2005 DirectX SDK came with a listing of hardware and their respective capabilities shake-down. Comes as an excel/jpeg/pdf file and is abso-bloody-lutely huge 
According to said listing, only the following 5 support a 32bit (or 32bit lockable) depth stencil format:
• Permedia 3
• Matrox G450
• SIS 315
• SIS Xabre
• Volari Family
Which is odd, because I thought at least some of the NV chipsets did. Could be a driver thing I suppose.
Jack
EDIT: Just realised my list is the same as the one above. Should've checked my list first I guess... My bad! Can we delete posts on this forum?
According to said listing, only the following 5 support a 32bit (or 32bit lockable) depth stencil format:
• Permedia 3
• Matrox G450
• SIS 315
• SIS Xabre
• Volari Family
Which is odd, because I thought at least some of the NV chipsets did. Could be a driver thing I suppose.
Jack
EDIT: Just realised my list is the same as the one above. Should've checked my list first I guess... My bad! Can we delete posts on this forum?
Ozo said:
The thing is that Z has a range of [0, 1].
Z is computed in the vertex shader.
The vertex shader uses FP32.
FP32 will give you a precision of 24 bits at best (given how Z is usually calculated).
So to make actual use of 32 bit Z we'd need a higher precision vertex shader.
Mate Kovacs
Newcomer
What he meant by whether an interval uses a bit or not, is whether the bit will change while iterating along the interval or not, IMHO.
Last edited by a moderator:
The [0-1] range might be able to utilize roughly 30 bits worth of a 32 bit float, but they are not distributed in a manner that is that useful for an integer Z buffer.
An 32 bit integer depth buffer can represent 2^31 values [1.0-0.5), but a 32 bit float can only represent 2^23 (24?) values in this range. Similar breakdowns happen in other sub-ranges like [0.5-0.25), because of the nature of floating point numbers. The 32 bit float does have fantastic precision between (2^-31, 0.0], but that is of no use to the depth buffer. Most importantly, the way the perspective projection works, most depth values are greater than 0.5.
I probably got some of th math wrong above, but it is essentially correct. The general moral is that floats do a relatively poor job of representing much more that 24 bits of integer depth information.
Please note that there are alternatives to the integer Z buffer, but most applications (and depth optimizations) these days are designed toward this type of buffer, because it has been the standard for a long time, and it works pretty well.
-Evan
An 32 bit integer depth buffer can represent 2^31 values [1.0-0.5), but a 32 bit float can only represent 2^23 (24?) values in this range. Similar breakdowns happen in other sub-ranges like [0.5-0.25), because of the nature of floating point numbers. The 32 bit float does have fantastic precision between (2^-31, 0.0], but that is of no use to the depth buffer. Most importantly, the way the perspective projection works, most depth values are greater than 0.5.
I probably got some of th math wrong above, but it is essentially correct. The general moral is that floats do a relatively poor job of representing much more that 24 bits of integer depth information.
Please note that there are alternatives to the integer Z buffer, but most applications (and depth optimizations) these days are designed toward this type of buffer, because it has been the standard for a long time, and it works pretty well.
-Evan
Mate Kovacs
Newcomer
[smartass]ehart said:
Please don't mix up things (neither the ordering of the numbers nor the brackets indicating open- or closedness) in a notation of an interval, in order to avoid confusion. That's why darkblu misread Nick's post, IMO.
For example the exponent of a float is fixed along intervals of the form [2^n;2^(n+1)), but along (0.5,1.0] it's not.
[/smartass]
Maybe my memory is totally wrong, but isn't there a performance penalty if the z values of a triangles vertices are too far apart? So you're best of not using 32 bit z...nAo said:
Or you could just store the fp value in the buffer instead of converting to integer?Hyp-X said:
I think CLX2 had a Z accuracy of about 28 bits (floating point), but don't quote me.Lazy8s said:
Hyp-X said:
I have researched this quite extensively. Used properly an N-bit floating point Z buffer gives you a much better distribution of accuracy than an N-bit fixed point Z.
[Gratuitous Name Drop Time] Incidentally, when I mentioned to Jim Blinn that he had this wrong in one of his "Jim Blinn's Corner" articles ("W Pleasure, W Fun"), he said that he'd added a footnote to the article when printed in his book, "Notation Notation Notation" which uses the correct method [/Gratuitous Name Drop Time]
Last edited by a moderator:
Yes, using a FP32 W buffer makes sense, and the Vertex Shaders definately has enough precision is that.
Also what I meant is that Z is computed with a (z-N)/z like equation which result an approximate 24bit precision in the whole [0, 1] range. This is because how the FP subtraction behaves.
Also what I meant is that Z is computed with a (z-N)/z like equation which result an approximate 24bit precision in the whole [0, 1] range. This is because how the FP subtraction behaves.
Need to remember you can get higher precision in the output pixels than the vertices because the pixels use interpolated values from the vertices.
Similar threads
