Hugh Fisher wrote: > André Pouliot wrote: > >> If we want to save resource we could expect all value to be normalized >> even number that should be unnormalized. We could also expect when the >> exponent is zero the value to always be zero it would diminish the >> dynamic range but simplify a lot of the code and make corner case easier >> to handle. Or we could stick to the spec of IEEE and augment the logic >> to do so, it would take at least 1 or 2 more stage and at least 280 more >> LUT(big mux for selecting the value to output as mantissa, doing the >> same function in asic it would be a barrel shifter, custom made it would >> be rather small and fast). > > Remember that this is an FPU to implement a 2D/3D pipeline, > not a full maths coprocessor. Just throw away all the > complex edge cases in IEEE floating point and adopt the > following rules: all little numbers == 0, all really big > numbers == infinity. > > Graphic programmers want speed, speed, and more speed, and > we *don't* want the graphics card grinding to a halt and > reporting exceptions. (Those programmers who do have a need > for precise calculations will use double precision on the > CPU anyway.) > Supporting for the corner case would not affect performance for speed, only more stage and more logic. The pipeline would still be full and running. The exceptions actually are not reported so there isn't any halt.
The logic already handle correctly when the operation go over infinite and clearly under zero, it's more the case near zero, multiply an unnormalized and normalized, multiply by zero and multiply by infinity that are not well supported. Multiply by zero and infinity will be resolved for the next version. To remove the support for unnormalized number for the small value in the beginning of the pipeline could affect the result 20 operations later and produce artifact in the image. It would surprise me if it happen, but I don't know if it's something we need to take into account or just don't care. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
