Blender Git Loki

Commit atomic operations file

Not currently used, but needed for some further changes

Use reentrant qsort() in particle codes

Particle system code used global variable to sort hair by orig index,
which is not safe for threading at all.

Replaced this with usage of reentrant version of qsort, which is
now implemented in BLI. It was moved from recast navigation code
to BLI, so more areas could use it (if needed).

--
svn merge -r59086:59087 ^/branches/soc-2013-depsgraph_mt

Added check for whether thread lock is being removed while thread is using guarded alloc.

--
svn merge -r58788:58789 ^/branches/soc-2013-depsgraph_mt

Optimization and threading fix for shapekeys weights calculation

This commit fixes two different issues, which were caused by
how weights are being calculated for relative shapekeys.

Weights for key block used to saved in KeyBlock DNA structure,
which lead to situations when different objects could start
writing to the same weights array if they're sharing the same
key datablock.

Solved this in a way so weights are never stored in KeyBlock
and being passed to shapekeys routines as an array of pointers.
This way weights are still computed run-time (meaning they're
calculated before shapekey evaluation and freed afterwards).

This required some changes to GameEngine as well, to make it
never cache weights in the key blocks.

Another aspect of this commit makes it so weight for a given
vertex group is only computed once. So if multiple key blocks
are using the same influence vertex group, they'll share the
same exact weights array. This gave around 1.7x speedup in
test chinchilla file which is close enough to if we've been
caching weights permanently in DNA (test machine is dual-code
4 threads laptop, speedup measured in depsgraph_mt branch,
trunk might be not so much high speedup).

Some further speed is optimization possible, but it could be
done later as well.

Thanks Brecht for idea of how the things might be solved in
really clear way.

--
svn merge -r58786:58787 ^/branches/soc-2013-depsgraph_mt

Added check for address being freed by mempool free

When blender is built in debug mode, BLI_mempool_free will
ensure address passed to the function actually belongs to
this pool.

--
svn merge -r58710:58711 ^/branches/soc-2013-depsgraph_mt

Utility benchmarking macros

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().

--
svn merge -r58281:58283 ^/branches/soc-2013-depsgraph_mt

Made armatures evaluation safe for threading

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.

--
svn merge -r58278:58279 ^/branches/soc-2013-depsgraph_mt

Make lattice deform safe for threading

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.

--
svn merge -r58277:58278 -r58795:58796 ^/branches/soc-2013-depsgraph_mt

Make GPU buffers allocation/freeing safe for threading

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

--
svn merge -r58276:58277 ^/branches/soc-2013-depsgraph_mt

Make fonts safe(r) for threading

Getting vfont data wasn't safe for threading, because it
was modifying font data which is in bmain and could be
shared by multiple objects.

For now made it so getting vfont uses critical section,
meaning vfont->data is initializing from inside a locked
mutex.

--
svn merge -r58168:58169 ^/branches/soc-2013-depsgraph_mt

fix [#36481] When "Rip Edge" cannot be completed, Blender crashes weirdly

Tag object-data level boundbox as invalid rather than freeing it

Object update used to free object-data level bounding box to trigger
it's re-calculation in the future. Such a freeing performed from
object update isn't thread-safe because mesh could be shared between
multiple objects.

Rather than freeing bounding box, tag it's as invalid, this is safe
from threading point of view and also prevents unnecessary memory
re-allocation.

Object-level bounding box is still reallocating, but think we could
change this easily in the future as well.

--
svn merge -r58154:58156 -r59258:59259 ^/branches/soc-2013-depsgraph_mt

Remove unused bounding box from MetaBall

--
svn merge -r58150:58151 ^/branches/soc-2013-depsgraph_mt

Made curves almost thread-safe

Now modifier stack wouldn't modify original curve's nurbs
and will operate on a copy of nurbs.

This makes it possible to process curve object update with
shared curve datablocks from multiple threads. There's no
big overhead for creating a copy of nurbs comparing to old
behavior which was allocating original vertex array and
apply coordinates on curve after all modifier are applied.

The only remained issue with curves is curve's bounding box
and texture space. It's not thread-safe, but it wouldn't
lead to crashes -- it just could lead to either memory
leak or wrong texture coordinates due to difference in
modifiers stacks of objects which shares the same curve.

--
svn merge -r57959:57961 ^/branches/soc-2013-depsgraph_mt

Remove unused argument from utility curve functions

So far it was harmless, but with upcoming changes having this
argument could be confusing from logic point of view

--
svn merge -r57958:57959 ^/branches/soc-2013-depsgraph_mt

Move bevel list and path from Curve to Object datablock

I know this is not so much nice to have this guys hanging
around in a general Object datablock and ideally they better
be wrapped around into a structure like DerivedMesh or
something like this. But this is pure runtime only stuff and
we could re-wrap them around later.

Main purpose of this is making curves more thread safe,
so no separate threads will ever start freeing the same path
or the same bevel list.

It also makes sense because path and bevel shall include
deformation coming from modifiers which are applying on
pre-tesselation point and different objects could have
different set of modifiers. This used to be really confusing
in the past and now data which depends on object is stored
in an object, making things clear for understanding even.

This doesn't make curve code fully thread-safe due to
pre-tesselation modifiers still modifies actual nurbs and
lock is still needed in makeDispListsCurveTypes, but this
change makes usage of paths safe for threading.

Once modifiers will stop modifying actual nurbs, curves
will be fully safe for threading.

Actually, this commit also contains wrapping runtime curve
members into own structure

This allows easier assignment on file loading, keeps curve-
specific runtime data grouped and saves couple of bytes in
Object for non-curve types.

--
svn merge -r57938:57939 ^/branches/soc-2013-depsgraph_mt
svn merge -r57957:57958^/branches/soc-2013-depsgraph_mt

Get rid of a display list stored in Curve datablock

This display list was only used for texture space calculation,
and even there this display list was only used for bounding
box calculation.

Since we already do have bounding box in a curve datablock
there's no reason to duplicate non-modified display list
just to calculate bounding box later, let's just calculate
bounding box at the first point.

This makes code a little be more thread-safe but curves are
still not safe for threads at all because of bevel list and
path. That would be solved later.

--
svn merge -r57939:57940 ^/branches/soc-2013-depsgraph_mt

Always use ob->bb when drawing the curve types

It used to be a check for ob->bb ? ob->bb : cu->bb but
in fact it doesn't make sense and only makes code more
crappy.

Making displist for mballs and curves/surfaces/fonts
already ensures object has walid bounding box.

--
svn merge -r57938:57939 ^/branches/soc-2013-depsgraph_mt

Made modifiers_getVirtualModifierList safe for threading

Move static variables to context filling in by this fcuntion
and owned by a callee function. This ensures no conflicts
between threads happens because of static variables used in
this function.

Also moved modifier types and virtual modifiers data to a
function called from creator. This is needed to be sure all
the information is properly initialied to the time when
threads starts to use this data.

--
svn merge -r57899:57900 ^/branches/soc-2013-depsgraph_mt

Fix issue with EWA filtering in compositor which disabled alpha

It was caused by wrong copy-paste thing, which replaced check
"whether alpha channel is enabled" with "whether alpha channel
is not zero" (which is always zero in accumulator).

Compositor always works with RGBA, so no need to do any special
checks here.

TODO: Maybe MapUV ode shall ignore alpha channel?