T76602 reported a crash with the exception address being 0,
this stack naturally could not be walked and no backtrace was
reported for the main thread. Which would have been helpful.
This change modifies the behaviour of the crash handler to ignore
the context record if it contains no useful information and
walk the current stack to get some information about what lead
to the crash.
Background task pools would not restart threads if reused multiple times,
thanks to Jeroen for identifying the cause of this problem.
Differential Revision: https://developer.blender.org/D7659
Surrounding includes with an 'extern "C"' block is not necessary anymore.
Also that made it harder to add any C++ code to some headers, or include headers
that have "optional" C++ code like `MEM_guardedalloc.h`.
I tested compilation on linux and windows (and got help from @LazyDodo).
If this still breaks compilation due to some linker error, the header containing
the symbol in question is probably missing an 'extern "C"' block.
Differential Revision: https://developer.blender.org/D7653
When writing out the module information in a crashdump
we did not include what symbol file was loaded and if
that symbol file actually matches our executable.
Given the backtraces may contain invalid information
if the symbols are unmatched this is relevant to know.
This diff adds the symbol file and an indication if
unmatched symbols are used.
To detect if private of public symbols were loaded we were relying
on a strcmp with a known filename, which was not great, the symbol
api has a field we can query which should be more flexible and
reliable.
With the recent backtrace overhaul, the fact that BLI_assert calls
BLI_system_backtrace slipped somehow trough the cracks, causing
issues for debug builds.
This change allows BLI_system_backtrace to run again without having
an exception record.
Also minor improvements to the comments.
A few tiny functions were not inlined even in some release
configurations. Added BLI_INLINE as extra compiler hint in
places that the profiler showed at hot spots when populating
geometry with hair.
Using BLI calls in this file triggered a condition where
poorly modelled dependencies in cmake (ie bf_blenlib using
zlib headers but not linking the libraries) leading to
linker error in debug builds of some of the tests.
This diff sidesteps the dependencies issue by using native
calls rather than BLI calls to check if a file exists and
what its size is. Effectively sweeping the issue right back
under the rug where I found it.
The best solution would be to audit all libraries and ensure
they have proper link requirements set, but that requires
significantly more time than I have available right now.
(zlib in blenlib was one of them and would have been easy
to fix, but there were others that required more work)
The alternative is tests that fail to build which worse.
I'll revisit this and fix it properly but for now this will
have to do.
This diff add supports for crash logs on windows for
release builds. This can be toggled on/off with the
`WITH_WINDOWS_PDB` cmake option. by default it is on.
Things to take into consideration:
Release builds are hightly optimized and the resulting
backtraces can be wrong/misleading, take the backtrace
as a general area where the problem resides rather than
an exact location.
By default we ship a minimized symbol file that can only
resolve the function names. This was chosen to strike
a balance between growth in size of the download vs
functionality gained. If more detailed information is
required such as source file + line number information
a full pdb can be shipped by setting `WITH_WINDOWS_STRIPPED_PDB`
to off.
Differential Revision: https://developer.blender.org/D7520
Reviewed by: brecht
This diff add supports for crash logs on windows for
release builds. This can be toggled on/off with the
`WITH_WINDOWS_PDB` cmake option. by default it is on.
Things to take into consideration:
Release builds are hightly optimized and the resulting
backtraces can be wrong/misleading, take the backtrace
as a general area where the problem resides rather than
an exact location.
By default we ship a minimized symbol file that can only
resolve the function names. This was chosen to strike
a balance between growth in size of the download vs
functionality gained. If more detailed information is
required such as source file + line number information
a full pdb can be shipped by setting `WITH_WINDOWS_STRIPPED_PDB`
to off.
The Release in the title of this diff refers to the
release build type, not the official blender releases.
Initially this will only be enabled for nightly build
bot versions of blender, official releases as of now
will not ship with symbols.
Differential Revision: https://developer.blender.org/D7520
Reviewed by: brecht
This patch enables TBB as the default task scheduler. TBB stands for Threading Building Blocks and is developed by Intel. The library contains several threading patters. This patch maps blenders BLI_task_* function to their counterpart. After this patch we can add more patterns. A promising one is TBB:graph that can be used for depsgraph, draw manager and compositor.
Performance changes depends on the actual hardware. It was tested on different hardwares from laptops to workstations and we didn't detected any downgrade of the performance.
* Linux Xeon E5-2699 v4 got FPS boost from 12 to 17 using Spring's 04_010_A.anim.blend.
* AMD Ryzen Threadripper 2990WX 32-Core Animation playback goes from 9.5-10.5 FPS to 13.0-14.0 FPS on Agent 327 , 10_03_B.anim.blend.
Reviewed By: brecht, sergey
Differential Revision: https://developer.blender.org/D7475
* Rename template parameter N to InlineBufferCapacity
* Expose InlineBufferCapacity parameter for Set and Map
* Add some comments
* Fixed an error that I introduced recently
This is not currently used and will take some work to support with TBB, so
remove it until we have a new implementation based on TBB.
Fixes T76005, parallel range pool tests failing.
Ref D7475
Instead of building on top of `BLI::Vector`, just use a raw array
and handle the growing in `BLI::VectorSet`.
After this change, the existing `EdgeSet` can be reimplemented using
`BLI::VectorSet` without performance regressions.
This adds a simple timer that can be used for performance measurements in C++.
More sophisticated timers are possible (e.g. one that takes averages, logs the results, ...).
However, I found that this simple timer is good enough for 99% of my use cases.
To use it just write `SCOPED_TIMER("my timer name");` or more commonly `SCOPED_TIMER(__func__);`
into some scope.
Reviewers: sergey
Differential Revision: https://developer.blender.org/D7491
