[Bf-cycles] HDR texture support

[Thomas Dinges]

1) It's not finished.
2) We are in BCon4 atm, meaning no new features, only bug fixes.

DingTo

Am 12.02.2012 21:00, schrieb 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
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> http://lists.blender.org/mailman/listinfo/bf-cycles


-- 
Thomas Dinges
Blender Developer, Artist and Musician

www.dingto.org