<snip> MULTITHREADED DEPENDENCY GRAPH > > Pixar right now uses basically one character per thread, then > background caches frames for playback to keep cores occupied. It's > kind of a workaround, but ensuring fast playback this way is quite > nice for animators. They showed their Presto animation software, with > fast playback, opensubdiv and hair deformation on the GPU, baked ptex > applied to the mesh and lighting and shadows from the key light. All > looked quite nice. > > They are looking into finer granularity too but don't have it yet. > Dreamworks is very granular, graphs with 50k-150k nodes. Requires > careful design of rigs, but they have very good scaling. Overhead from > granularity is reduced by using TBB, and letting threads handle chains > of nodes without going through the task system. > > Pixar uses a system where there is a very clear separation between > output data and the depsgraph, for evaluating multiple frames at the > same time and to reduce locking, this is something we want in Blender > too. They also compile the depsgraph in advance, and Dreamworks caches > networks for changing various values. It's unclear if this will help > in Blender, maybe with quite complex rigs. I think it's best to leave > this as an optimization to solve when it shows up as a performance > problem. >
This paper from the Technicolor folks is two clicks away from the SIGGRAPH papers link so may (or may not) have been noticed already: http://jmarvie.free.fr/Publis/2013_WEB3D/manyCoreEventEvaluation.pdf Two level event scheduler for a multithreaded depsgraph they claim results in near-linear speedups. Dan _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers