[Bf-committers] Proposal: Blender OpenCL compositor

[Aurel W.]

> 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.
Even if we just assume the existing nodes, there are lots of issues
with tiles. To be future-proof, also other nodes and operations have
to be considered. I mentioned some, they might not be the best
examples, but they demonstrate issues with the design. Strong limits
in this tile based design are a con. Sorry if this seems to be just
"theoretical objections", but just comparing a design to the existing
nodes won't do it.

> 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.
Again, just examples for operations on images,... and I guess
tone-mapping isn't such a bad one, especially if you consider
compositing of single images, not animations.

> The benefits are lower memory usage, and better/easier parallelisation.
In practice, if you assume that your memory can hold multiple buffers
anyway, I can't significant improvements in memory usage. We also have
to distinguish between two use cases here, the one where compositing
graph is just executed once and the one where a user interactively
adjusts settings and wants to keep intermediate results in memory.
Again, there is no proposal for a caching scheme for the tiled based
solution in the interactive case yet and I can't think of anything
that would have large benefits compared to work on full buffers and
also cache those.

I also highly doubt that this will lead to better/easier
parallelisation. I still think that more fine grained parallelisation
in each individual node, operating on the entire buffer, would turn
out better in practice.

At least I want to have a discussion on this. Just to assume
prematurely, that tiles will give better performance is not a good
idea.

aurel