Age | Commit message (Collapse) | Author |
|
After looking into task isolation issues with Sergey, we couldn't find the
reason behind the deadlocks that we are getting in T87938 and a Sprite Fright
file involving motion blur renders.
There is no apparent place where we adding or waiting on tasks in a task group
from different isolation regions, which is what is known to cause problems. Yet
it still hangs. Either we do not understand some limitation of TBB isolation,
or there is a bug in TBB, but we could not figure it out.
Instead the idea is to use isolation only where we know we need it: when
holding a mutex lock and then doing some multithreaded operation within that
locked region. Three places where we do this now:
* Generated images
* Cached BVH tree building
* OpenVDB lazy grid loading
Compared to the more automatic approach previously used, there is the downside
that it is easy to miss places where we need isolation. Yet doing it more
automatically is also causing unexpected issue and bugs that we found no
solution for, so this seems better.
Patch implemented by Sergey and me.
Differential Revision: https://developer.blender.org/D11603
|
|
This patch allows Windows users to specify that their current blender
installation should be used to create thumbnails and be associated
with ".blend" files. This is done from Preferences / System. The only
way to do this currently is from the command-line and this is sometimes
inconvenient.
Differential Revision: https://developer.blender.org/D10887
Reviewed by Brecht Van Lommel
|
|
The warning would appear when using the `ENUM_OPERATORS()` macro inside
of an `extern "C"` block.
Didn't cause a warning in master currently, but in the
`asset-browser-poselib` branch.
After macro expansion, there would be C++ code in code with C linkage
(`extern "C"`). So make sure the expanded C++ code always uses C++
linkage.
The syntax used is totally C++ compliant: the C++ standard requires that
in such nested linkage specifications, the innermost one determines the
linking language (e.g. see
https://timsong-cpp.github.io/cppwp/n4659/dcl.link#4).
|
|
|
|
Better to avoid explicit vectors components direct manipulation when a
generic operation for whole vector exists, if nothing else it avoids
potential mistakes in indices.
|
|
Those were caused by various tools used on degenerate geometry, see
T79775.
Note that fixes are as low-level as possible, to ensure they cover as
much as possible of unreported issues too.
We still probably have many more of those hidden in BLI_math though.
|
|
Until OneDrive supports macOS's native placeholder file implementation, detect
the com.microsoft.OneDrive.RecallOnOpen extended file attribute.
Differential Revision: https://developer.blender.org/D11466
|
|
These were limited to obvious cases. Some less obvious cases
were kept as refactoring might make them necessary in future.
|
|
|
|
Even though this function is alredy using system-specific code, it's
still cleaner to use `SEP` and `ALTSEP` here.
|
|
Splitting out thread safe iteration logic means regular iteration
isn't checking for the thread-safe pointer each step.
This gives a small but measurable overall performance gain of 2-3%
when redrawing a high-poly mesh.
Ref D11564
Reviewed By: mont29
|
|
This change was prompted by D6408 which moves thumbnail extraction into
a shared function that happens use these endian defines but only links
blenlib.
There is no need for these defines to be associated with globals
so move into their own header.
|
|
|
|
|
|
|
|
Error in 14f3b2cdad2d7b00ce3ea27bf8eb0087ac2a6cbd.
|
|
Support thread local storage for BLI_task_parallel_mempool,
as well as support for the reduce and free callbacks.
mempool_iter_threadsafe_* functions have been moved into a private
header thats only shared between task_iterator.c and BLI_mempool.c
so the TLS can be made part of the iterator array without having to
rely on passing in struct offsets.
Add test task.MempoolIterTLS that ensures reduce and free
are working as expected.
Reviewed By: mont29
Ref D11548
|
|
A single threaded task with thread data over 8192 bytes would leak.
While this didn't happen in practice, it could cause issues in the
future.
The free call for `task_parallel_iterator_do` wasn't running
if callbacks weren't set, also not an issue in practice but avoids
potential problems in the future too.
|
|
|
|
Under some circumstances using task isolation can cause deadlocks.
Previously, our task pool implementation would run all tasks in an
isolated region. Now using task isolation is optional and can be
turned on/off for individual task pools.
Task pools that spawn new tasks recursively should never enable
task isolation. There is a new check that finds these cases at runtime.
Right now this check is disabled, so that this commit is a pure refactor.
It will be enabled in an upcoming commit.
This fixes T88598.
Differential Revision: https://developer.blender.org/D11415
|
|
|
|
Use bounding box tests quickly tell that two components cannot
have a containment relation between each other. This change
cut about 0.6s off a test with 25 big icospheres.
|
|
|
|
Also remove reference to function that never existed for adding `bNode`.
|
|
|
|
This patch is from erik85, who says:
This patch makes populate_plane inside polymesh_from_trimesh_with_dissolve run in parallel.
On a test file with a boolean between two subdivided cubes (~6 million verts) this gives a 10% speed increase (49.5s to 45s) on my 6 core CPU.
Also there is an optimization of other_tri_if_manifold to skip the contains-call and get the pointer directly.
This reduces CPU time for find_patches from 5s to 2.2s on the same test file.
|
|
When there are many components (separate pieces of connected mesh),
a part of the algorithm to determine component containment was slow.
Using a float version of finding the nearest point on a triangle
as a prefilter sped this up enormously. A case of 25 icospheres
subdivided twice goes 11 seconds faster on my Macbook pro with this
change.
|
|
This corrects an outdated comment in the vector header and a typo
in the index mask header.
|
|
This is from patch D11432 from Erik Abrahamsson. He found that
in some mpq3 functions called frequently from loops, passing in
buffers for termporary mpq3 values can save substantial time.
On my machine, his example in that patch went from 9.48s to 7.50s
for the boolean part of the calculation. On his machine, a running
time went from 17s to 10.3s.
|
|
The fseek() function on Windows only accepts a 32-bit long offset
argument. Because of this we have our own version, BLI_fseek(), which
will use 64-bit _fseeki64() on Windows. This patch just replaces some
fseek() calls with BLI_fseek().
Differential Revision: https://developer.blender.org/D11430
Reviewed by Brecht Van Lommel
|
|
This patch from Erik Abrahamsson uses a parallel_for to speed up
the case where the input is not manifold and the "hole_tolerant"
option is set.
In a test case on a 24 core (48 thread) machine, this sped up a
the boolean part on an object with 221k triangles from 12.06s to 0.46s.
|
|
Event though in practice this wasn't causing problems as the fixed size
buffers are generally large enough not to truncate text.
Using the result from `snprint` or `BLI_snprintf` to step over a fixed
size buffer allows for buffer overruns as the returned value is the size
needed to copy the entire string, not the number of bytes copied.
Building strings using this convention with multiple calls:
ofs += BLI_snprintf(str + ofs, str_len_max - ofs);
.. caused the size argument to become negative,
wrapping it to a large value when cast to the unsigned argument.
|
|
|
|
This patch fixes a long-standing complaint from users:
the console window shortly flashing when they start
blender.
This is done by adding a new executable called
blender-launcher.exe which starts blender.exe while
hiding the console.
Any command line parameters given to blender-launcher
will be passed on to blender.exe so it'll be a drop
in replacement.
Starting blender.exe on its own will still function as
a proper console app so no changes required here for
users that use blender for batch processing.
Notable changes:
Registering blender (-R switch) will now register
blender-launcher as the preferred executable.
This patch updates the installer and updates the
shortcuts to start blender-launcher.exe rather
than blender.exe
Differential Revision: https://developer.blender.org/D11094
Reviewed by: brecht, harley
|
|
Colors are often thought of as being 4 values that make up that can make any color.
But that is of course too limited. In C we didn’t spend time to annotate what we meant
when using colors.
Recently `BLI_color.hh` was made to facilitate color structures in CPP. CPP has possibilities to
enforce annotating structures during compilation and can adds conversions between them using
function overloading and explicit constructors.
The storage structs can hold 4 channels (r, g, b and a).
Usage:
Convert a theme byte color to a linearrgb premultiplied.
```
ColorTheme4b theme_color;
ColorSceneLinear4f<eAlpha::Premultiplied> linearrgb_color =
BLI_color_convert_to_scene_linear(theme_color).premultiply_alpha();
```
The API is structured to make most use of inlining. Most notable are space
conversions done via `BLI_color_convert_to*` functions.
- Conversions between spaces (theme <=> scene linear) should always be done by
invoking the `BLI_color_convert_to*` methods.
- Encoding colors (compressing to store colors inside a less precision storage)
should be done by invoking the `encode` and `decode` methods.
- Changing alpha association should be done by invoking `premultiply_alpha` or
`unpremultiply_alpha` methods.
# Encoding.
Color encoding is used to store colors with less precision as in using `uint8_t` in
stead of `float`. This encoding is supported for `eSpace::SceneLinear`.
To make this clear to the developer the `eSpace::SceneLinearByteEncoded`
space is added.
# Precision
Colors can be stored using `uint8_t` or `float` colors. The conversion
between the two precisions are available as methods. (`to_4b` and
`to_4f`).
# Alpha conversion
Alpha conversion is only supported in SceneLinear space.
Extending:
- This file can be extended with `ColorHex/Hsl/Hsv` for different representations
of rgb based colors. `ColorHsl4f<eSpace::SceneLinear, eAlpha::Premultiplied>`
- Add non RGB spaces/storages ColorXyz.
Reviewed By: JacquesLucke, brecht
Differential Revision: https://developer.blender.org/D10978
|
|
This reverts commit fd94e033446c72fb92048a9864c1d539fccde59a.
does not compile against latest master.
|
|
Colors are often thought of as being 4 values that make up that can make any color.
But that is of course too limited. In C we didn’t spend time to annotate what we meant
when using colors.
Recently `BLI_color.hh` was made to facilitate color structures in CPP. CPP has possibilities to
enforce annotating structures during compilation and can adds conversions between them using
function overloading and explicit constructors.
The storage structs can hold 4 channels (r, g, b and a).
Usage:
Convert a theme byte color to a linearrgb premultiplied.
```
ColorTheme4b theme_color;
ColorSceneLinear4f<eAlpha::Premultiplied> linearrgb_color =
BLI_color_convert_to_scene_linear(theme_color).premultiply_alpha();
```
The API is structured to make most use of inlining. Most notable are space
conversions done via `BLI_color_convert_to*` functions.
- Conversions between spaces (theme <=> scene linear) should always be done by
invoking the `BLI_color_convert_to*` methods.
- Encoding colors (compressing to store colors inside a less precision storage)
should be done by invoking the `encode` and `decode` methods.
- Changing alpha association should be done by invoking `premultiply_alpha` or
`unpremultiply_alpha` methods.
# Encoding.
Color encoding is used to store colors with less precision as in using `uint8_t` in
stead of `float`. This encoding is supported for `eSpace::SceneLinear`.
To make this clear to the developer the `eSpace::SceneLinearByteEncoded`
space is added.
# Precision
Colors can be stored using `uint8_t` or `float` colors. The conversion
between the two precisions are available as methods. (`to_4b` and
`to_4f`).
# Alpha conversion
Alpha conversion is only supported in SceneLinear space.
Extending:
- This file can be extended with `ColorHex/Hsl/Hsv` for different representations
of rgb based colors. `ColorHsl4f<eSpace::SceneLinear, eAlpha::Premultiplied>`
- Add non RGB spaces/storages ColorXyz.
Reviewed By: JacquesLucke, brecht
Differential Revision: https://developer.blender.org/D10978
|
|
Includes fixes to misspelled function names.
Ref D11280
|
|
|
|
This patch adds wavelength node support to Eevee, similar to how
Eevee Blackbody node works, thus it is a little off from Cycles.
Reviewed By: #eevee_viewport, fclem, brecht
Differential Revision: https://developer.blender.org/D11326
|
|
This patch turns off the creation of file thumbnails for files that are
offline and therefore not fully-present on the file system. These types
of files - typically cloud-based or stored on slower backup media -
only have their contents available when actually accessed, at which
point there will be a short delay. If we allow thumbnail creation in
this state then all offline files in a folder will be downloaded just
to view a listing, which can take a long time.
Files in this state will instead get a more generic thumbnail that
still indicates file type (icon in center) and that shows offline state
will a special icon at the bottom-left.
Although this currently only affects Windows users, most of this patch
is platform-agnostic. So other platforms inherit this behavior if they
only add FILE_ATTR_OFFLINE attribute to files in this state.
See D11101 for more information.
Differential Revision: https://developer.blender.org/D11101
Reviewed by Julian Eisel
|
|
Heterogeneous lookup is useful when constructing a key in a
map/set is relatively expensive (e.g. `std::string`). When doing
lookups in the map/set, one usually does not want to construct
the type to avoid overhead. Instead, heterogeneous lookup
allows for using a different type (such as `StringRef`) as key.
This change makes it easier to implement heterogeneous
lookup for custom types. Before, one had to specialize
`blender::DefaultHash`. Now, one just has to implement
a `static uint64_t hash_as(value)` on the type itself.
One still has to provide the equality operator in addition
to the hash function of course.
|
|
Sometimes it is useful to find the key that compares equal
to a known key. Typically that happens when the key itself
has additional data attached that is not part of its hash.
Note that the returned key reference/pointer is const, because
the caller must not change the key in a way that changes its
hash or how it compares to other keys.
|
|
The wrapper is necessary to support building without TBB.
This class is used by the upcoming new evaluator for
geometry nodes.
|
|
Previously, one could allocate an array, but not construct its
elements directly. This method just adds some convenience.
|
|
|
|
|
|
Problem introduced in {rB1f223b9a}.
This was possibly causing random crashes in Blender file browser when
compiled with ASAN.
Microsoft documents indicate that any call to `CoInitializeEx` must be
balanced by a corresponding call to `CoUninitialize`.
https://docs.microsoft.com/en-us/windows/win32/api/combaseapi/nf-combaseapi-coinitializeex#remarks
|
|
This patch adds initial curve support to geometry nodes. Currently
there is only one node available, the "Curve to Mesh" node, T87428.
However, the aim of the changes here is larger than just supporting
curve data in nodes-- it also uses the opportunity to add better spline
data structures, intended to replace the existing curve evaluation code.
The curve code in Blender is quite old, and it's generally regarded as
some of the messiest, hardest-to-understand code as well. The classes
in `BKE_spline.hh` aim to be faster, more extensible, and much more
easily understandable. Further explanation can be found in comments in
that file.
Initial builtin spline attributes are supported-- reading and writing
from the `cyclic` and `resolution` attributes works with any of the
attribute nodes. Also, only Z-up normal calculation is implemented
at the moment, and tilts do not apply yet.
**Limitations**
- For now, you must bring curves into the node tree with an "Object
Info" node. Changes to the curve modifier stack will come later.
- Converting to a mesh is necessary to visualize the curve data.
Further progress can be tracked in: T87245
Higher level design document: https://wiki.blender.org/wiki/Modules/Physics_Nodes/Projects/EverythingNodes/CurveNodes
Differential Revision: https://developer.blender.org/D11091
|
|
|