Statically linking the OpenXR Loader library would cause std exception
type metadata symbol to be duplicated and shadow the base libc++
symbols, causing exception catching type comparaison to fail in
`BLI_string_split_name_number()` (and possibly other unknown issues) -
see [^1] for more details. Fixed by building the OpenXR loader as a
shared library on macOS / Linux, keeping it as a static library on
Windows, following the OpenXR SDK defaults (see docs[^2]).
Tested the OpenXR loader to work and an OpenXR session to successfully
connect on macOS and Linux. Since the library situation doesn't change
on Windows (where the OpenXR Loader lib remains static) a rebuild
should only be needed on macOS / Linux, and can be skipped on Win32 /
WoA.
[^1]: https://projects.blender.org/blender/blender/issues/161404#issuecomment-1985694
[^2]: https://github.com/KhronosGroup/OpenXR-SDK#optional-building-the-openxr-loader-as-a-dll
Pull Request: https://projects.blender.org/blender/blender/pulls/161563
As described in issue #159530, this commit upgrades the Intel Open Image
Denoise library to 2.5.0 to address an image corruption issue on Apple
M5 Pro/Max processors. As the fix couldn't easily be isolated for
backporting, it has been decided to directly upgrade OIDN from 2.4.1 to
2.5.0.
In addition to this, this new OIDN version requires ISPC 1.30.0, which
has also been upgraded from 1.29.1. The 5.2 LTS library change issue
(#153974) has been updated in this regard.
Tests confirmed to pass on macOS arm64, Linux x64 and both Windows x64
and arm64. This commit also contains the updated hash for each platform's
library submodule.
Pull Request: https://projects.blender.org/blender/blender/pulls/159622
An oversight was made in !156154 (Build: Make OpenColorIO and OpenEXR
mandatory deps) where the WoA submodule hash was bumped, but then
discarded by a force-push. Correct this by updating the submodule
hash to the latest main.
Both OpenColorIO and OpenEXR were implicitly always required as these are non optional dependencies of OpenImageIO. Because OpenImageIO currently doesn't try to find these dependencies by itself properly, we get build failures in bpy and lite builds when OpenColorIO and/or OpenEXR is turned off on the Blender side of things. (However, they do properly list them as dependencies in cmake, so if you manually look for them, the OpenImageIO cmake target will pull in all of the required libraries properly)
As OpenImageIO is a mandatory dependency, make OpenColorIO and OpenEXR mandatory as well as these libraries need to be included either way for OpenImageIO (and by extension Blender) to work.
Because of this we can again remove the linker workarounds as now we should properly pull in the needed dependencies where needed.
Pull Request: https://projects.blender.org/blender/blender/pulls/156154
There is a strong coupling between the API version an application
passes to the hiprtCreateContext() and the HIP-RT library: if there
is a mismatch the context will fail to be created.
Additionally, the HIP-RT library does not have static dependencies
as it loads HIP SDK dynamically.
It all makes the wrangler be not so useful, and harmful in cases
when Blender is packaged for different Linux distros which might
use HIP-RT library of a different version from what Cycles is
currently expecting via the bundled hiprtew.h.
The HIPRT_API_VERSION is now coming from the hiprt/hiprt.h so it
is guaranteed that Cycles will request the same API version as
the library is was compiled with.
The slightly annoying part is that this approach requires the
dynamic libraries to have API version in the name of the library
to function properly This is because of the SONAME which still
mentions the original library name. The similar thing happens on
Windows where the hiprt0200564.lib points to the hiprt0200564.dll.
There might be some way to do the rename during install, but it
is a bit tricky, especially due to the manifest on Windows. It
might be the easiest to simply rename precompiled libraries.
Pull Request: https://projects.blender.org/blender/blender/pulls/153892
This updates submodule `lib/windows-x64` to the latest commit, where we
fix an issue that was causing build to be marked as "modified" (#154191).
Co-authored-by: Jonas Holzman <jonas@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/154249
This update the library submodule hash for all platforms, following the
5.1 library update. This includes:
- Windows x64
- Windows arm64
- Linux x64
- macOS arm64
Pull Request: https://projects.blender.org/blender/blender/pulls/153968
This commit includes new minimum compiler requirements for Blender 5.1 as well as updated and new libraries.
**New compiler requirements**
* Windows x64: Visual Studio 2022 (17.14.14 or newer)
* Windows arm64: Visual Studio 2022 (17.14.23 or newer)
* Linux x64: gcc 14 (when used with our libraries)
**New libraries**
Abseil 20250814.1
ThorVG 1.0.0-pre31
OpenJPH 0.25.2
**Updated libraries**
AOM 3.13.1
Expat 2.7.2
FFI 3.5.2
HIPRT 606b4886efabce918dd0634ef71c06615a47c83b
Imath 3.2.2
ISPC 1.29.1
libheif 1.20.2
MaterialX 1.39.4
MESON 1.9.0
minizip-ng 4.0.10
Numpy 2.3.4
oneAPI Level Zero 1.21.9
OneTBB 2022.3.0
OpenColorIO 2.5.0
OpenEXR 3.4.3
OpenImageDenoise 2.4.1
OpenImageIO 3.1.7
OpenSubDiv 3.7.0
OpenVDB 13.0.0
OpenXR 1.1.53
PIP 25.2
Python 3.13.9
ShaderC 2025.4
Vulkan 1.4.328
webp 1.6.0
Yaml CPP 0.8.0
ZSTD 1.5.7 (z-standard 0.25.0)
**Library changes**
FMT (moved from /extern to libs)
Ceres (updated version in lib, will be removed from /extern in a later commit)
Eigen (updated version in lib, will be removed from /extern in a later commit))
Ref #147201
Co-authored-by: Nikita Sirgienko <nikita.sirgienko@intel.com>
Co-authored-by: Ray Molenkamp <github@lazydodo.com>
Co-authored-by: Sebastian Parborg <sebastian@blender.org>
Co-authored-by: Anthony Roberts <anthony.roberts@linaro.org>
Co-authored-by: Jonas Holzman <jonas@holzman.fr>
Co-authored-by: Bart van der Braak <bart@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/149852
These are the changes from #141950 as requested by #141945
this contains the following changes:
Attrs 25.3.0
Cattrs 25.1.1
Fastjsonschema 2.21.1
Typing_extensions 4.14.1
These are the changes from #141950 as requested by #141945
this contains the following changes:
Attrs 25.3.0
Cattrs 25.1.1
Fastjsonschema 2.21.1
Typing_extensions 4.14.1
In Blender 3.3 (1) the individual combine and separate color nodes were
combined together into a single combine/separate color node.
To ensure legacy addons still worked, the old nodes were left in
Blender, but hidden from the Add menus.
It has been nearly 3 years since that change was made, most if not all
addons should have been updated by now. So this commit removes these
hidden legacy nodes.
(1) blender/blender@82df48227b
Pull Request: https://projects.blender.org/blender/blender/pulls/135376
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
