On 7/30/07, Petter Urkedal <[EMAIL PROTECTED]> wrote: > > I see I'm thinking to generally here. Dropping corner cases seems > good, but choosing between Inf and NaN, isn't NaN the more general?
A number only means what we decide it means. One operation we do is convert a float to a fixed. When we do that, numbers above a certain value all get clamped to the max fixed value. The simplest way to do that is to check the exponent first and decide if it's too big. If so, the answer is easy. If we're checking only the exponent first, then all that means is that we have decided that NaN and Inf are indistinguishable. Another way to look at it is that all values with an exponent greater than a certain value (something surprisingly small), are infinity, regardless of the mantissa value. Analogously, exponents below a certain value (certainly larger than the minimum exponent) all map to zero, although in this case, some of those smaller numbers are actually useful in intermediate computations. For coordinates, negative coordinates can be meaningful. But for colors, they're not, so all negative colors map to zero. The whole idea behind using float is to increase the _intermediate_ precision beyond what can be done with fixed. But while the model carries floats all the way through, the real hardware won't. At the earliest reasonable point, any given number will be converted to fixed because that takes vastly less logic to process. > > If we are talking about coordinates, isn't it an advantage that any > undefined operation results in NaN and causing the corresponding > triangles not be rendered, rather than potentially ending up in the > corner of the screen? Well, that was may practical consideration, but > if you say 0*Inf=0 (0*NaN=0) is good for the pipeline, I'll take your > word for it. We just don't need it to be that smart. At a much higher level of abstraction, software can check operands to make sure they make sense. So what the hardware gets is only those numbers that it can handle. You to make a good point, though. If a coordinate value is undefined, and clipping is turned off, any part of the framebuffer could get corrupted. But how much programmer error must we really account for in hardware? (As little as possible, with _none_ probably being an upper bound.) Some of this checking will happen automatically. For instance, when converting a coordinate from float to fixed, any number out of range would get converted to the max representable fixed number. Probably something like "FFFF.FF". If some kind of clipping is involved, this gets culled trivially. Also, some coordinates are fixed from the beginning. For instance, screen coordinates on the destination surface will be written to the engine as fixed point numbers from the start. This is because float is never usedful for them. On the other hand, texture coordinates need to be floats. But since textures are never written, only read, then the worst that can happen is that garbage appears in the texture. (Note that you can write to a texture. You just have to treat that area of memory as a drawing surface, not a texture.) -- Timothy Normand Miller http://www.cse.ohio-state.edu/~millerti Open Graphics Project _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
