[Bf-committers] Proposal: Blender OpenCL compositor

Brecht Van Lommel brechtvanlommel at pandora.be
Sat Jan 22 01:03:22 CET 2011


Hi,

On Fri, Jan 21, 2011 at 10:31 PM, Aurel W. <aurel.w at gmail.com> wrote:
>> DOF and Blur you can take care of with overlapping source tiles as long as you know the maximum fetch distance (the blur radius, basically). Takes a bit more memory but it means you can parallelize them pretty much how you want (with diminishing return because the overlap zone size is constant).
>
> Hi, there are many nodes, where this won't be easy, and they really
> need "full buffer access". Just computing overlapping patches for a
> simple convolution case gets far too complicated and is really not
> flexible at all.
>
> Let's assume you have filter node, with a lot of iterations, so
> several convolutions taking place. The patch based approach fails
> here, since you would need to access also the updated regions in the
> other tiles, which were computed by an other patch. The only solution
> is to grow the the overlapping areas depending on the number of
> iterations.

Another solution is to execute kernels multiple times, and load/unload
tiles each time. For each iteration you only need the same region, not
a larger region.

> Let's assume we have a convolution node as DOF, which does several
> iterations and has a long graph as an input node. Essentially the
> patch size has to be changed each time the you adjust a setting in the
> node and therefore the entire sub graph has to be evaluated again.
>
> Changing patch sizes? That doesn't make sense to me and really gets
> overcomplicated. Full buffer access is needed in this case as I
> pointed out previously. There are also other operations, which need
> access to the entire buffer to determine a single pixel.
>
> Again, I have a very bad feeling about this patch based approach.

I can't think of current nodes that would not work with such a tile
based approach, with some implementation tweaks. But I'm not sure what
your point is though, do you think there is a different, better way to
handle buffers larger than memory, or do you think it's impossible?

Brecht.


More information about the Bf-committers mailing list