On Monday 30 July 2007, Petter Urkedal wrote: > On 2007-07-30, Andre Pouliot wrote: > > In that case I'm going to modify the program to make the result go to > > infinity when we receive an infinite/NAN or force the output at zero when > > we receive an denormalized/zero value. So no more denormalized value. All > > case that make the pipeline behave strangely will be covered. The case > > infinite multiplied by zero will result in zero unless someone have an > > objection. > > I think I'd let Inf*0 = NaN, the argument being as follows: Ignoring the > sign, if the result of an operation on finite values is Inf, the true > value can be anything above the greatest representable, and if the > result is 0, the value can be anything below the smallest representable. > The product of the two can be *any* value including 0 and infinite.
Introducing a NaN is IMHO a bad idea, unless it significantly simplifies the logic. We don't handle NaNs as inputs, so it seems wrong to produce them as results. Remember that we're dealing with a graphics pipeline, so we shouldn't be encountering exceptional/infinite values in the first place. If we do encounter any strange values I'd say the user already screwed up and it doesn't matter what we do, as long as the chip doesn't lock up. Flush-to-zero is an extremely common FP implementation. I can think of several general purpose FP units that implement this behavior, and incur a significant performance penalty (even bouncing back to software emulation) to handle denormals and unordered values. Paul _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
