[Bf-cycles] HDR texture support

[Virgil Ioan]

Any reason why this isn't committed yet? I could really use this particular patch as I'm sure many others would, besides, using HDR environments as LDR and without any type of adjustable tone mapping is kind of strange.

P.S. First time poster on a list so I hope this is how it works.

-Virgil

Date: Mon, 30 Jan 2012 23:55:08 -0800
From: Mike Farnsworth <mike.farnsworth at gmail.com>
Subject: Re: [Bf-cycles] HDR texture support
To: bf-cycles at blender.org
Message-ID:
    <CAPZh=FueA8baN+=QRDLTX=ZuXK_rYZx8Q-qB-Pm3A9w2+-5MYA at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

As a stopgap, I've implemented the third option (I siphoned off 5 of
the 100 texture slots as float texture slots), but with the added
benefit that the user doesn't have to specify which textures are
float, and which ones are not.  It uses OIIO to detect texture
formats, and in the case that the native texture format is half, float
or double it will go ahead and use a float texture slot.

Good news: this enables HDR textures for use on *anything* you can
assign a texture to for Cycles.  Bad news: there are 5 slots taken up
(for those that needed them for regular textures), but there are only
5 slots available (for those that might need more than 5 for HDR
textures).

I tested this with Radiance HDR/RGBE, EXR, TIFF, and some other LDR
formats to make sure it appeared to grab the correct slots each time.
Patch is attached.

-Mike

On Mon, Jan 30, 2012 at 10:57 AM, Mike Farnsworth
<mike.farnsworth at gmail.com> wrote:
> 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