| Age | Commit message (Collapse) | Author |
|---|
|
tested that already without much change yesterday, but for some reasons
today it gives me another 2-3% speedup in both test files.
And it should also mitigate the (supposed) almost-starving situation,
hopefully.
|
|
Those are small enough to be worth it, and it does give me ~2% speedup here...
|
|
This reverts commit 32959917ee112200125e3e742afb528fc2196072.
Definitively gives worse performances. Looks like every overhead we add
to task management is always worse than potential better scheduling it
might give us...
|
|
Idea here is to reduce number of threads a pool is allowed to work on,
in case it does not get tasks quickly enough.
This does not seem to be really great result (have to only do the checks
once every 200 tasks pushed to avoid too much overhead), but I cannot
reproduce that nearly-starving case here so far. @sergey, curious if it
gives any difference on your 12cores with 14_03_G?
|
|
|
|
|
|
|
|
|
|
small tasks.
This is partially based on Sergey's work from D2421, but pushing the things
a bit further. Basically:
- We keep a sheduler-counter of TODO tasks, which avoids us to do any
locking (even of the spinlock) when queue is empty, in workers.
- We spin/nanosleep a bit (less than a ms) when we cannot find a task,
before going into real condition-waiting sleep.
- We keep a counter of condition-sleeping threads, and only use
condition notifications in case we know some are waiting on it.
In other words, when no tasks are available, we spend a bit of time in a
rather high-activity but very cheap and totally lock-free loop, before
going into more expansive real condition-waiting sleep.
No noticeable speedup in complex production scene (barbershop one), here
master, D2421 and this code give roughly same performances (about 30%
slower in new than in old despgraph).
But with testfile from T50027 and new depsgraph, after initial bake,
with master I have ~14fps, with D2421 ~14.5fps, and with this code ~19.5fps.
Note that in theory, we could get completely rid of condition and stay
in the nanosleep loop, but this implies some rather high 'noise' (about
3% of CPU usage here with 8 cores), and going into condition-waiting
state after a few hundreds of micro-seconds does not give any measurable
slow down for me.
Also note that this code is only working on POSIX systems (so no Windows, not
sure how to do our nanosleeps on this OS :/ ).
Reviewers: sergey
Differential Revision: https://developer.blender.org/D2426
|
|
|
|
Comments said that function was supposed to 'stop worker threads', but
it absolutely did not do anything like that, was merely wiping out TODO
queue of tasks from given pool (kind of subset of what
`BLI_task_pool_cancel()` does).
Misleading, and currently useless, we can always add it back if we need
it some day, but for now we try to simplify that area.
|
|
processed.
Freeing pool was calling `BLI_task_pool_stop()`, which only clears
pool's tasks that are in TODO queue, whithout ensuring no more tasks
from that pool are being processed in worker threads.
This could lead to use-after-free random (and seldom) crashes.
Now use instead `BLI_task_pool_cancel()`, which does waits for all tasks
being processed to finish, before returning.
|
|
|
|
|
|
range
|
|
|
|
|
|
get the same name
The paint slot name was not the same as what is displayed on the texture properties panel.
Instead, the slot type (e.g. "Diffuse Color") was used as the name.
Patch by Suchaaver (@minifigmaster125) with minor changes from @mont29.
Reviewers: mont29, sergey
Maniphest Tasks: T50704
Differential Revision: https://developer.blender.org/D2523
|
|
Can't say enough how much I hate those proxies... their duality (sharing
some aspects of both direct *and* indirect users) is a nightmare to handle. :(
|
|
Was assigning new edge index to ml_prev->e, and then assigning ml_pre->e
to orig_index...
|
|
Is already added through Transform_Properties
|
|
Issue was that the VIEW_OT_manipulator operator calls the transform
operators and passes them it's own operator properties. That means the
transform operator got properties passed that it doesn't have.
|
|
|
|
accurate transform
Now it is defined by keymap.
|
|
Was caused by property being saved by the operator manager.
|
|
The custom poll function for surfacedeform_bind seems to have caused
issues when calling it from Python. Fixed by using the generic modifier
poll function, and setting the button to be active or not in the
Python UI code instead. (there might be a better way, but for now this
works fine)
|
|
Not really happy of per-pool threads limit, need to find better
approach to that. But at least it's possible to get rid of half
of the nastyness here by removing getter which was only used in
an assert statement.
That piece of code was already well-tested and this code becomes
obsolete in the new depsgraph and does no longer exists in blender
2.8 branch.
|
|
|
|
|
|
|
|
This was only used for progress report, and it's wrong because:
- Pool might in theory be re-used by different tasks
- We should not make any decision based on scheduling stats
Proper way is to take care of progress by the task itself.
|
|
For now only prevent crash.
|
|
|
|
Implementation of the SDef modifier, which allows meshes to be bound by
surface, thus allowing things such as cloth simulation proxies.
User documentation: https://wiki.blender.org/index.php/User:Lucarood/SurfaceDeform
Reviewers: mont29, sergey
Subscribers: Severin, dfelinto, plasmasolutions, kjym3
Differential Revision: https://developer.blender.org/D2462
|
|
Thanks Bastien for help!
|
|
mesh gets modified
Do a "full" update on leaving sculpt mode, so we are sure scene will be brought
to a consistent state.
Ideally we'll only do that when there are objects which depends on geometry
without re-calculating self geometry, but that's a bit tricky currently.
|
|
|
|
|
|
|
|
the `dm->release(dm)`
|
|
- remove unused struct member.
- misleading variable name.
|
|
|
|
|
|
|
|
|
|
|
|
instead of to the object itself.
|
|
Can't see any reason to call AUD exit early in WM_exit, that's a
low-level module that has no dependency on anything else in Blender, but
is dependency of some other parts of Blender, so it should rather be
exited late in the process!
|
|
This adds an option to force fields of type "Force", which enables the
simulation of gravitational behavior (dist^-2 falloff).
Patch by @AndreasE
Reviewers: #physics, LucaRood, mont29
Reviewed By: #physics, LucaRood, mont29
Tags: #physics
Differential Revision: https://developer.blender.org/D2389
|
|
|
