Commit Graph

11 Commits

Author SHA1 Message Date
40091ff83a Correction to early output in the parallel range implementation
The used heuristic of checking the value prior to lock is not totally safe
because assignment is not atomic and check might not give proper result.
2015-05-18 16:40:51 +05:00
97ae0f22cd Depsgraph debug: Remove hardcoded array of BLENDER_MAX_THREADS elements
Allocate statistics array dynamically, so increasing max number of threads does
not increase sloppyness of the memory usage.

For the further cleanups: we can try alloca-ing this array, but it's also not
really safe because we can have quite huge number of threads in the future.
Plus statistics will allocate memory for each individual entry, so using alloca
is not going to give anything beneficial here.
2015-04-13 14:41:02 +05:00
e177c51430 Use atomic operations in task pool
This ensures proper values of currently running tasks in the pool
(previously difference between mutex locks when acquiring new job
and releasing it might in theory give wrong values).
2014-12-02 15:23:58 +05:00
7b0c529fe2 Task scheduler: Add an option to limit number of threads per pool
This way we can have scheduler capable of scheduling tasks on all the CPUs
but in the same time we can limit tasks like baking (in the future) to use
no more than given number of threads.
2014-11-21 11:31:30 +01:00
e43b74d87a Optimization of parallel range
It now supports different scheduling schemas: dynamic and static.
Static one is the default and it splits work into equal number of
range iterations.

Dynamic one allocates chunks of 32 iterations which then being
dynamically send to a thread which is currently idling.

This gives slightly better performance. Still some tricks are
possible to have. For example we can use some smarter static scheduling
when one thread might steal tasks from another threads when it runs
out of work to be done.

Also removed unneeded spin lock in the mesh deform evaluation,
on the first glance it seemed to be a reduction involved here but
int fact threads are just adding value to the original vertex
coordinates. No write access to the same element of  vertexCos
happens from separate threads.
2014-11-03 22:44:29 +05:00
eaaeae4699 Cleanup: spelling 2014-10-23 10:38:38 +02:00
dfc4de036e Meshdeform modifier: Use threaded evaluation
This commit switches meshdeform modifier to use threads to evaluate
the vertices positions using the central task scheduler.

SO now we've got an utility function to help splitting the for loop
into tasks using BLI_task module which is pretty straightforward to
use: it gets range (which is an integer lower and higher bounds) and
the function and userdata to be invoked for each of the iterations.

The only weak point for now is the passing the data to the callback,
this isn't so trivial to improve in pure C.

Reviewers: campbellbarton

Differential Revision: https://developer.blender.org/D838
2014-10-22 12:20:41 +02:00
b3afbcab8f ListBase API: add utility api funcs for clearing and checking empty 2014-02-08 06:24:05 +11:00
621bf47e91 Docs: doxygen file descriptions for BLF, GPU and WM 2014-01-19 23:15:25 +11:00
48c1e0c0fc spelling: use American spelling for canceled 2013-10-26 01:06:19 +00:00
f0dcff9aa9 Task scheduler ported form CYcles to C
Replaces ThreadedWorker and is gonna to be used
for threaded object update in the future and
some more upcoming changes.

But in general, it's to be used for any task
based subsystem in Blender.

Originally written by Brecht, with some fixes
and tweaks by self.
2013-10-12 14:08:59 +00:00