On Thursday 03 March 2005 16:55, Lourens Veen wrote: > On Thursday 03 March 2005 22:22, Daniel Phillips wrote: > > It works as long as there aren't too many bits of mantissa. In > > particular, it works for 6 bits (but not 9). You'll see in my code > > that this condition is handled explicitly (look for the !!). > > Erm, I'm not sure I follow you here. If the mantissa is 0, then it > should remain 0 (because of the perfect-powers-of-two rule) and the > exponent should be corrected. What am I missing? And Nicolai's fix > does the same as your !! doesn't it?
Yes, that was my point, sorry for not being clearer. > > Explicitly accounting the exponent bias in this code does not make > > sense. In hardware, there is no reason to have a bias. The bias > > is only there so that packed fp numbers sort properly. The only > > place where we _might_ pack fp numbers is in the depth buffer. In > > hardware, the exponent should be a signed 8 bit number. > > Ah, good point. I hadn't thought about the exponent yet to be honest. > I figured the mantissa was the hard part and the exponent would be > trivial. Any ideas about NaNs and infinities and denormals? We have to detect denormals and negative exponent out of range (the same test) and set the number to zero. Which reminds me, zero is a special case that the reciprocal needs to handle. What should happen? I think the GPU should stop. On the other hand, that might prevent some buggy programs from running, that run on other graphics cards. Tough one. Here is a nano-fact (I think): if the exponent has an even number of possible values, then reciprocal overflow cannot occur on any input other than zero and the smallest possible non-zero value. If we let the smallest possible value represent zero (not how ieee does it) then zero is the only input to the reciprocal that can overflow. If we are not going to trap overflow in any special way, then a perfectly reasonable thing to do is let the inverse of zero be zero. It might be that this "just happens" in the current implementation, then we could say that overflow is handled, however crudely. We really ought to detect NANs, infinities and exponent out of range, and halt processing with an error flag. Again, this might prevent some buggy programs from running. An alternative is just to set the number to zero and keep going. Another alternative is to not do anything and just let things act strangely, so long as nothing locks. > > It would be nice to clean things up so it works in the range [1, > > 2). > > It doesn't? I didn't mean it fails to work, I meant that the table lookup should be defined over the range [1, 2). But I don't know that it isn't, because I haven't looked at the latest version, so possibly disregard that comment ;-) (Was that sentence a quadruple negative?) 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)
