Code around draw objects became safe for threading
and no special workaround is needed in scene update
anymore.
Unused buffers will be freed next time window is
drawing. Some further tweaks maybe needed to how
buffers are freeing, but things shall work for now
nice and stable.
This commit adds per-thread statics for object
update threads which would give you information
about:
- How much objects each thread handled
- How much overall time thread spend on running
object_handle_update.
- How long each of object_handle_update took.
Enabled by ./blender -d
The code is surrounded by ifdef, so shall be
not a problem to drop the code when we don't
need it anymore.
Also added special value for rt (debug_value)
of 13666 which switches scene update to a
single thread. Useful for benchmarking.
This new macros could be used to benchmark overall
execution time of some chunk of code, running in cycle.
The usage is:
void foo(void) {
TIMEIT_BLOCK_INIT(overall_bar);
for (...) {
...
TIMEIT_BLOCK_BEGIN(over_bar);
bar();
TIMEIT_BLOCK_END(oberall_bar);
...
}
TIMEIT_BLOCK_STATS(overall_bar)
}
This would print total time which was spent on
running function bar().
Apparently, some routines in armature deformation code
were using static arrays. This is probably just an
optimization thing, but it's very bad for threading.
Now made it so bbone matrices array is allocating in
callee function stack. This required exposing
MAX_BBONE_SUBDIV to an external API, This is not so
much crappy from code side, and it shall be the same
fast as before.
Lattice deformation used to store some runtime data
inside of lattice datablock itself. It's something
which is REALLY bad. Ideally DNA shouldn't contain
and runtime data.
For now solved it in a way that initialization of
lattice deform will create a structure which contains
lattice object for which deformation is calculating
and that runtime data which used to be stored in
lattice datablock itself.
It works really fine for mesh deform modifier, but
there's still runtime data stored in particle system
DNA, It didn't look something easy to be solved, so
leaving this as-is for now.
Code in GPU_buffers_free was already trying to be safe
for threading, by skipping OGL calls there, but in fact
it was still buggy.
Namely, freeing was doing buffers shift in a cycle, and
if two threads will call this function shifting will go
crazy.
Now made it so GPU_buffers_alloc and GPU_buffers_free
are using mutex lock, so they're completely safe for
threading. Same goes to gpu_buffer_setup function.
It required minor functions reshuffle, so there're no
locks happening from locked thread, but it's all very
straightforward change.
This was in fact really nasty bug, caused by multitex_nodes
function using global variable R (which is a copy of current
renderer). this variable is not initialized to anything
meaningful for until first rendering (preview or final)
happened.
Since multitex_nodes might be used outside of render pipeline,
made it so whether CM is on or off as an argument to functions
multitex_ext_safe and multitex_ext. Now multitex_nodes() is
only shall be used for stuff happening from render pipeline!
Also needed to make some changes to other places, so all the
usages of texture sampling knows for the fact whether CM is
on or off.
And one more change is related on behavior of dispalcement,
wave, warp, weightvg modifiers and smoke. They'll be always
using CM off since texture is used for influence, not for
color.
It's rather bigger patch, but it's mostly straightforward
changes, which we really need to be done.
Reviewed by Brecht, thanks!
the UI on OS X.
The problem is due to a large variable on the stack, and pthreads have a smaller
stack size than the main thread by default. On Linux the pthread stack size seems
to be 2MB, OS X 512KB and Windows 256KB - 512KB.
Issue was caused by operator redo saving values for previous
inverted channels, meaning the same channels will be inverted
next time operator runs.
Don't think it's useful to save operator values here, since
you don;t have visual feedback about which channels were
inverted. So marked all this properties as SKIP_SAVE. Gives
much more predictable results.
- BLI_strncpy_wchar_from_utf8 wasn't NULL terminating the destination string, caused uninitialized memory use in BPY_python_start().
- BLI_strncpy_wchar_as_utf8 could write one byte past the buffer bounds.
