| Age | Commit message (Collapse) | Author |
|---|
|
- Use BLI_threadpool_ prefix for (deprecated)
thread/listbase API.
- Use BLI_thread as prefix for other functions.
See P614 to apply instead of manually resolving conflicts.
|
|
- When returning the number of items in a collection use BLI_*_len()
- Keep _size() for size in bytes.
- Keep _count() for data structures that don't store length
(hint this isn't a simple getter).
See P611 to apply instead of manually resolving conflicts.
|
|
See https://wiki.blender.org/index.php/Dev:Doc/Code_Style#Braces_with_Macros
|
|
This is kind of doesn't matter where macro itself is defined.
We should stick to the following:
- If some macro is actually more an inline function, follow regular
function name conventions.
- If macro is a macro, type it in capitals. Use module prefix if that
helps readability or it if helps avoiding accidents.
|
|
result in the point
This isn't supported since there are subsequent reads to all point coordinates
after modification started.
Probably we need to create a temp copy of point, but that's like extra CPU
ticks.
|
|
|
|
These are used for randomization, so it's convenient if the index is already
hashed and consistent with the Object Info node.
|
|
|
|
Previously quads always split along first-third vertices.
This is still the default, to avoid flickering with animated deformation
however concave quads that would create two opposing triangles now use
second-fourth split.
Reported as T53999 although this issue has been known limitation
for a long time.
|
|
bli_fileops.h was using uint64_t without including the proper header.
issue triggered by rBb0af44fa4d7a2e134b315c49a4fbdf573f781004
|
|
Consistent with other BLI API's
|
|
Error: math_base_inline.c(402): error C2668: 'log10' : ambiguous call to
overloaded function
|
|
It's harder to reason about array access with negative indices.
|
|
|
|
|
|
|
|
LinkList's are a different API, no need to confuse things.
|
|
|
|
Improve hashsizes comment too.
|
|
|
|
Those pointers are never to be aliased, so let's be explicit about this and hope
compiler does save some CPU ticks.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This seems to only cause extra rthreading overhead on systems with 10s of
threads, without actually solving anything.
|
|
The idea is to support following: allow doing parallel for on a small range,
each iteration of which takes lots of compute power, but limit such range to
a subset of threads.
For example, on a machine with 44 threads we can occupy 4 threads to handle
range of 64 elements, 16 elements per thread, where each block of 16 elements
is very complex to compute.
The idea should be to use this setting instead of global use_threading flag,
which is only based on size of array. Proper use of the new flag will improve
threadability.
This commit only contains internal task scheduler changes, this setting is not
used yet by any areas.
|
|
Basically, split it up and avoid extra abstraction level.
|
|
Now all the fine-tuning is happening using parallel range settings structure,
which avoid passing long lists of arguments, allows extend fine-tuning further,
avoid having lots of various functions which basically does the same thing.
|
|
Wrap all arguments into TLS type of argument. Avoids some branching and also
makes it easier to extend things in the future.
|
|
|
|
The idea is to avoid any threading overhead when we start pushing tasks in a
loop. Similarly to how we do it from the new dependency graph. Gives couple of
percent of speedup here, but also improves scalability.
|
|
The last compiler version needs this include
|
|
There was no simple way to get the shortest quaternion angle.
|
|
|
|
|
|
|
|
|
|
|
|
Also some re-indenting.
|
|
D2860 by @miqlas
Even though Haiku is a niche OS, only minor changes are needed.
|
|
For some blend modes there would be no effect with factor 1.0, even if factor
0.999 would give a very different image. Now the result should have no
discontinuity.
Differential Revision: https://developer.blender.org/D2925
|
|
|
|
It merely uses the new thread-safe iterators system of mempool, quite
straight forward.
Note that to avoid possible confusion with two void pointers as
parameters of the callback, a dummy opaque struct pointer is used
instead for the second parameter (pointer generated by iteration over
mempool), callback functions must explicitely convert it to expected
real type.
Also added a basic gtest for this new feature.
|
|
This will allow threaded tasks to 'consume' all mempool items in
parallel tasks, each one working on a whole chunk at once (to reduce
concurrency managing overhead).
|
|
Adapted from http://www.pixelbeat.org/programming/gcc/static_assert.html.
Note that this macro just discards error message, so error when building
is much less nice than with gcc's _Static_assert... But error log will
point to right place in code, so should still be OK.
|
|
|
|
This reverts commit d749320e3b10161430bc4cb7dd92edb63712bf8c.
It's possible the container struct is larger,
we could do sizeof checks that falls back to memmove
but rather avoid complicating things.
|
