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