[Bf-committers] Proposal: Blender OpenCL compositor

[Aurel W.]

> 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