[Bf-cycles] HDR texture support

[Mike Farnsworth]

I'm adding support for float format textures (particularly for
environments and emission textures, as that's where they are
particularly useful), and I'm to the point where I think I need some
wisdom on what is the best way to proceed.  Here are a few options,
I'd like to see any feedback y'all have regarding them:

* Force float textures for all textures.  Pros: easy to do, very
simple patch.  Cons: takes up 4x the RAM, which is particularly
troublesome for GPUs, and compiles in that way.

* Global option.  Pros: fairly simple to do.  Cons: very blunt
solution, and we have to compile multiple versions of the kernels, as
the float vs. non-float settings on the textures are compile-time;
all-or-nothing could put people over on RAM limits just because they
need one float texture.

* Hard-coded X number of float texture slots, out of the 100
available.  Pros: fairly straightforward to do.  Cons: not very
flexible.

* CUDA layered textures, semi-dynamic texture management.  This is the
most complex option, where we would group all textures together that
are the same size, and same format (e.g. float RGBA vs. 8888 RGBA)
into a layered texture.  Each texture then gets a slot as they do now,
but also an index.  There appears to be a 512 MB limit on total
texture size, but I haven't verified if that's the case for layered
textures, but that would also be taken into account for spillover to
additional slots.  A fixed number of float texture slots would also be
allocated at compile-time from the 100 total slots, and textures would
be grouped dynamically within those as well.    Pros: much more
flexible, potentially raises the 100 texture limit we have now
substantially higher (and in my opinion, 100 textures is *extremely*
restrictive for typical animation/VFX shots).  Cons: more difficult to
implement, and OpenCL only seems to support arrays of 2D textures in
OpenCL 1.2, which is very new.  Also, in order for this to work well,
textures need to be the same size, or else we need to have the option
of upping their resolution to match a slot that already is allocated
when GPU memory is available.  Then the grouping would likely be
effective enough.

I suspect that the last option is something that will have to be done
at some point.  The 128 total texture limit in CUDA is...embarassing
IMHO, but using layered textures to work around it could be a good way
to go.  It is a bit of work.  The first option is too blunt and will
shut numerous people out of using the GPU.  The second option I don't
like at all; if we're going to complicate things, the other choices
are better.  The third option would work as a decent workaround, but
if there are people already using all or nearly all of the texture
slots we'd break their ability to use GPU rendering.

Thoughts?

-Mike