[Bf-committers] Proposal: Blender OpenCL compositor
Ton Roosendaal
ton at blender.org
Fri Jan 21 19:33:33 CET 2011
Hi Brecht,
Great remarks, and several of these I can assist on too. The get-pixel
one will be toughest though... I know several nodes have been heavily
optimized to use rows.
I need to study Jeroen's proposal in detail still, can't say much...
but based on all the feedback he received, it's definitely good to try
to limit the scope of work as much as possible, or define a step by
step migration path.
Reply to some concerns here;
- The compositor should run always good on CPU (multi core) too. I'm
convinced it would benefit OpenCL's thread balancing a lot already. A
bit of performance loss compared to a full native pthread
implementation (like 10-20% ?) is acceptable, provided the GPU gains
are very evident.
- My impression is that non-openCL usage will be mostly on render
farms, and nearly every average-to-decent 3D workstation will have
excellent GPU performance. Artist time is still far more valuable than
computer time :)
- A tile-based subdivision schedule is for two reasons; efficient
memory use (valid for cpu and gpu alike) and for a potential efficient
threading setup. The latter has to be carefully designed, to prevent
bottlenecks on individual nodes that need full buffers (like DOF,
Vector Blur).
-Ton-
------------------------------------------------------------------------
Ton Roosendaal Blender Foundation ton at blender.org www.blender.org
Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands
On 21 Jan, 2011, at 16:55, Brecht Van Lommel wrote:
> Hi Jeroen,
>
> I'll comment on the tiling / OpenCL proposal itself in another mail
> later.
>
> I agree with Matt that it would be good to address a number of design
> issues first. Perhaps these could be implemented before work on tiling
> or OpenCL begins.
>
> * Automatic data type conversion between nodes.
> * Storing channels non-interleaved.
> * Premul vs. key alpha. We should have a convention here and stick
> to it.
> * Color management. Also think we should decide on a convention here.
> * Store transformations along with buffers.
> * Change all nodes to use a get_pixel function.
>
> Options to shuffle channels, or change color spaces can all be done
> outside of nodes, as part of automatic data conversion as already
> proposed. A get_pixel function would handle
> procedurals/transformations automatically. These things don't seem
> particularly hard to implement, but would be quite a bit of work
> refactoring code.
>
> Further, most of the things in the VFX proposal seems like they would
> not have much effect on the internal workings, more about UI and
> different ways to get data in/out of the compositor.
>
> Brecht.
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
More information about the Bf-committers
mailing list