| Age | Commit message (Collapse) | Author |
|---|
|
|
|
For now just make new depsgraph do similar updates to the old one.
See bug report for more detailed information about what was going on.
|
|
|
|
|
|
Avoids using copy-constructor invoked every time we pass function
to the builder functions.
Should lower number of CPU ticks spent during DEG construction.
|
|
Was rather weird and only used for time source. It is simpler to make depsgraph
to keep track of time source directly.
No need to introduce extra entitites without actual need.
|
|
|
|
The idea is to use this function for modifiers' updateDepsgraph functions
instead of doing direct scene->depsgraph access.
|
|
|
|
|
|
Was internally a no-op operation, which only caused extra work
to be done during depsgrpah traversal and evaluation, without
making any measurable improvement.
|
|
|
|
|
|
|
|
|
|
|
|
Was only used to indicate entry/exit operation of component,
which is now done explicitly. No reason to keep something which
is unused and confusing.
|
|
This isn't used too often, and haivng such API will let us to skip
specifying operation type for all oeprations.
|
|
|
|
|
|
|
|
Those were never finished nor used. Again, starting from clean
state before we go into more complicated details.
|
|
Was never used or worked on in ages, if any of this code is
needed in the future it'll need to be redone anyway.
|
|
This was never finished or done or used, no reason to keep it.
Better to simplify things before adding complexity of overrides
and copy-on-write.
|
|
It was never actually used apart from being stored at a construciton time.
This caused some redundancy and ncertanty about which relation type to use
during construciton (often existing types were not close enough to particular
use case).
|
|
The idea is to accumulate all new tasks in a thread local queue
first without doing any thread synchronization (aka, locks and
conditional variables) and move those tasks to a scheduler queue
once they are all ready. This way we avoid per-task-pool lock
and only have one lock per bunch of tasks.
This is particularly handy when scheduling new dependency graph
node children. Brings FPS of cached simulation from the linked
below file from ~30 to ~50.
See documentation for BLI_task_pool_delayed_push_{begin, end}
and for TaskThreadLocalStorage::do_delayed_push.
Fixes T50027: Rigidbody playback and simulation performance regression with new depsgraph
Thanks Bastien for the review!
|
|
This is a corresponding part of 7dda3cf.
|
|
Seems to be a copy-paste error from code above.
|
|
|
|
Those are not depsgraph or C++ specific and can be used by everyone.
|
|
This way we always have predictable behavior, especially from the
performance point of view. Additionally, if some bottleneck is found
in stack implementation it'll be easier for us to address.
|
|
This way everyone can benefit from it, not only dependency graph.
|
|
Second round of fix, was broken by 843be91.
|
|
|
|
Was preventing update in 3DView etc. when changing something in the
World's NodeTree, especially annoying in blender2.8 branch (since legacy
depsgraph has been removed there), but also affecting master.
|
|
The change was initially needed for Blender 2.8 branch but the actual
function was reverted in there. So no reason to keep dead unused
placeholder in the dependency graph.
This reverts commit fd69ba225540cde5e4c1fa651fb02df21ea0a143.
|
|
Spotted by Luca, thanks!
|
|
|
|
Need to flush layers from components back to ID node.
|
|
This area is a subject of reconsideration, so for now used simplest
way possible -- ensure depsgraph's nodes have proper layer flags
when going in and out of local mode.
|
|
The iossue was caused by 0371ef1/
|
|
Need to expand all object's dupli-groups, not only the dupli-groups
of objects directly linked to the scene.
|
|
|
|
Lower risk of forgetting to update some values here.
|
|
|
|
depsgraph
The thing i'm really starting to hate is the requirement to specify both
operation code and node type. Seems to be duplicated enums without real
need for that.
|
|
Suspended pools allows to push huge amount of initial tasks
without any threading synchronization and hence overhead.
This gives ~50% speedup of cached rigid body with file from
T50027 and seems to have no negative affect in other scenes
here.
|
|
This is something what should be done in the task scheduler instead
with local thread queues so we handle this in a single place.
|
|
This feature was adding extra complexity to task scheduling
which required yet extra variables to be worried about to be
modified in atomic manner, which resulted in following issues:
- More complex code to maintain, which increases risks of
something going wrong when we modify the code.
- Extra barriers and/or locks during task scheduling, which
causes extra threading overhead.
- Unable to use some other implementation (such as TBB) even for
the comparison tests.
Notes about other changes.
There are two places where we really had to use that limit.
One of them is the single threaded dependency graph. This will
now construct a single-threaded scheduler at evaluation time.
This shouldn't be a problem because it only happens when using
debugging command line arguments and the code simply don't
run in regular Blender operation.
The code seems a bit duplicated here across old and new
depsgraph, but think it's OK since the old depsgraph is already
gone in 2.8 branch and i don't see where else we might want
to use such a single-threaded scheduler.
When/if we'll want to do so, we can move it to a centralized
single-threaded scheduler in threads.c.
OpenGL render was a bit more tricky to port, but basically we
are using conditional variables to wait background thread to
do all the job.
|
|
|
