openexr-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Openexr-devel] luts


From: Drew Hess
Subject: Re: [Openexr-devel] luts
Date: Wed, 18 Feb 2004 09:59:39 -0800 (PST)

Strictly speaking I don't think ATI supports half in hardware on their
current generation of GPUs.  As far as I know, the FPUs on the R3xx series
are all 24-bit.  What I'm not sure about is where your 32-bit and 16-bit
FP textures get converted to 24 bits: in the driver at texture download
time, or in the texture unit at texture lookup time.

Anyway, yeah, it's pretty fast regardless of what method it's using :)

One caveat: according to ATI's 16-bit FP extension spec, hardware may
optionally not support denormalized numbers, so if you have some really
small values, they may round to zero earlier than you'd like.  Again, I
dunno whether the R3xx series of GPUs does that or not.  You could test
this by rendering a quad mapped with a 16-bit FP texture full of denormals
to a pbuffer and then reading it back to see if you get the same thing
(modulo any rounding that might occur when the 16-bit FP texture is
converted to 24-bit and then back again).

Denormals might not be a big deal depending on what you're doing, but
people trying to use OpenEXR's "half" datatype on GPUs should probably be
aware of this, anyway.

Also, ATI's 16-bit FP extension doesn't support inf's and nans.  So if
you're doing render-to-texture on an ATI card and you want to stuff the
result in an OpenEXR image, you might want to make a pass thru the image
before doing so to clamp over-range or nan values to half inf, unless you 
don't care that there may be inf's and nans in your OpenEXR image.

I'm hoping that future generations of ATI GPUs use the same half format as
Nvidia and OpenEXR so we can stop worrying about these minor differences.


-dwh-


On Wed, 18 Feb 2004, Ken McGaugh wrote:

> Lutz Latta wrote:
> > 
> > Sorry, I was wrong. I overlooked the fact that the value that is split 
> > up is not used as integer, but as floating point with mantissa and 
> > exponent. My suggestion only works for integer values like [0..65535].
> > 
> > I'm afraid that there are probably no easy alternatives to make those 
> > kind of bit manipulations in ARB_fragment_program. You could try to 
> > decode the half value into mantissa and exponent by doing all kinds of 
> > multiplication or other operations, driving it close to its numerical 
> > limits. But considering that other hardware doesn't offer true half 
> > operations, this is unlikely to be portable - if it is possible at all.
> > 
> > Sorry,
> >  Lutz
> > 
> 
> Thanks anyway.  I'm trying to get a 1D texture working as a lut right
> now instead.
> 
> BTW, I have successfully used half data on other hardware, namely my
> G4 powerbook with an ATI graphics card.  It runs so fast I have to
> assume it fully supported in the ATI hardware.
> 
> --Ken
> 
> 
> 
> 
> _______________________________________________
> Openexr-devel mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/openexr-devel
> 
> 






reply via email to

[Prev in Thread] Current Thread [Next in Thread]