Some Linux multi lib setups have a helper include file for Jemalloc that
in turn includes the actual header file. This makes our version regex fail.
As the Jemalloc version we are checking for is no longer in any of
the currently supported LTS linux distros, we can safely drop it.
Pull Request: https://projects.blender.org/blender/blender/pulls/139225
OpenColorIO is now a dynamic library, and these are included in it. The
legacy code for the static library case was causing the Homebrew libraries
to be found and linked to.
Pull Request: https://projects.blender.org/blender/blender/pulls/139087
Pretty bare bones but gets the job done, unlike the gcc
tooling, this will work for release builds, the performance cost
of it is on the high side of things, the full test suite tests take over
an hour for me with code coverage support enabled on a release build.
I have not timed a debug build. Given developers can just run their
tests to get coverage data over what they are working on, I feel this
is still useful tooling to have.
This adds the 3 targets for clang and adds a single gcc target
coverage-reset - this removes the collected code coverage data and
report
coverage-report - This merges the collected data and generates the
report (new for gcc)
coverage-show - This merges the collected data and generates the report
and opens it in the browser
This relies on llvm-cov and llvm-profdata being available if not found
code coverage is disabled.
Note: A full test run requires an obscene amount of disk space, a
complete test run takes about 125GB and takes 12 minutes to merge, so
provision the COMPILER_CODE_COVERAGE_DATA_DIR folder accordingly
Example report in PR
Briefly about this change:
- OpenColorIO C-API is removed.
- The information about color spaces in ImBuf module is removed.
It was stored in global ListBase in colormanagement.cc.
- Both OpenColorIO and fallback implementation supports GPU drawing.
- Fallback implementation supports white point, RGB curves, etc.
- Removed check for support of GPU drawing in IMB.
Historically it was implemented in a separate library with C-API, this
is because way back C++ code needed to stay in intern. This causes all
sort of overheads, and even calls that are strictly considered bad
level.
This change moves OpenColorIO integration into a module within imbuf,
next to movie, and next to IMB_colormanagement which is the main user
of it. This allows to avoid copy of color spaces, displays, views etc
in the ImBuf: they were used to help quickly querying information to
be shown on the interface. With this change it can be stored in the
same data structures as what is used by the OpenColorIO integration.
While it might not be fully avoiding duplication it is now less, and
there is no need in the user code to maintain the copies.
In a lot of cases this change also avoids allocations done per access
to the OpenColorIO. For example, it is not needed anymore to allocate
image descriptor in a heap.
The bigger user-visible change is that the fallback implementation now
supports GLSL drawing, with the whole list of supported features, such
as curve mapping and white point. This should help simplifying code
which relies on color space conversion on GPU: there is no need to
figure out fallback solution in such cases. The only case when drawing
will not work is when there is some actual bug, or driver issue, and
shader has failed to compile.
The change avoids having an opaque type for color space, and instead
uses forward declaration. It is a bit verbose on declaration, but helps
avoiding unsafe type-casts. There are ways to solve this in the future,
like having a header for forward declaration, or to flatten the name
space a bit.
There should be no user-level changes under normal operation.
When building without OpenColorIO or the configuration has a typo or
is missing a fuller set of color management tools is applies (such as the
white point correction).
Pull Request: https://projects.blender.org/blender/blender/pulls/138433
While shaderc is a c++ library that normally requires debug libs
for ABI reasons, shaderc only exports a C interface, so it will
link release mode libs just fine even for debug builds.
This drops the time required for GPU_shader_compile_static in a
debug build from 5 mins to 3 sec for @pragma37
no changes for release configurations.
This change moves the tests data files and publish folder of assets
repository to the main blender.git repository as LFS files.
The goal of this change is to eliminate toil of modifying tests,
cherry-picking changes to LFS branches, adding tests as part of a
PR which brings new features or fixes.
More detailed explanation and conversation can be found in the
design task.
Ref #137215
Pull Request: https://projects.blender.org/blender/blender/pulls/137219
Enable optimizations on Debug builds for executables used for the build
process (datatoc and glsl_preprocess) and enable unity builds for
shader preprocessing targets.
Debug: From 28.9s to 5.7s
Release: From 4.9s to 3.5s
Pull Request: https://projects.blender.org/blender/blender/pulls/138274
See #129009 for context.
The preprocessor parses metadata and writes a header file containing
an inline function that inits the `GPUSource` with the metadata.
These header files are then included inside `gpu_shader_dependency.cc`.
This still keep the usage of the `metadata` enums and classes to avoid
pulling the whole blender module inside the preprocessor executable.
This speeds-up startup time in Debug build:
`gpu_shader_dependency_init`
- Before : 37ms
- After : 4ms
I didn't measure release, but it is unlikely to be noticeable (in the
order of 4ms > 1ms).
Pull Request: https://projects.blender.org/blender/blender/pulls/138070
Adds the 'manifold' solver option to the Boolean geo node and to
the Boolean modifier. This solver is about as fast, or faster,
than the current float solver, and is robust against floating
point issues like the Exact solver. But currently it only
works on mesh arguments that are strictly manifold.
See https://projects.blender.org/blender/blender/issues/120182
for many more details.
This patch changes the default macOS x64 linker from the slower legacy
"classic" linker, to the much faster default modern macOS linker. A new
CMake option `WITH_LEGACY_MACOS_X64_LINKER` was also introduced to use
the old linker, set to OFF by default.
As an example from testing on an Intel Macbook, this makes linking time
go from 3min25s to 10s after this change. The reason why the legacy
linker was enforced on x64 in the first place was to silence "platform
load command not found" warnings during linking. Since this behavior is
still desired on the BuildBot, the `WITH_LEGACY_MACOS_X64_LINKER` option
is enforced in the BuildBot macOS configs.
Pull Request: https://projects.blender.org/blender/blender/pulls/134639
Adds a C++ based FBX importer, using 3rd party ufbx library (design task:
#131304). The old Python based importer is still there; the new one is marked
as "(experimental)" in the menu item. Drag-and-drop uses the old Python
importer; the new one is only in the menu item.
The new importer is generally 2x-5x faster than the old one, and often uses
less memory too. There's potential to make it several times faster still.
- ASCII FBX files are supported now
- Binary FBX files older than 7.1 (SDK 2012) version are supported now
- Better handling of "geometric transform" (common in 3dsmax), manifesting
as wrong rotation for some objects when in a hierarchy (e.g. #131172)
- Some FBX files that the old importer was failing to read are supported now
(e.g. cases 47344, 134983)
- Materials import more shader parameters (IOR, diffuse roughness,
anisotropy, subsurface, transmission, coat, sheen, thin film) and shader
models (e.g. OpenPBR or glTF2 materials from 3dsmax imports much better)
- Importer now creates layered/slotted animation actions. Each "take" inside
FBX file creates one action, and animated object within it gets a slot.
- Materials that use the same texture several times no longer create
duplicate images; the same image is used
- Material diffuse color animations were imported, but they only animated
the viewport color. Now they also animate the nodetree base color too.
- "Ignore Leaf Bones" option no longer ignores leaf bones that are actually
skinned to some parts of the mesh.
- Previous importer was creating orphan invisible Camera data objects for
some files (mostly from MotionBuilder?), new one properly creates these
cameras.
Import settings that existed in Python importer, but are NOT DONE in the new
one (mostly because not sure if they are useful, and no one asked for them
from feedback yet):
- Manual Orientation & Forward/Up Axis: not sure if actually useful. FBX
file itself specifies the axes fairly clearly. USD/glTF/Alembic also do
not have settings to override them.
- Use Pre/Post Rotation (defaults on): feels like it should just always be
on. ufbx handles that internally.
- Apply Transform (defaults off, warning icon): not sure if needed at all.
- Decal Offset: Cycles specific. None of other importers have it.
- Automatic Bone Orientation (defaults off): feels like current behavior
(either on or off) often produces "nonsensical bones" where bone direction
does not go towards the children with either setting. There are discussions
within I/O and Animation modules about different ways of bone
visualizations and/or different bone length axes, that would solve this
in general.
- Force Connect Children (defaults off): not sure when that would be useful.
On several animated armatures I tried, it turns armature animation
into garbage.
- Primary/Secondary Bone Axis: again not sure when would be useful.
Importer UI screenshots, performance benchmark details and TODOs for later
work are in the PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/132406
This was introduced during EEVEE-next developement
cycle to not make the buildbot fail because of EEVEE
render tests.
These have stabilized now and we can remove this option.
Pull Request: https://projects.blender.org/blender/blender/pulls/137545
This patch replaces our own FindTBB module with TBB's own TBBConfig
module. On the technical side of things, this harvests the TBB CMake
config modules, and switches our TBB CMake find_package calls from
Module mode to Config mode. Integration was done using OpenPGL as a
blueprint for parsing TBB target's property back into CMake variables
(TBB_LIBRARIES and TBB_INCLUDE_DIRS).
Pull Request: https://projects.blender.org/blender/blender/pulls/137063
Removes '/' prefix from gtest filter for parameterized tests. This prefix
was causing tests in fixtures like VKRenderGraphTestScheduler and
VKRenderGraphTestRender to be skipped in `make test`.
Only parameterized tests with an InstantiationName will have a '*/' in
their names as part of a prefix. But according to the spec, InstantiationName
is optional, and if not set it wont generate prefixes. In these cases, the
gtest_filter produced will not match the test names, and cause `make test`
to not run the tests.
Removing this '*/' prefix should still match any tests with a non-empty
InstantiationName.
Pull Request: https://projects.blender.org/blender/blender/pulls/136987
Majority of projects within generated VS IDE solution are put under
their respective source folders, except the test executables. Majority
of which are various libmv tests. Use the same cmake macro to arrange
them in folders as what is used for regular libraries.
Pull Request: https://projects.blender.org/blender/blender/pulls/137028
Implements a crash dialog for Windows.
The crash popup provides the following actions:
- Restart: reopen Blender from the last saved or auto-saved time
- Report a Bug: forward to Blender bug tracker
- View Crash Log: open the .txt file with the crash log
- Close: Closes without any further action
Pull Request: https://projects.blender.org/blender/blender/pulls/129974
Resolve CMake warning, using an undefined variable.
Don't attempt to use OSL_SHADER_DIR in it's own hint,
introduced in fix for #73830.
This was also overwriting the previous assignment from "OSL_COMPILER".
Ref !136961
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
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.
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
This is done because the library is necessary to make certain FFTW
functions thread safe, see #136557 as well.
Also pass each library variable separately to
`find_package_handle_standard_args` instead of as a list, as otherwise
it won't correctly detect if `libfftw3f` or `libfftw3f_threads` is
missing. This is because CMake considers a value false if it contains
`-NOTFOUND` at the end, but not if it's in the middle. For example,
CMake considers
`.../libfftw3f.a;.../libfftw3f_threads.a;FFTW3_LIBRARY_D-NOTFOUND` to be
false, but
`.../libfftw3f.a;FFTW3_LIBRARY_THREADS_F-NOTFOUND;.../libfftw3.a` to be
true.
---
I noticed that some other find modules also have the same list issue. I guess it was done this way to make CMake print all the found libraries instead of only the first.
Pull Request: https://projects.blender.org/blender/blender/pulls/136692
The issue is caused by the fact that when both compositors are used,
`fftwf_plan_dft_r2c_2d` can end up being called in parallel, which is
only thread-safe if `fftwf_make_planner_thread_safe` is called before.
This is done by `fftw::initialize_float`, but only if the FFTW threading
support library is available. Said library was not detected correctly on
Windows because of a typo, which this change addresses. This should also
make the fog glow faster on Windows because it'll now use multithreaded
FFT as intended.
This change also moves the call to `initialize_float` to the main
function because the FFTW functions it calls are not thread-safe and
because FFTW is also used by Audaspace, which cannot call it.
Pull Request: https://projects.blender.org/blender/blender/pulls/136557
DEPENDS is not supported for post_build commands and recent
cmake versions have started emitting warnings about that.
This can be safely removed, as cmake has been silently ignoring
the keyword for years.
This is primarily to solve Intellisense failures with various USD
header files and macros. However, it also unifies Windows x64 with
Windows arm64 (though MSVC is unused for arm64 currently) since it would
be required for proper `sse2neon` support anyhow.
Pull Request: https://projects.blender.org/blender/blender/pulls/135844
PR as discussed on the thread for #134676.
Works by disabling dependent load flag in OIDN, and also switching off OpenMP.
The OIDN bit is just a workaround until they can resolve this properly on their side by fixing the manifest.
The OpenMP bit requires more investigation regarding delayed loading.
Pull Request: https://projects.blender.org/blender/blender/pulls/135319
Seems like ASAN has been broken on debug builds for MSVC ever since
d5e50460e7 (1.5 years ago) the core reason is it's incompatible with
fastlink, it'll appear to work, but in the asan reports no symbols
will be resolved.
While looking into this, some other problems like the symbol format being
not inline with the table in the comment above it, and a warning coming
out of /extern were noted.
All of these issues are addressed in this commit.
This change brings the following improvements on the user level
- Support of GPUs with gfx12 architecture
- New HIP-RT library which in addition to the gfx12 support brings
various bug-fixes.
The known limitation of gfx12 is that OpenImageDenoiser does not yet
support this GPU architecture. This means that while Cycles will use the
full advantage of the gfx12 (including hardware accelerated ray-tracing),
denoising will only be possible on CPU, or secondary gfx11 or below GPU.
This is something that requires a change in OIDN and it is to late to do
it for Blender 4.4, but it is something to look forward for Blender 4.5.
The gfx12 changes for the pre-compiled kernels is rather trivial,
so it comes together (in the same PR) as the bigger HIP-RT change.
On the development side this change brings the following improvements:
- One step compile and link (much simpler CMake rules)
- Embedding BVH binaries in hiprt dll (which makes it easier to package
and load, without relying on special path configuration)
Co-authored-by: Sahar Kashi <sahar.kashi@amd.com>
Co-authored-by: Sergey Sharybin <sergey@blender.org>
Co-authored-by: Brecht Van Lommel <brecht@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/133129
