[Bf-committers] Proposal: Blender OpenCL compositor

Jeroen Bakker j.bakker at atmind.nl
Wed Jan 19 21:57:54 CET 2011


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>




More information about the Bf-committers mailing list