Take advantage of the efficiency provided by the snap_context.
Also fixes errors:
- volume snap fails based on view angle (T48394).
- multiple instances of dupli-objects break volume calculation.
Pass distance argument so its possible to limit the range we get all hits from.
Other changes:
- Use boundbox test before calling callback, avoids redundant calls.
- Remove meaningless return value.
- Add doc string, explaining purpose of this function.
This commit makes use of new taskpool feature (instead of allocating own tasks),
and removes the spinlock used to generate chunks (using atomic ops instead).
In best cases (dynamic scheduled loop with light processing func callback), we
get a few percents of speedup, in most cases there is no sensible enhancement.
This is what old dependency graph was doing and apparently this avoids some updates,
however it's not really clear why those nodes are considering done. Maybe just because
of the way how relations are working. But needs a closer investigation.
Appears mutex was guarateeing number of tasks is not modified at moments
when it's not expected. Removing those mutexes resulted in some hard-to-catch
locks where worker thread were waiting for work by all the tasks were already
done.
This reverts commit a1d8fe052c.
Brain melt here, intention was to reduce number of tasks in case we have not much chunks of data to loop over,
not to increase it!
Note that this only affected dynamic scheduling.
It uses some additional compute power and the evaluation priority is
not even used.
This brings fps 88.2 with blenrig_for_debugging.blend on this desktop.
Simple thing, and apparently fps goes up to 80 with the demo file from jpbouza.
Not sure why at this point fps is so much higher than the old dependency graph
here now. And it's definitely something what others should verify as well.
This reduces stress on the task scheduler and avoids some unwanted overhead
caused by all the threading business in the cases when there's only one
children node. We try to immediately switch to it's evaluation now, keeping
active thread up and running.
This bumps FPS from 58 to 64 on the blenrig test file from jpbouza.
This commit implements new function BLI_task_pool_push_from_thread()
who's main goal is to have less parasitic load on the CPU bu avoiding
memory allocations as much as possible, making taks pushing cheaper.
This function expects thread ID, which must be 0 for the thread from
which pool is created from (and from which wait_work() is called) and
for other threads it mush be the ID which was sent to the thread working
function.
This reduces allocations quite a bit in the new dependency graph,
hopefully gaining some visible speedup on a fewzillion core machines
(on my own machine can only see benefit in profiler, which shows
significant reduce of time wasted in the memory allocation).
Many keyboard layouts (italian, spanish, german...) have direct access to '+' key on main
keyboard area (not the numpad one), ans x11 has own define for this key, so use it instead
of generating an unkown key event.
Note that we most likely have much more missing 'specific' keycodes for non-US keyboard layout,
but think since we already had a 'minus' keyevent, supporting 'plus' one is totally consistent.
And we had a spare space in our defined values just for it even!
This keyevent is only supported/generated by x11 and cocoa Ghost backends for now,
neither SDL nor win32 seem to have matching key events...
This commit:
* Removes most of all dirty internal details from public atomi_ops.h file, and move them into /intern private subdir.
* Removes unused 'architectures' (__apple__ and jemalloc).
* Split each implementation into its own file.
* Makes use of C99's limits.h system header to determine pointer and int size, instead of using fix hardcoded list of architectures.
* Introduces new 'faked' atomics ops for floats.
Note that we may add a lot more real and 'faked' atomic operations over integers and floats
(multiplication, division, bitshift, bitwise booleans, etc.), as needs arise.
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D1982
This was originally done for T46320 in order to re-store depsgraph state
after all the constraint modifications.
However, it relations were updated if there's any IK chain the the pose,
which is a bit too annoying.
