[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