> 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. Things start to get a little confusing now. I thought that the entire graph or one output node can be evaluated for a single tile. At least this is how I understand the proposed tiled based system should work. Am I wrong in this case?
So what you try to say is, that for one filter node, all tiles of the image have to be computed for each single iteration, where tiles have an overlapping area of the filter size. In the next iteration, the tiles are newly loaded containing also the results from neighboring tiles from the last iteration? And this has to be implemented somehow in the filter node then? So in the end, image by image is convoluted and the next iteration can't start before all tiles have finished? I sort of ment this by "the full buffer" is needed. > 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? I have no doubt, that it wouldn't work, the question is how efficient it is and if there are no better solutions and if this is really necessary. So if I get this right, the only reason for tiling is to handle large buffers? Large as in larger than main memory order video ram in case of opencl? I am not sure, if this is really necessary and to handle such large images, also other things have to be adapted to support this, like the image viewer, exr loading, renderbuffer,... So are there really plans to support rendering/viewing/compositing like 32k images in blender from now on? I agree, that tiling would be the only way to support the processing of images larger than main memory. But I don't think that it will give better performance and I also think that it introduces a lot of unnecessary complexity. aurel _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers