On Wednesday 09 February 2005 07:55, Lourens Veen wrote: > Ah. I think I'm starting to see your point about 13 bits not being > enough.
I failed to mention a especially easy way to amplify the error: repeating textures. Say you're viewing a long hall with repeating textures on the wall. Small errors at the far end of the hall will amplify into multi-texel errors at the near end. Masking doesn't work because the math is nonlinear. The easiest fix is to have some precision in reserve and otherwise ignore the problem. What would have to be done to cure the repeating texture problem definitively? I've never attempted this myself, but some compare and recalculate strategy should work: for each texture interpolant T estimate the number of perspective interpolation steps until T exceeds acceptable range. This estimate doesn't have to be very accurate. After that many steps, stop everything, recalculate the interpolation parameters from the initial T, estimate a new limit and resume. This is wretchedly ugly and complex, maybe somebody knows a better alternative. The pragmatic approach is to just ignore this for the first release. > I am fairly sure I can make that full interpolation (which presently > does 15 bits) into full 16 bit precision by storing 17- or 18-bit > values instead of 16-bit ones. I vote for 18 bits, which would guarantee 17 bit precision. The 17th bit would only live for a short while, being fed immediately into the perspective correction multipliers. To me, every bit of extra precision is gold, so if it's easy to get, get it. > The only problem is that we'd need a > quad-gated RAM block to do two pixels at a time. Or two RAM blocks... OK, here goes my limited understanding of how this RAM works: it's dual-ported, so each pixel can pick up the start sample on one clock and the following sample on the next clock, which is perfectly ok because latency isn't a problem for the texture divide. Alternatively, twice as much RAM can be used, encoding an 18 bit sample and an 18 bit difference in each 36 bit word, and look them up together. Can a 36 bit lookup be dual ported without losing a multiplier? The earlier discussion left me confused on this point, and wandering through the chip spec hasn't helped. I think the simplest arrangement is just to compute the difference on the fly, taking two clocks for the interpolation. Interpolating the last sample in the table needs a bit of extra logic to handle the table wrap. Interpolating the zeroth sample needs something special to handle the missing most significant bit for the sample of exactly 1. The nice thing about all of this is, the divides seems to be under control. That's what I worried about most when I first heard of this project. 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)
