[Bf-committers] Proposal: Blender OpenCL compositor

Aurel W. aurel.w at gmail.com
Sat Jan 22 13:28:27 CET 2011


> 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 ?

Yes something like that would be necessary. I guess in practice it
will be very hard to determine the required tiles, so maybe there will
be only two cases, one where only one tile is needed and the one where
simply all tiles are needed.

I am also worried about the memory layout of this. Single tiles would
be computed to separate data structures, maybe just a single array.
All tiles are computed like this for an entire image. The next node,
which needs to operate on the entire image now has to access
individually pixels in all tiles. So you have two options, introduce
some sort of abstraction to access these pixels, or copy all tiles to
a single buffer, which then gets processed. The first one adds a lot
of overhead and cache unfriendliness. The second one also adds
overhead and memory usage by copying. Of course this would need
testing and better analysis, but it can tremendously slow things down.

> the goal here is to build a compositor and as Matt says, it should do what
it's supposed too.
well, of course,...

aurel


More information about the Bf-committers mailing list