[Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [35338] trunk/blender/source/blender: bugfix #26267

[Lukas Tönne]

> And i'm not 100% sure what's happening with this
> ntreeBeginExecTree/ntreeEndExecTree. I've tried to add this near texture
> recalculation in fixed texture brush handler and it worked fine (but
> really slow). But why it's not affected with threading issues? I mean
> what would happen if preview widget would be triggered to redraw between
> my ntreeBeginExecTree/ .. ntreeEndExecTree block? Wouldn't it also lead
> to wrong texture recalculation? And if it've got copy of node tree why
> this BeginExec/EndExec is necessery? And i'm also afraid of preview
> refresh triggering between ntreeBeginExecTree() and actual image
> generating from texture.

Yea, i've been shaking my head over this mess for some time now.
Storing execution data (the "stack") _inside_ the node tree is bad
imo. Afaik it only works for current node trees because only shader
and texture nodes are actually working in parallel, and these use a
(probably inefficient) method of duplicating the stack data for each
sample evaluation, split between threads. Compo nodes otoh don't have
real parallelization, they only assign nodes to threads as a whole.

The whole thing is bound to cause serious trouble as soon as we try to
use "nodetrees in nodetrees" more extensively: texture nodes used in
other trees are only the start! Has anybody tried using the same node
texture in parallel already? My guess is that sooner rather than later
this will lead to more threading conflicts, because nodes try to
evaluate trees that are already in use.

As mentioned before, i'd like to see "execution data" split off of the
node trees. Each evaluation of a node tree (i.e. one per
shader/texture sample or compo buffer output) would be writing its
data to a unique buffer (can be many for each tree), instead of
artificially trying to separate data during execution. This would also
work much better for things like groups inside groups (which are just
another instance of "nodes using trees"). The reason i didn't do it
yet is that it requires some other means of storing per-sample
execution data than simply accessing the nodetree->stack pointer.

> -------- Original Message --------
> Subject: [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [35338]
> trunk/blender/source/blender: bugfix #26267
> From: Ton Roosendaal <ton at blender.org>
> To: bf-blender-cvs at blender.org
> Date: 03/03/2011 11:53 PM
>> Revision: 35338
>>            http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=35338
>> Author:   ton
>> Date:     2011-03-03 18:53:07 +0000 (Thu, 03 Mar 2011)
>> Log Message:
>> -----------
>> bugfix #26267
>>
>> ImageWindow + 3D view texture paint + texture preview render + texture nodes.
>> Threading hell! But it works now :)
>>
>> Modified Paths:
>> --------------
>>      trunk/blender/source/blender/blenkernel/BKE_texture.h
>>      trunk/blender/source/blender/blenkernel/intern/node.c
>>      trunk/blender/source/blender/blenkernel/intern/texture.c
>>      trunk/blender/source/blender/editors/render/render_preview.c
>>      trunk/blender/source/blender/editors/sculpt_paint/paint_image.c
>> ...
>
>
> --
> With best regards, Sergey I. Sharybin
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>