[Bf-cycles] HDR texture support

[David Black]

Hi Mike,

Firstly congratulations on the new arrival, no I don't mean HDR textures! :)

 From an end users perspective, excuses the simplistic explanation, is 
it possible to keep all textures non float, adding a HDR check box to 
the texture node and texture selection within the UI, so just those 
textures are float, helping save available graphics card memory.

David
-- 

3d-designs-davidblack.blogspot.com 
<http://www.3d-designs-davidblack.blogspot.com>


On 30/01/2012 18:57, Mike Farnsworth 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-cycles/attachments/20120130/5337dd46/attachment.htm