[Bf-cycles] HDR texture support

[Brecht Van Lommel]

This patch has been committed now, thanks!

Brecht

On Tue, Jan 31, 2012 at 8:55 AM, Mike Farnsworth
<mike.farnsworth at gmail.com> wrote:
> 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
>
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> http://lists.blender.org/mailman/listinfo/bf-cycles
>