[Bf-committers] Proposal: Blender OpenCL compositor

Thu Jan 20 23:48:41 CET 2011

btw, you confirm that Expression PY & Python Pixelizer are two different
thing right ?
by Expression PY, I meant behing able to type some python for each
parameter. (I don't have any UI design for that, but it could be something
like : right click on a param > click on Set Expression > a textfield popup
to type the expression > click OK > the param goes to red color to show it
is control by an expression)

while a Python pixelizer as I understand it is more like a pixel processing
node (like the Expression Node in Nuke) which could be coded via Py (which
can call ocl, glsl, c, ... functions) ? And I understand this is not a
performance processing approach, but as in a production & artist side... not
everyone can have time or capabilities to create a new node/filter in C and
recompile the entire blender while sometimes an simple equation could just
be type and get the results.

I think that for a list of missing nodes or nodes to get rid of it,
Sebastian & Pablo should join the talk :)

Thx

François,

2011/1/19 Jeroen Bakker <j.bakker at atmind.nl>

> Hi Francois!
>
> well... my answer is still in a very early draft :). Today I took the
> time to dive into your posting in detail. I missed some parts when I
> read it first.
>
> Expression PY and Python pixelizer is do-able. I just need to include
> this in the proposal. I really see the value of having this. In my
> perception this is on all settings of a node (in Nuke I thought it was
> in a different node. perhaps we can borrow this idea from them.) also a
> Python based pixelizer can be done. but can have some limitation in
> performance. But that is to the artist to decide.
>
> On OpenFX I still haven't looked into the details. Currently I think
> that the bottleneck of implementing this is more on the Blender UI. As
> OpenFX has plugin capabilities the UI should be capable of handling
> flexible node settings etc based on your installed plugins. And also the
> reading and writing to a blend file is not that flexible (yet). I will
> spend some time next month in this subject. Also an issue is that it is
> Windows only. They state that a port is in the planning to Linux.
>
> Also what I personally miss is to really be able to twitch the internals
> of a node. In October I have, with the knowledge of Ton, reverse
> engineered the defocus node and came to a conclusion that it was
> implemented differently than we initially thought. Also when reading how
> many 'feature request' on this node is are placed in the bug-tracker and
> the complexity of the node there should me more options on the node to
> finetune the usage. This way nodes can become more generally usable. The
> main settings could be altered on the node, but the detailed settings
> can be altered in a panel (the N-key in the compositor). There is more
> place and will be more dynamic as it is python based.
>
> A different thing I want to change in the proposal is the current
> connector types. Currently they are buffers of 1, 2, 3 or 4 float
> values, representing Value, Vector and Color. The node system is
> flexible, but simple tasks can become a spaghetti of lines. I think that
> when we put all data of a single pixel in a single type. When connecting
> a rendered layer to the vector-blur node for example, will be one line,
> containing all needed data. Tweaking of the vectors can be done by
> settings, or by an expression node. This way we can reduce the number of
> links and make the node system easier to use. Perhaps we will introduce
> some limitations, but they can be tweaked. The node system will be
> cleaner (in functionality and usage). Also color model should be
> included in this data type.
>
> My question back is in this kind of situation, what nodes do we expect,
> and what nodes shall not be used anymore.
>
> I really like this discussion. It will take the proposal to the next level!
>
> Jeroen.
>
> On 01/19/2011 12:30 AM, François T. wrote:
> > thx for answering to my blog post via your proposal, to answer some of
> your
> > questions there :
> >
> > *expression py* ->  only because it is User/Artist oriented. While python
> is
> > great for doing this kind of stuff and pretty popular to most people, I'm
> > not so sure about openCL language. by the way this is not a way to make
> new
> > node, it is just a node which can control some parameter or datas in your
> > comp.
> > Look at what is done with Expression in AE :
> > http://www.videocopilot.net/basic/tutorials/09.Expressions/ I don't
> think it
> > does need OCL power to do this kind of thing. Probably more for the Nuke
> > kind of Expression node because it can be do some pixel processing, but
> then
> > it is just a wrapper ?
> > Maybe on a programmer stand point of view it needs to be openCL or
> > whatever... maybe not for the front end user. IMO this needs to be
> > consistent with the rest of the scripting language in Blender. Again
> > production tool :)
> >
> >
> > *custom passes* are not mask, they are just render passes (normal, P
> pass,
> > vector pass... ), but more on a 3d render side rather than the
> compositor.
> >
> > *masks* if you refer to the Addon RotoBezier, then yes it is still to be
> > done IMO. this should be a native tool with all the features that comes
> > with. Probably a new node any way. As I said RotoBezier is a great work
> > around in the mean time, but not a production tool at all.
> >
> > *openFX* please pretty please :D
> >
> >
> > F
> >
> >
> >
> >
> > 2011/1/16 Erwin Coumans<erwin.coumans at gmail.com>
> >
> >> Bullet uses its own MiniCL fallback, it requires no external references,
> >> the main issue is that it is not a full OpenCL implementation (no
> barriers
> >> yet etc). We developed MiniCL primarily for debugging and secondary to
> run
> >> the Bullet OpenCL kernels on platforms that lack an OpenCL
> implementation.
> >>
> >> The Intel and AMD OpenCL drivers for CPU perform similar to regular
> multi
> >> threaded code (pthreads, openpm etc) but it is more suitable for data
> >> parallel problems and not for complex code with many branches.
> >>
> >> So while you can port a compositor or cloth simulation to OpenCL, most
> >> general purpose code requires large refactoring and simplification
> causing
> >> reduced quality, so don't expect miracles.
> >>
> >> Still, it will be fun to see compositing, physics simulation etc in
> Blender
> >> being accelerated through OpenCL, optionally.
> >>
> >> Thanks,
> >> Erwin
> >>
> >> On Jan 16, 2011, at 5:34 AM, Jeroen Bakker<j.bakker at atmind.nl>  wrote:
> >>
> >>> On 01/15/2011 03:55 PM, (Ry)akiotakis (An)tonis wrote:
> >>>> On 15 January 2011 09:19, Matt Ebb<matt at mke3.net>   wrote:
> >>>>> While I can believe that there will be dedicated online farms set up
> >>>>> for this sort of thing I was more referring to farms in animation
> >>>>> studios, most of which are not designed around GPU power - now, and
> >>>>> nor probably for a while in the future. Even imagining if in the
> >>>>> future blender uses openCL heavily, if a studio has not designed a
> >>>>> farm specifically for blender (which is quite rare), CPU performance
> >>>>> will continue to be very important. I'm curious how openCL translates
> >>>>> to CPU multiprocessing performance, especially in comparison with
> >>>>> using something like blender's existing pthread wrapper.
> >>>>>
> >>>>> cheers,
> >>>>>
> >>>>> Matt
> >>>>> _______________________________________________
> >>>>> Bf-committers mailing list
> >>>>> Bf-committers at blender.org
> >>>>> http://lists.blender.org/mailman/listinfo/bf-committers
> >>>>>
> >>>> I have to disagree on that. Almost every 'serious' user today has an
> >>>> OpenCL capable GPU and they can benefit from an OpenCL implementation.
> >>>> Besides OpenCL allows for utilization of both CPU and GPU at the same
> >>>> time. It's not as if it sets a restriction on CPUs.
> >>> In my understanding the issue is that internal renderfarms have no
> >>> 'OpenCL' capable GPU (yet). It is not an issue on the user side. Like
> >>> during durian, we have workstations with medium gpu's and only cpu
> based
> >>> renderfarm. The question is how would a cpu-based renderfarm benefit
> >>> from opencl?
> >>>
> >>> Users on the otherhand have different issues. Our user population also
> >>> have non OpenCL capable hardware/OS's. therefore we still need a full
> >>> CPU-based fallback or the bulletsolution by implementing an own opencl
> >>> driver. The bullet solution is complicated in our situation as it needs
> >>> a lot of external references (compilers, linkers, loaders etc)
> >>>
> >>> Jeroen
> >>> _______________________________________________
> >>> Bf-committers mailing list
> >>> Bf-committers at blender.org
> >>> http://lists.blender.org/mailman/listinfo/bf-committers
> >> _______________________________________________
> >> Bf-committers mailing list
> >> Bf-committers at blender.org
> >> http://lists.blender.org/mailman/listinfo/bf-committers
> >>
> >
> >
>
>
> --
>
> Met vriendelijke groet,
>
> Jeroen Bakker
>
> *At Mind BV
> *
>
> Telefoon: 06 50 611 262
> E-mail: j.bakker at atmind.nl <mailto:j.bakker at atmind.nl>
>
>
> _______________________________________________
> 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