<div>My uneducated opinion:</div>Perhaps for the next release a blunt easy solution - Global option.<br>Slow global floats is better then no floats.<br><div>And then start implementing it properly.<div><br><br><div class="gmail_quote">
On 30 January 2012 20:57, Mike Farnsworth <span dir="ltr"><<a href="mailto:mike.farnsworth@gmail.com">mike.farnsworth@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm adding support for float format textures (particularly for<br>
environments and emission textures, as that's where they are<br>
particularly useful), and I'm to the point where I think I need some<br>
wisdom on what is the best way to proceed. Here are a few options,<br>
I'd like to see any feedback y'all have regarding them:<br>
<br>
* Force float textures for all textures. Pros: easy to do, very<br>
simple patch. Cons: takes up 4x the RAM, which is particularly<br>
troublesome for GPUs, and compiles in that way.<br>
<br>
* Global option. Pros: fairly simple to do. Cons: very blunt<br>
solution, and we have to compile multiple versions of the kernels, as<br>
the float vs. non-float settings on the textures are compile-time;<br>
all-or-nothing could put people over on RAM limits just because they<br>
need one float texture.<br>
<br>
* Hard-coded X number of float texture slots, out of the 100<br>
available. Pros: fairly straightforward to do. Cons: not very<br>
flexible.<br>
<br>
* CUDA layered textures, semi-dynamic texture management. This is the<br>
most complex option, where we would group all textures together that<br>
are the same size, and same format (e.g. float RGBA vs. 8888 RGBA)<br>
into a layered texture. Each texture then gets a slot as they do now,<br>
but also an index. There appears to be a 512 MB limit on total<br>
texture size, but I haven't verified if that's the case for layered<br>
textures, but that would also be taken into account for spillover to<br>
additional slots. A fixed number of float texture slots would also be<br>
allocated at compile-time from the 100 total slots, and textures would<br>
be grouped dynamically within those as well. Pros: much more<br>
flexible, potentially raises the 100 texture limit we have now<br>
substantially higher (and in my opinion, 100 textures is *extremely*<br>
restrictive for typical animation/VFX shots). Cons: more difficult to<br>
implement, and OpenCL only seems to support arrays of 2D textures in<br>
OpenCL 1.2, which is very new. Also, in order for this to work well,<br>
textures need to be the same size, or else we need to have the option<br>
of upping their resolution to match a slot that already is allocated<br>
when GPU memory is available. Then the grouping would likely be<br>
effective enough.<br>
<br>
I suspect that the last option is something that will have to be done<br>
at some point. The 128 total texture limit in CUDA is...embarassing<br>
IMHO, but using layered textures to work around it could be a good way<br>
to go. It is a bit of work. The first option is too blunt and will<br>
shut numerous people out of using the GPU. The second option I don't<br>
like at all; if we're going to complicate things, the other choices<br>
are better. The third option would work as a decent workaround, but<br>
if there are people already using all or nearly all of the texture<br>
slots we'd break their ability to use GPU rendering.<br>
<br>
Thoughts?<br>
<br>
-Mike<br>
_______________________________________________<br>
Bf-cycles mailing list<br>
<a href="mailto:Bf-cycles@blender.org">Bf-cycles@blender.org</a><br>
<a href="http://lists.blender.org/mailman/listinfo/bf-cycles" target="_blank">http://lists.blender.org/mailman/listinfo/bf-cycles</a><br>
</blockquote></div><br></div></div>