[rescue] looking for SGI system, cheap

[Joshua Boyd]

On Fri, Jan 27, 2006 at 02:54:01PM -0600, Matthew Weigel wrote:

> > While 3D rendering may be
> > floating point heavy, quite a lot of 2D image processing was mostly
> > integer work.
> 
> Not in my experience - colors are expressed in floating point, and 
> operations that change colors are necessarily fp.  There's a lot of 
> pixel addressing, but even that involved taking a fp calculation and 
> figuring out which integer pixel best corresponded to the value.

In my experience, colors are typically expressed as 8bit or 16bit values
under most circumstances.  For some tasks, one may convert them to
floating point and then back, but they are still integer values.

For instance, if you are fading between two images, there is no reason
to convert to floating point to work on it.  Image interpolation (for
any sort of affine transform) is also traditionally done with integer
math.  In Mplayer, there is at least one example of an integer color
space conversion routine.  Even MS gives you an integer color space
conversion routine on their website.  Gama correction is typically
achieved mostly with integers (via a LUT.  I personally calculate the
LUT with FP math). 

Now all this integer math isn't always fastest.  For a MIPS R10,000 CPU,
the fastest approach is likely to split the work so that both pipelines
can be kept busy rather than using only one or the other.  On P3 and
newer CPUs, splitting the work to fill both pipelines is also probably
fastest, unless you choose to use SSE instead.  Then I don't know which
method will be faster.  I might guess that for 16bit image data that
integers would still be faster since you can process 8 pixels at a time
instead of 4, but I haven't tried timing this at all.

For designers of custom hardware, integers are especially easier to use
than floating point as adding floating point chews up a lot of gates.

-- 
Joshua D. Boyd
jdboyd at jdboyd.net
http://www.jdboyd.net/
http://www.joshuaboyd.org/