This patch enables TBB as the default task scheduler. TBB stands for Threading Building Blocks and is developed by Intel. The library contains several threading patters. This patch maps blenders BLI_task_* function to their counterpart. After this patch we can add more patterns. A promising one is TBB:graph that can be used for depsgraph, draw manager and compositor.
Performance changes depends on the actual hardware. It was tested on different hardwares from laptops to workstations and we didn't detected any downgrade of the performance.
* Linux Xeon E5-2699 v4 got FPS boost from 12 to 17 using Spring's 04_010_A.anim.blend.
* AMD Ryzen Threadripper 2990WX 32-Core Animation playback goes from 9.5-10.5 FPS to 13.0-14.0 FPS on Agent 327 , 10_03_B.anim.blend.
Reviewed By: brecht, sergey
Differential Revision: https://developer.blender.org/D7475
Tasks: move priority from task to task pool {rBf7c18df4f599fe39ffc914e645e504fcdbee8636}
Tasks: split task.c into task_pool.cc and task_iterator.c {rB4ada1d267749931ca934a74b14a82479bcaa92e0}
Differential Revision: https://developer.blender.org/D7385
Was happening when having compositor open with Viewer node attached
directly to Render Layers output.
There were two things involved here:
1. The code which was storing CoW-ed versions of IDs was checking all
IDs for whether they are expanded or not. This was causing access
of freed memory for deleted IDs which do not need CoW (such as IM).
Simple fix: store ID type as a scalar and use early check before
doing more elaborate check based on accessing fields of id_cow.
2. The code which was ensuring view layer pointer is doing CoW for
scene. This isn't an issue on its own, but scene might have an
embedded ID such as compositor which was actually traversed by the
ID remap routines. This was causing remapping procedure to go into
non-updated copy of compositor, accessing freed Viewer image ID.
Solved by not recursing into embedded IDs for datablocks as those
are supposed to have own copy-on-write operations which takes care
of re-mapping.
Reported my Bastien, and also pair-coded with him.
The FPS here is measured based on a timestamp from when depsgraph
was previously evaluated.
Allows to ease investigating performance improvements/regressions
which are not related on animation system but on modifications on
a single frame (such as transforming vertex in edit mode).
This commit restores old metaball workaround which was forcing their
update from a single thread.
The root of the issue comes to the fact that metaball evaluation needs
to access metaballs from duplilists, so they are properly polygonized
with corresponding motherball which is outside of duplilist.
In a more ideal world this will be implemented in a way that will not
require iterating over all duplilists, but only through the ones which
actually contain metaballs for the given motherball. In practice this
ends up in a huge refactor in both relations builder (which meeds to
see whether there are metaballs in duplilists without actually
creating duplilist as it can not be done prior scene is evaluated)
and in metaballs area which need to use new relations information.
Additionally, metaball evaluation must become thread-safe, which is
currently not a case with dupli-object matrices. There might be issues
deeper in polygonization code which I am not aware of.
Having this forced single-thread evaluation is same as Blender 2.79
was doing.
Think it's better to have slower but simpler solution than to invest
time in refactoring area which requires deeper design changes.
Reviewed By: dfelinto
Differential Revision: https://developer.blender.org/D6539
Found this while looking into T70463, solves the high spinning times
mentioned in T70463#791026.
Sounds logical that iterating over an array to modify a single property
is faster than doing it in threads. But strangely, doing it for both
nodes and its components is still faster in threads here.
Gives extra speedup with a file mentioned in the report.
Reviewed By: brecht, mont29
Differential Revision: https://developer.blender.org/D6017
BF-admins agree to remove header information that isn't useful,
to reduce noise.
- BEGIN/END license blocks
Developers should add non license comments as separate comment blocks.
No need for separator text.
- Contributors
This is often invalid, outdated or misleading
especially when splitting files.
It's more useful to git-blame to find out who has developed the code.
See P901 for script to perform these edits.
Some summary of changes:
- Don't use DEG prefix for types and enumerator values:
the code is already inside DEG namespace.
- Put code where it locally belongs to: avoid having one
single header file with all sort of definitions in it.
- Take advantage of modern C++11 enabled by default.
COW nodes in the graph are mostly connected via a relation type
that doesn't propagate the update flags. Unfortunately, due to
the scheduling implementation that means the relations don't
actually guarantee execution order for indirect dependencies.
Relations also don't guarantee order in case of cycles.
As mentioned in IRC, the simplest way to fix possible problems
is to execute all COW nodes as a separate execution stage. This
seems to fix crashes with Data Transfer modifier in a cycle.
Staging works by simply delaying actual scheduling of tasks for
non-COW nodes until the second run of schedule_graph.
Reviewers: sergey
Differential Revision: https://developer.blender.org/D4027
The idea of those flags is to avoid evaluation of operations
which are not needed to bring visible objects to an up to date
state.
Previously, dependency graph attempted to do combine those
into an ID level flag. In practice it proved to be rather
tricky, since there could be dependency cycles on ID level
which will not exist on component level.
The title says it all actually, the idea is to speedup the following case:
- Visible duplicator of a restricted collection (reported as T56512),
One of the questionable change is that none of the view layer bases is
ignored now. This ensures corresponding objects will have copy-on-write
component evaluated, making it possible to access those pointers. The
evaluation of those objects is skipped.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D3641
After discussion with Sergey and Dalai, we have decided to remove
this option completely. We're getting to the point where it is almost
impossible to really use 2.8 without COW, and keeping the old option
running ends up diverting dev resources away towards tracking down
and fixing problems with a parallel system that will be going away.
Previously it could have happened on every request to evaluated scene
or view layer.
This commit also removes expansion of view layer and scene from iterator.
Iterator is not to be used before depsgraph is evaluated.
The depsgraph was always created within a fixed evaluation context. Passing
both risks the depsgraph and evaluation context not matching, and it
complicates the Python API where we'd have to expose both which is not so
easy to understand.
This also removes the global evaluation context in main, which assumed there
to be a single active scene and view layer.
Differential Revision: https://developer.blender.org/D3152
Fix for T54437: Sequencer preview uses last updated scene
The fix started in master, moving EvaluationContext initialization
before we leave `deg_evaluate_on_refresh()`.
Upon merging master we can fix the actual issue which was to set
the EvaluationContext depsgraph even if the depsgraph was already updated.
This is required to T54437 (sequencer preview uses last updated scene).
Although the fix itself needs to be in 2.8, for the 2.8 specific
initialization code.
