[Bf-committers] Proposal: Blender OpenCL compositor

[Matt Ebb]

On Sat, Jan 22, 2011 at 8:11 PM, Aurel W. <aurel.w at gmail.com> wrote:
> I also realize that the argument "it would work with the current
> compositor" is a strong argument. But I got some problems with that.
> First of all I think that a compositor should be in principal be able
> to support all image processing operations.

On the contrary, I think the compositor should be designed and
optimised for its purpose, compositing CGI/vfx imagery. It doesn't
need to be a completely generalised image processing system, it just
needs to do what it's intended for, well. So far I've seen a mostly
theoretical objections here, but I think it's important to keep
focused on enabling people to produce shots.

> But back to the simple issue with operations, which need full buffer
> access. I agree that this could be still done with tiling, because you
> can simply compute all input tiles and just access those when
> computing one single output tile.

Or rather the tiles that are necessary at any given time. In the case
of the Normalize node for example (which is mostly useless for
animated sequences, as are any tone mapping operators that work in a
similar way), it would be possible to retrieve each tile one by one in
a pre-process, read and store the statistical information, and then
apply that per tile or even per pixel.

> In terms of memory usage, caching, etc. if we assume that only
> reasonable sized buffers are used, let's say up to 64MB, I also don't
> see the strong benefits in using tiles rather than buffers, which hold
> the entire image.

The benefits are lower memory usage, and better/easier parallelisation.