On Tuesday 01 February 2005 13:08, Nicolai Haehnle wrote: > On Tuesday 01 February 2005 18:19, Daniel Phillips wrote: > > On Tuesday 01 February 2005 11:54, Timothy Miller wrote: > > > I've decided that I'm going to add the Z into the rasterizer. > > > > I hope it's only a temporary decision. The payoff for working out > > all the little problems with using W instead of Z is pretty big. > > If there's an extra interpolant in the pipeline I'd far rather see > > it used for, say, color or alpha than Z. > > Why is this payoff so big, anyway? > > Note that an additional "normal" (i.e. color or texture) interpolant > would be a lot more expensive than Z.
About the same cost, actually. I guess the point is: interpolate one of 1/Z or 1/W, not both. The cost of additional interpolants impacts the whole system. On the driver side it imposes a scaling factor on CPU usage and memory bandwidth, roughly linear with the number of interpolants (plus some fixed overhead). For example, extra interpolants also have to be clipped. On the hardware side, each additional interpolant eats two multipliers (because it's a two pixel pipeline), and that is without any filtering. There are only 40 multipliers available I think, so they get used up quickly. In simple terms, adding a Z interpolant means something else on the card has to be dropped. > > Have you thought about what to do when the number of interpolants > > required for a particular render state exceeds the number that can > > be practically hard coded? > > > > > The only thing that isn't clear to me is whether I need to store > > > Z (world) or Z/W (screen coordiates) in the depth buffer. > > > > Normalized device coordinates I think. > > Well, window coordinates. But these only differ from normalized > device coordinates (Ndc) by a bias. > > By the way, this bias is also one of the things that the user can > control - especially look at glDepthRange, which is one more problem > factor that we would have to deal with if we wanted to escape the > need for the OpenGL Z. Compare section 2.11 Coordinate Transformation > of the OpenGL spec. Yes, I'd anticipated that, clearly any divergence between what the card implements and what OpenGL mandates has to be compensated for in the driver. It's my impression that most if not all 3D hardware out there does such remappings at least on some level, and that OpenGL was designed to facilitate it. > > > Therein lies a problem. Since the reciprocal isn't precise (we > > > use only 10 mantissa bits when computing it) > > > > Hmm, I thought we had 18 bits of precision readily available. Is > > this a consequence of using linear interpolation for the divide? > > I was also under the impression that 10 mantissa bits were used for > the LUT, and the other bits were used for linear interpolation > between two 18 bit values from the LUT. This should actually yield a > pretty good result, I think Nicolas Caspens was the one who > contributed most of this in the original discussion (obviously, I may > be mistaken, so please don't kill me if I got the attribution wrong). > In any case, with linear interpolation the precision should be *much* > better than 10 bits. Anyway, if interpolation doesn't work out for some reason there's always Newton-Raphson, which is tried and true. I seem to recall that Newton-Raphson needs two multipliers for the single iteration step required, so if linear interpolation can do the job with one then I guess it's better. Regards, Daniel _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
