<div dir="ltr">Yes, it's not ideal and i'd indeed rather consider this is a temporary solution.<div><br></div><div>I'd rather not to work on a proper load balancing for now and have fundamental problems solved first (which is making modifier stack really thread-safe). Once this is solved, we could work on a task pool.</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Jun 29, 2013 at 5:50 AM, Brecht Van Lommel <span dir="ltr"><<a href="mailto:brechtvanlommel@pandora.be" target="_blank">brechtvanlommel@pandora.be</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Sergey,<br>
<br>
I'm not sure this design with threaded groups is ideal. Maybe it's<br>
temporary, but as I understand it you're trying to divide the work in<br>
advance. This is not going to give good scaling across threads as the<br>
amount of work for each object or group is difficult to predict. I<br>
think the way this should work is that you have a queue of objects<br>
that are ready to be updated, and threads will each pick an object<br>
from it, and when done add any objects to the queue that are now ready<br>
to be updated because all their dependencies are done.<br>
<br>
It also more naturally fits with e.g. dupligroups or armatures I<br>
think. You may need to evaluate duplis before you can find out if some<br>
proxy object needs to be updated. Instead of having to figure out all<br>
that stuff in the main thread in advance, a thread can go into the<br>
dupli group and dynamically add more work to the queue as needed. Same<br>
with armatures, if the main thread needs to figure out in advance<br>
which bones need to be evaluated that's no ideal, it's better if a<br>
worker thread can do that and figure it out while other worker threads<br>
already start evaluating other objects.<br>
<br>
Some time ago I did a test porting the Cycles task scheduler to C. I<br>
almost forgot this, maybe it's useful to you. It's basically the<br>
mechanism described, you push tasks into a queue and threads pick them<br>
off that queue and spawn their own if needed. It's possible to make a<br>
better implementation, but I think multithreaded graph or game engine<br>
implementations are almost always task queue based, I'm not sure how<br>
else you can do proper load balancing.<br>
<br>
<a href="http://www.pasteall.org/43629/diff" target="_blank">http://www.pasteall.org/43629/diff</a><br>
<br>
Brecht.<br>
<div><div class="h5"><br>
On Fri, Jun 28, 2013 at 11:58 PM, Sergey Sharybin <<a href="mailto:sergey.vfx@gmail.com">sergey.vfx@gmail.com</a>> wrote:<br>
> Hi,<br>
><br>
> From the code side this week i did:<br>
><br>
> * Experimental feature to lock the interface while rendering, which locks<br>
> the whole interface forbidding changing any data and preventing viewport<br>
> from running into conflict with render thread.<br>
><br>
> Also implemented small feature which will allow panning/zooming in image<br>
> editor while interface is locked.<br>
><br>
> * Worked on running object_handle_update from multiple threads.<br>
><br>
> Basis code is here, need to be cleaned up a bit, but it works in general.<br>
> However this change unleashed some more areas which are not safe for<br>
> threading, read about this in plans for the next week.<br>
><br>
> From the documentation point of view, not so much done actually. Made some<br>
> discussions with Campbell about how to keep memory usage sane when copying<br>
> all the scene graph, but it's still some black holes in the design i'd say.<br>
><br>
> = Next week =<br>
> Would work on making this areas thread safe:<br>
><br>
> * Curves, which are likely still using some pointers stored in Curve<br>
> datablock, which makes it unsafe to create displist from multiple threads<br>
> when curve is used by multiple objects.<br>
> * Virtual modifier list, which seems to be smallest change for the next<br>
> week.<br>
> * Look into armature modifier and hope to change storing runtime data in<br>
> armature itself, so armature modifier becomes safe for threading.<br>
> * And hope to finish design document for safe and nice local graphs.<br>
><br>
> = Questions =<br>
> No new question actually,<br>
><br>
> P.S. Just in case, reports are also there:<br>
> <a href="http://wiki.blender.org/index.php/User:Nazg-gul/GSoC-2013/WeeklyProgress" target="_blank">http://wiki.blender.org/index.php/User:Nazg-gul/GSoC-2013/WeeklyProgress</a><br>
><br>
> --<br>
> With best regards, Sergey Sharybin<br>
><br>
</div></div>> _______________________________________________<br>
> Soc-2013-dev mailing list<br>
> <a href="mailto:Soc-2013-dev@blender.org">Soc-2013-dev@blender.org</a><br>
> <a href="http://lists.blender.org/mailman/listinfo/soc-2013-dev" target="_blank">http://lists.blender.org/mailman/listinfo/soc-2013-dev</a><br>
><br>
_______________________________________________<br>
Soc-2013-dev mailing list<br>
<a href="mailto:Soc-2013-dev@blender.org">Soc-2013-dev@blender.org</a><br>
<a href="http://lists.blender.org/mailman/listinfo/soc-2013-dev" target="_blank">http://lists.blender.org/mailman/listinfo/soc-2013-dev</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div><span style="color:rgb(102,102,102)">With best regards, Sergey Sharybin</span></div>
</div>