| Age | Commit message (Collapse) | Author |
|---|
|
This new function is part of the 'parallel for loops' functions. It
takes an iterator callback to generate items to be processed, in
addition to the usual 'process' func callback.
This allows to use common code from BLI_task for a wide range of custom
iteratiors, whithout having to re-invent the wheel of the whole tasks &
data chuncks handling.
This supports all settings features from `BLI_task_parallel_range()`,
including dynamic and static (if total number of items is knwon)
scheduling, TLS data and its finalize callback, etc.
One question here is whether we should provide usercode with a spinlock
by default, or enforce it to always handle its own sync mechanism.
I kept it, since imho it will be needed very often, and generating one
is pretty cheap even if unused...
----------
Additionaly, this commit converts (currently unused)
`BLI_task_parallel_listbase()` to use that generic code. This was done
mostly as proof of concept, but performance-wise it shows some
interesting data, roughly:
- Very light processing (that should not be threaded anyway) is several
times slower, which is expected due to more overhead in loop management
code.
- Heavier processing can be up to 10% quicker (probably thanks to the
switch from dynamic to static scheduling, which reduces a lot locking
to fill-in the per-tasks chunks of data). Similar speed-up in
non-threaded case comes as a surprise though, not sure what can
explain that.
While this conversion is not really needed, imho we should keep it
(instead of existing code for that function), it's easier to have
complex handling logic in as few places as possible, for maintaining and
for improving it.
Note: That work was initially done to allow for D5372 to be possible... Unfortunately that one proved to be not better than orig code on performances point of view.
Reviewed By: sergey
Differential Revision: https://developer.blender.org/D5371
|
|
|
|
|
|
* Add proper adjustment for scale in the solver epsilon computation.
* Run at least one full iteration of the solver, even if the initial
state meets the epsilon requirement.
* When applying offset, blend normal into the offset direction
as the initial point moves very close to the target mesh.
Also random improvements to debug trace output in the console.
|
|
|
|
|
|
|
|
|
|
In Blender 2.7 delete would permanently delete files, now this function is back
but using more standard behavior.
This patch includes code contributed by Kris (Metricity).
Differential Revision: https://developer.blender.org/D4585
|
|
|
|
Wasn't checking for repeated vertices.
Also, made choices of edges to keep more aesthetically pleasing.
|
|
Some scripts will need to be updated to support this.
|
|
clang got a little to aggressive discarding unused variables
see D6012 for details.
Differential Revision: https://developer.blender.org/D6012
Reviewers: brecht, sergey, angavrilov
|
|
|
|
|
|
|
|
|
|
|
|
This reverts commit 9d282d7a8d689a17ae58e94453ae99a41e91b701.
os_unfair_lock requires macOS 10.12 or newer.
|
|
Call SetErrorMode() at startup to prevent error mode dialogs.
Differential Revision: https://developer.blender.org/D5941
Reviewed by Brecht Van Lommel
|
|
|
|
NDEBUG is the standard define, not DEBUG.
|
|
|
|
That code is simpler and more general (not limited to some specific
values of thread numbers). It still gives similar default chunk size as
what we had before, but handles smoother increase steps, and higher
number of threads, by keeping increasing the chunk size.
No functional change expected from that commit.
|
|
Reviewers: brecht
Differential Revision: D4997
|
|
OSSplinLock is a deprecated API, os_unfair_lock is its successor.
This reduces the number of warnings when building on macOS.
|
|
Picked up while investigating a build error on the functions branch
which seems to use this specific header in a way master doesn't.
The problem:
The MSVC headers define a `_CONCAT` macro, so does BLI_kdtree_imp.h
however at the end `BLI_kdtree_imp.h` undefines the macro making the
MS headers that still rely on it "unhappy".
Who's fault is this:
Ours, C99 Spec says
```
7.1.3 Reserved identifiers
- All identifiers that begin with an underscore and either an uppercase letter or another underscore are always reserved for any use.
...
if the program removes (with #undef) any macro definition of an identifier in the first
group listed above, the behavior is undefined.
```
So we should not have defined it, and we definitely should not
have undefined it.
We have *tons* of these violations, although fixing them would be great
at one point lots of them are in /extern or in the 3rd party deps,
I'd rather deal with them on a case by case basis when it actually
causes issues.
Differential Revision: https://developer.blender.org/D5790
Reviewers: campbellbarton, JacquesLucke
|
|
The function now allows custom return types defined
by the callbacks. This can be useful when a user of the
data structure has to implement some custom behavior.
|
|
|
|
|
|
With this the values could have been changed without
updating the hash table.
|
|
|
|
The structure is a set built on top of a vector and not the other
way around.
|
|
This makes it possible to use e.g. `std::unique_ptr` in a map.
|
|
|
|
This reverts commit ce34a6b0d727bbde6ae373afa8ec6c42bc8980ce.
|
|
Reviewers: brecht
Differential Revision: D4997
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This commit adds some new hashing based data structures to blenlib.
All of them use open addressing with probing currently.
Furthermore, they support small object optimization, but it is not
customizable yet. I'll add support for this when necessary.
The following main data structures are included:
**Set**
A collection of values, where every value must exist at most once.
This is similar to a Python `set`.
**SetVector**
A combination of a Set and a Vector. It supports fast search for
elements and maintains insertion order when there are no deletes.
All elements are stored in a continuous array. So they can be
iterated over using a normal `ArrayRef`.
**Map**
A set of key-value-pairs, where every key must exist at most once.
This is similar to a Python `dict`.
**StringMap**
A special map for the case when the keys are strings. This case is
fairly common and allows for some optimizations. Most importantly,
many unnecessary allocations can be avoided by storing strings in
a single buffer. Furthermore, the interface of this class uses
`StringRef` to avoid unnecessary conversions.
This commit is a continuation of rB369d5e8ad2bb7.
|
|
|
|
|
|
Along with the new utility `BM_vert_weld_linked_wire_edges_into_linked_faces`
|
|
|
|
|
|
These two data structures reference strings somewhere in memory.
They do not own the referenced string. The string is considered
const.
A string referenced by StringRefNull can be expected to be
null-terminated. That is not the case for StringRef.
This commit is a continuation of rB369d5e8ad2bb7c2.
|
