It's better for performance to use a single thread pool for all areas of
Blender, and this gets us closer to that.
Bullet, Quadriflow, Mantaflow and Ceres still contain OpenMP code, but it
was already disabled.
On macOS, our OpenMP libraries are no longer compatible with the latest
Xcode 16.3. By removing OpenMP we no longer have to solve that problem.
OpenMP was disabled for bpy module builds on Windows ARM64, which also no
longer needs to be solved.
Pull Request: https://projects.blender.org/blender/blender/pulls/136865
Only the parallel sparse matrix code was updated. This is used by e.g.
LSCM and ABF unwrap, and performance seems about the same or better.
Parallel GEMM (dense matrix-matrix multiplication) is used by libmv,
for example in libmv_keyframe_selection_test for a 54 x 54 matrix.
However it appears to harm performance, removing parallelization makes
that test run 5x faster on a Apple M3 Max.
There has been no new Eigen release since 2021, however there is active
development in master and it includes support for a C++ thread pool for
GEMM. So we could upgrade, but the algorithm remains the same and
looking at the implementation it just does not seem designed for modern
many core CPUs. Unless the matrix is much larger, there's too much thread
synchronization overhead. So it does not seem useful to enable that
thread pool for us.
Pull Request: https://projects.blender.org/blender/blender/pulls/136865
To make adding a dependeny on TBB easier.
Additional changes:
* Using LIB for libmv tests, as it now brings in includes
* Removing Eigen header listing in iTaSC
Pull Request: https://projects.blender.org/blender/blender/pulls/136865
GPU_DEPTH_NONE leads to issues with Intel GPU drivers on Windows
where camera gizmos cannot be shifted. glGetQueryObjectuiv for
GL_SAMPLES_PASSED seems to return zero in all cases.
This might be due to undefined behavior of OpenGL when the depth
test is disabled and rendering to a depth render target-only
framebuffer. Using GPU_DEPTH_ALWAYS fixes the issue.
Pull Request: https://projects.blender.org/blender/blender/pulls/136607
Previously pressing `c` to cut through mesh will only update knife cuts
when mouse is moved again, this means if you press `c` at the end of
mouse stroke, it will not update cuts and you end up still only cutting
front faces. This fix makes it that the toggle refreshes knife cuts
immediately.
Pull Request: https://projects.blender.org/blender/blender/pulls/136870
`win->ime_data` could be non-null when it's read from a file, and
subsequent dependence of this value would crash on interface handlers.
Now always clear it when ghost window is ensured after reading the file.
The actual reset is put in `wm_window_ensure_eventstate`, since it's
also conceptually a part of "event state".
Pull Request: https://projects.blender.org/blender/blender/pulls/136833
Under some circumstances the `value_task` run by node tree updates
needs access to a node group topology cache. Unlike the `usage_task`
it was not ensuring the cache for the node group, so a stale cache
could be used (triggers assert).
Pull Request: https://projects.blender.org/blender/blender/pulls/136878
This was an issue previously not noticed. There were two bugs:
- When an out of range index was somehow detected, line art discards the
entire stroke after the point, which causes remaining point positions
to be invalid. In fact the index should never go out of range unless
total points in the scene exceeds `size_t`.
- Line art point index is global, not local to objects, previously the
"object starting index" was not subtracted from the final point index
when transferring weights, this will lead to incorrect weight being
transferred/discarded.
Now both problems have been properly taken care of.
Pull Request: https://projects.blender.org/blender/blender/pulls/136869
The goal is to be able to switch away from OpenMP by default.
In order to achieve this a new parallel_for() function is added,
which follows the same declaration as the one from TBB. For now
the simplest formulation is used where range is provided by start
and last indices (the last one is excluded from the range).
The side effect is that Libmv now expects the threading limits
to be imposed by the default thread area (or have an explicit
thread area with the limit in the caller). In a way this is
similar to other external libraries.
Pull Request: https://projects.blender.org/blender/blender/pulls/136834
Caused by not checking against key array size. The issue was introduced
in ee9e4ead8d. It looks like mistake done during refactoring, because
the code was supposed to fix previous transition segment, not only the
next one.
The previously code attempted to reduce levels of indentation, but it
was less readable and error prone. Now it should be more obvious what
the intent is.
Pull Request: https://projects.blender.org/blender/blender/pulls/136743
Disambiguates between Apple Clang 17 (based off LLVM 19) and LLVM
Clang 17. Although an LLVM Clang 17 build is unlikely currently to
succeed on macOS, the subtle differences between the two compilers can
easily led to confusion. So clearly indicate this fix only targets Apple
Clang.
MacOS is currently using one of our custom "hourglass" cursors during
busy times. This PR changes it to an OS-supplied cursor, a pointer
arrow with an animated blue spinner, meant for this purpose. Although
undocumented it has been used by many applications for many years.
Including Firefox for 11 years now.
Pull Request: https://projects.blender.org/blender/blender/pulls/136735
The bug was partially caused by the fact that
`translate_snap_increment_ex` would interpret sequencer-specific
snapping bit `SEQ_SNAP_TO_FRAME_RANGE` as `SCE_SNAP_TO_INCREMENT`. Add a
check to fix this.
Technically, #122759 never added snapping for cursors in the preview,
but we can take this opportunity to also add the support, which is
relatively simple.
Pull Request: https://projects.blender.org/blender/blender/pulls/136579
* Replace #define with constexpr
* Use float3 instead of float[3]
* Use C++ math library
* Use return values instead of r_ prefixed arguments
* Use const where possible
Pull Request: https://projects.blender.org/blender/blender/pulls/136851
Part of #131825
Currently, no change to an RNA property invoked from the UI while inside
Vertex Paint mode creates an undo step. This includes both tool
properties (e.g. brush size, tool settings) as well as mesh properties
(symmetry, active vertex group, selection mode).
This behavior was initially introduced to avoid creating extra undo
steps when painting or sculpting and changing tool settings, however,
it applied to all property changes performed while in any paint mode,
including changes to mesh datablock properties.
To fix this behavior, this commit removes the usage of the sculpt undo
system from Vertex Paint and removes it from the list of modes that
are incompatible with memfile undo.
This switch from Sculpt Undo to Memfile Undo improves the performance of
the undo operator from 90ms to 9ms, representing a 10x speedup.
This speedup is possible because Vertex Paint is not fully integrated
with the Paint BVH drawing system, which normally has the benefit of
skipping depsgraph reevaluation and subsequent BVH rebuilding on each
stroke.
Anecdotally, when painting with large strokes on a mesh of 2 million
vertices, this change to using Memfile undo also uses anywhere from
half as much to a third as much memory compared to the Sculpt Undo
implementation (6 GB vs 2 GB).
Pull Request: https://projects.blender.org/blender/blender/pulls/135830
Part of #131825
Currently, no change to an RNA property invoked from the UI while inside
Vertex Paint mode creates an undo step. This includes both tool
properties (e.g. brush size, tool settings) as well as mesh properties
(symmetry, active vertex group, selection mode).
This behavior was initially introduced to avoid creating extra undo
steps when painting or sculpting and changing tool settings, however,
it applied to all property changes performed while in any paint mode,
including changes to mesh datablock properties.
To fix this behavior, this commit removes the usage of the sculpt undo
system from Vertex Paint and removes it from the list of modes that
are incompatible with memfile undo.
This switch from Sculpt Undo to Memfile Undo improves the performance of
the undo operator from 90ms to 9ms, representing a 10x speedup.
This speedup is possible because Vertex Paint is not fully integrated
with the Paint BVH drawing system, which normally has the benefit of
skipping depsgraph reevaluation and subsequent BVH rebuilding on each
stroke.
Anecdotally, when painting with large strokes on a mesh of 2 million
vertices, this change to using Memfile undo also uses anywhere from
half as much to a third as much memory compared to the Sculpt Undo
implementation (6 GB vs 2 GB).
---
Similar to !135758
### Implementation Notes / Thoughts
An alternate approach to getting similar if not better performance in Vertex Paint mode is to integrate it with `BKE_sculptsession_use_pbvh_draw` and `flush_update_step`, however this represents an unknown amount of work and does not reduce the number of consumers of Sculpt Undo. Given that the general direction in the module right now is to reduce dependency upon this system and migrate more to using Memfile undo where possible, spending extra effort on integration does not seem like the correct decision to make.
### Testing
* Verified undo step is created when selection mode is changed
* Verified undo step is created when symmetry is changed
* Verified undo step is created when active color attribute is changed
* Verified undo step is created when color attribute underlying data is changed
Pull Request: https://projects.blender.org/blender/blender/pulls/135830
The scene isn't being changed here, especially object selection. The mesh
is being changed though (or rather its shape key data-block, but that really
means the objects using it need to be reevaluated). For some reason this
doesn't make a functional difference currently though.
- Remove useless wrapper function that checked redundant invariants
- Use Vector instead of looping over context variable twice
- Use references instead of pointers
- Make variable names non-cryptic
- Remove useless comment
- Use continue instead of indenting the rest of loops
- Fix grammar and improve text in comment
Adds new NURBS knot mode NURBS_KNOT_MODE_FREE. Knots are stored in
`CurvesGeometry::custom_knots`. Knot offsets binding them to their
curves are calculated at runtime and held in a cache. This commit adds
custom knots support to OBJ import. It is the only way create such
curves for now. Legacy curve's tools don't support this knot mode,
thus on any modification knots get regenerated and whole shape changes.
If to convert imported legacy curve to new curves, point deletion,
duplicate and extrude preserve custom knots.
Rel #99891
Pull Request: https://projects.blender.org/blender/blender/pulls/130132
The precompiled library uses incompatible ABI with this version,
leading to linking errors.
There is no easy short-term solution: as per documentation the
OpenMP library must match LLVM version. It is hard to achieve in
a way that both older and newer LLVM versions are supported: it
would need to be multiple OpenMP libraries pre-compiled and chosen
at the build time.
There are not that many places left in Blender when OpenMP is
still used, so it seems better to invest in getting of those
remaining cases. The most challenging one would be Eigen, but
need to check whether the code-paths that are used from Eigen
even contain OpenMP.
Pull Request: https://projects.blender.org/blender/blender/pulls/136828
Cause by trying to deference a null batch.
In normal case, these calls never create a command
and are discarded early. 4.4 introduced the
polyline_draw_workaround to remove the use of geometry
shaders. These were not guarded against zero vertices
calls.
Adding an early out clause fixes the issue.
Pull Request: https://projects.blender.org/blender/blender/pulls/136840
Reduce the register pressure and branching in the switch() by using
subclass and cast from void* to the base class.
This ensures intersection functions are not inlined multiple times,
bringing performance back.
Alternative could be to avoid functions (they are quite large) but
that only partially resolves the performance regression.
Pull Request: https://projects.blender.org/blender/blender/pulls/136823
While profiling a scene with many objects, I noticed some unexpected
functions taking a significant time of depsgraph creation/evaluation.
String length calculation and equality comparison was taking longer than
it should, and some simple methods were appearing in profiles that should
be inlined instead.
There are more places where this sort of change would be helpful, this
commit just changes places using `OperationIDKey` and `ComponentIDKey`.
Pull Request: https://projects.blender.org/blender/blender/pulls/136795
This was caused by the deinterleaved format being
incorrectly decoded by the `bind_attribute_as_ssbo`
function.
Accumulating the offset should be done for all attributes
and not only the one being used. Furthermore, this needs
to happen only once per attribute and not once per name.
Moving the offset computation out of the name loop
fixes the issue.
Pull Request: https://projects.blender.org/blender/blender/pulls/136821
If render engines dont specify `RE_USE_PREVIEW` / `bl_use_preview`, they
wont pass the `ED_check_engine_supports_preview` test.
That is mostly meant to tell blender this engine is capable of
generating (Material) previews and if it isnt, they will skip generating
button previews in `icon_preview_startjob_all_sizes`.
There are already exceptions for type of IDs that can still generate
previews (think Asset previews for Objects or Actions), so the same
exception can be made for Images and Brushes as well (these previews
will just befulled from the Image buffer, that should not rely on the engine
whatsoever). We can also be permissive on Groups (they are treated
similar to Objects).
NOTE: this was reported for the Workbench engine, in another (future)
commit, we might even consider flagging that engine `RE_USE_PREVIEW` as
well (see comments in the PR)?
Pull Request: https://projects.blender.org/blender/blender/pulls/136824
This PR refactors the way how swapchains are used.
Allow scaling of the swapchain content to the actual resolution of the swapchain.
can reduce artefacts when resizing windows when supported.
When frame rate is to fast the previous implementation could use a semaphore
that were still in use, leading to unwanted stuttering on certain platforms. Waiting
when the rendering has finished (GHOST_Frame.submission_fence), before the
next image is acquired from the swap chain.
Mailbox has been disabled as it can calculate more frames then actually been
presented, leading to a lag and increased power usage on others.
Pull Request: https://projects.blender.org/blender/blender/pulls/136603
When making a minimized window larger Blender can have negative regions.
This leads to out of bound writes when blitting to the framebuffer.
Easy reproducable on NVIDIA/Windows.
Pull Request: https://projects.blender.org/blender/blender/pulls/136832
When debugging with gdb in vscode, the stuff I print when executing a script in
the text editor does not show up in the terminal. It does work when I flush
explicitly though using `print(..., flush=True)`. This is quite annoying.
The solution is to always flush `stdout` and `stderr` automatically when running
a script. This is done using the CPython API, as just using
`fflush(stdout/stderr)` did not solve the issue.
Pull Request: https://projects.blender.org/blender/blender/pulls/136632
