Blender Git Commit Log

Cycles: Remove early out that may cause threads to diverge before barrier

Cycles: Matched motion interpolation to Embree's interpolation

When Embree is turned on, the transform matrices of motion steps are now interpolated linearly (the wrong way). Cycles itself has a better way of interpolating, but when mixing it with Embree's direct matrix interpolation, it results in artefacts.

Cycles: Fixed Embree Volume rendering when the camera is inside a volume

Cycles: Fixed a crash when setting up Embree hair curves

Cycles: Code style cleanup

Cycles: Fixed wrong Embree line intersections

Line segments should not go through the backfacing test.

Cycles: Set the compact flag on Embree to save memory

Cycles: removed use of constexpr to stay compatible with pre-C++11 compilers

Cycles: Extended Embree integration

Implemented ribbon curves and thick curves for hair.
Embree now obeys the static/dynamic BVH setting.

Merge branch 'master' into blender2.8

Conflicts:
source/blender/editors/mask/mask_draw.c

Cleanup: ImageEditor's mask drawing code was re-implementing `BKE_maskrasterize_buffer`!

So this deduplicates and simplifies code, yeah.

Also, as an odd bonus, new code seems slighly quicker than previous one
(about 5 to 10% quicker).

Removing OMP: BKE's mask_rasterize.c

Once again nothing much to say here, except that whole mask rendering
process from VSE is about 25% quicker now. ;)

Removing OMP: autotrack BKE code.

Pretty straightforward this time, we already have a single struct
pointer containing all needed data (or nearly).

And we gain about 10-15% speed on tracking! :)

updated caching (now using frame 1 for liquids as well) and also added new snd particle parameters

Removing OMP: bmesh_operators.c

Two more 'not really useful' cases (OMP only shows some noticeable
speedup with above 1M elements, and since this is quick operation anyway
compared to even ather basic operators, gain is in the 1% area of total
processing time in best case).

So not worth parallelizing here, we'll gain much more on tackling heavy
operations. ;)

And BMesh is free from OMP now!

Removing OMP: bmesh_interp.c

Performances tests on this one are quite surprising actually...
Parallelized loop itself is at least 10 times quicker with new BLI_task
code than it was with OMP. And subdividing e.g. a heavy mesh with 3
levels of multires (whole process) takes 8 seconds with new code, while
10 seconds with OMP one. And cherry on top, BLI_task code only uses
about 50% of CPU load, while OMP one was at nearly 100%!

In fact, I suspect OMP code was not properly declaring outside vars,
generating a lot of uneeded locks.

Also, raised the minimum level of subdiv to enable parallelization,
tests here showed that we only start to get significant gain with subdiv
levels of 4, below single threaded one is quicker.

Removing OMP: nuke last usages in bmesh_mesh.c

Those three ones were actually giving no significant benefits, in fact
even slowing things down in one case compared to no parallelization at
all (in `BM_mesh_elem_table_ensure()`).

Point being, once more, parallelizing *very* small tasks (like index or
flag setting, etc.) is nearly never worth it.

Also note that we could not easlily use per-item parallel looping in
those three cases, since they are heavily relying on valid
loop-generated index (or are doing non-threadable things like allocation
from a mempool)...

Fix T53349: AO bounces not working correct with OpenCL.

Cycles: Fixed parametric coordinates for hair intersections with Embree

Cycles: Added runtime checks for Embree build. If Embree is not configured correctly, it will print warnings to the console.