[Bf-committers] Proposal: Blender OpenCL compositor

[François T.]

>
> Jeron : Like what are tiles in the perspective of a user/artist and

what are tiles in perspective of parallelization.

Both definitions are right, but developers and users mix the definition

and the meaning. Sorry for that.


Thats what I thought :)



Aurel : 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 goal here is to build a compositor and as Matt says, it should do what
it's supposed too. I know that as for now the compositor had a design to
enhanced render and mostly still (and IMO that the reason it got some
limitation today too). As xsi had its fxtree or whatever.
Thinking about using it for still is like if you were telling me you would
use After Effects to do Photoshop stuff. It is possible and yes they could
make one tool of both. But there is a good reason it is two different
software even if at the end they do really similar things.
Just to say, I believe the design should concentrate on large image memory
(4k & higher is coming in future for sure) and animation above all.

>


some gradiant base algorithm & very fast blur are in needs of full buffer
for sure, but I don't understand why some nodes cannot says "I need full
buffer, so I'll wait all my parents to compute and give me a FB as input"
and other nodes (by default) based on tiles. So only a few  would be slower
than other, but still everybody would happy ?

Actually I wonder if Nuke is not doing some kind of similar thing. Matt ?
The reason it makes me think of that, is on some Nukes scripts, I have seen
some nodes updating all together, and then one of them updating kind of
seperatly, like if it was waiting for something. But again, maybe i don't
really understand the issue here, my apology :(

F


2011/1/22 Aurel W. <aurel.w at gmail.com>

> > 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
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



-- 
____________________
François Tarlier
www.francois-tarlier.com
www.linkedin.com/in/francoistarlier