Hi, On Fri, Jan 21, 2011 at 10:31 PM, Aurel W. <[email protected]> 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. _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
