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