[Bf-committers] SIGGRAPH observations

[Dan Eicher]

<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