Updates the prebuilt libs to the versions used in 4.4
Also adds a check to ensure users are using at least the version of VS2022, that was used to compile the libraries
Pull Request: https://projects.blender.org/blender/blender/pulls/134405
OpenCollada used to rely on PCRE (a Perl Regexp library). Since
switching to Aras' OpenCollada fork (#122270), the library is no
longer needed, but is still required as a dependency.
This patch cleans this up by completely removing it from our build
system and linux system package installation script. This also lets
us remove it from our pre-compiled library platform repos, making the
process of recompiling our libraries from scratch easier as it wasn't
compiled by our dependency builder anymore.
Pull Request: https://projects.blender.org/blender/blender/pulls/134310
MSVC does this by default, and is a good way to see build progress
indication, when using msbuild. clang-cl also got that option back
in 2018, but it is off by default.
Pull Request: https://projects.blender.org/blender/blender/pulls/133810
That version has a bunch of API changes, so by dropping support for older
versions we can remove old compatibility code.
Also, that version is required for OptiX support, so building a fully-featured
Cycles wasn't possible with older OSL anyways.
Pull Request: https://projects.blender.org/blender/blender/pulls/133746
- WITH_WINDOWS_EXTERNAL_MANIFEST is now required even for ninja
builds, this previously was not the case. so just apply it
across all build flavours on windows.
- fmsc-version=1922 is no longer needed, was required back when
support for clang on windows landed, is fine without it now.
- /MP gives better build performance when building from the IDE
makes no difference for a ninja build which wasn't struggling in
that department anyhow.
* Some libraries like Alembic and OpenColorIO for a long time removed
header dependencies on Boost.
* No need to have BOOST_LIBRARIES anymore, only BOOST_PYTHON_LIBRARIES
is a direct dependency through USD headers.
* OpenVDB is no longer a static library, no need to link its dependencies.
Pull Request: https://projects.blender.org/blender/blender/pulls/133424
While I implemented pipewire support I forgot that some of the functions I use is not available in older pipewire versions.
This adds proper library version sanity checks for pipewire.
Pull Request: https://projects.blender.org/blender/blender/pulls/131610
CMake 3.31+ have begun emitting warnings when you feed install()
paths that are not normalized (ie have, '.' or '..' in them) easiest
fix is just not use them.
This cleans up the windows sections of the build system, the other
platform devs will have to take a look on their respective platforms.
This is not an officially supported platform, but it was working before
so might as well keep it up to date.
* Tweak logic for various BLENDER_PLATFORM_ARM checks
* Use linux_arm64 name for folders, matching Windows and macOS
* CUDA is enabled, SYCL and HIP are not
* Tested to work on Rocky Linux 8
This change switches Cycles to an opensource HIP-RT library which
implements hardware ray-tracing. This library is now used on
both Windows and Linux. While there should be no noticeable changes
on Windows, on Linux this adds support for hardware ray-tracing on
AMD GPUs.
The majority of the change is typical platform code to add new
library to the dependency builder, and a change in the way how
ahead-of-time (AoT) kernels are compiled. There are changes in
Cycles itself, but they are rather straightforward: some APIs
changed in the opensource version of the library.
There are a couple of extra files which are needed for this to
work: hiprt02003_6.1_amd.hipfb and oro_compiled_kernels.hipfb.
There are some assumptions in the HIP-RT library about how they
are available. Currently they follow the same rule as AoT
kernels for oneAPI:
- On Windows they are next to blender.exe
- On Linux they are in the lib/ folder
Performance comparison on Ubuntu 22.04.5:
```
GPU: AMD Radeon PRO W7800
Driver: amdgpu-install_6.1.60103-1_all.deb
main hip-rt
attic 0.1414s 0.0932s
barbershop_interior 0.1563s 0.1258s
bistro 0.2134s 0.1597s
bmw27 0.0119s 0.0099s
classroom 0.1006s 0.0803s
fishy_cat 0.0248s 0.0178s
junkshop 0.0916s 0.0713s
koro 0.0589s 0.0720s
monster 0.0435s 0.0385s
pabellon 0.0543s 0.0391s
sponza 0.0223s 0.0180s
spring 0.1026s 1.5145s
victor 0.1901s 0.1239s
wdas_cloud 0.1153s 0.1125s
```
Co-authored-by: Brecht Van Lommel <brecht@blender.org>
Co-authored-by: Ray Molenkamp <github@lazydodo.com>
Co-authored-by: Sergey Sharybin <sergey@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/121050
This reverts commit 0a0551cf26.
This commit broke building on linux with mold. It seems to never
generate the necessary file when something other than the `blender`
binary is the first thing being built.
Support manipulating symbols_unix.map using symbols_unix.map.cmake
script.
Currently this removes symbols that generate noisy warnings with the
mold linker.
Disable dynamic SDL loading as well as disable SDL for release builds.
This was only used for audio output which can already use OpenAL
if there are back-ends not natively supported by Blender.
- Remove extern/sdlew/
- Remove the WITH_SDL_DYNLOAD build option.
- Remove `bpy.app.sdl.available`.
Ref !127554
On Windows, if compiler is 32 bit there already is a fatal error. If it
is 64 bit (normal case, and any case when build can actually work), it
feels like "64 bit compiler detected" status message does not indicate
anything useful.
Pull Request: https://projects.blender.org/blender/blender/pulls/127484
Correct fix from [0].
The previous fix seemed to work but on further testing the environment
wasn't properly expanded. Using "$$" prefix resolves the problem.
[0]: b0ec4bba70
The value used for the the library path was being evaluated by CMake
instead of forwarding the value to the shell expression (as intended).
This meant any build-time binaries that depended on the environments
library-path would failed to run.
This gets Windows ARM64 to compile with clang-cl, which gives up to 40% performance improvements in certain scenes rendered with cycles, compared to MSVC.
This is all tested using LLVM 18.1.8 and a VS2022 `vcvarsall` window.
Subsequent PRs with various lib version updates, etc to go in at a later point.
Pull Request: https://projects.blender.org/blender/blender/pulls/124182
This continues the cmake modernization effort and introduces support for
allowing our optional dependencies to integrate properly. TBB is added
here as it's proven troublesome to maintain correctly.
Currently the only Blender project which uses the TBB headers directly
is `blenlib`. However, all downstream projects which require blenlib as
their dependency, and wish to properly make use of its threading
facilities, needed to define various TBB items in their CMake files. Not
only is this unnecessary and arcane, but several projects didn't do this
and ended up not using threading as well as producing ODR violations
along the way[1].
This PR makes TBB a modern dependency and exposes it PUBLIC'ly from
`blenlib`. All downstream projects which depend on blenlib will now
receive everything they require from TBB automatically. This includes
the `WITH_TBB` define, the headers, and the library itself.
[1] blender/blender@05241f47f5
Pull Request: https://projects.blender.org/blender/blender/pulls/124916
When having several clang versions installed cmake would default
to the last llvm directory in the registry when finding the openmp
libraries. Two problems with that are :
1- The registry entry may not exist
2- Even if it exists it may not point to the right folder for the
Current compiler.
This PR changes the behaviour to look relative to the clang binary
to find the openmp libraries.
Pull Request: https://projects.blender.org/blender/blender/pulls/125101
* Always define root directories in LIBDIR even when not needed,
to silence some warnings.
* Only show warnings about not finding libs when oneAPI is enabled.
* Prefix message for context.
It originally came from the Compositor work about optimizing Glare
node (#121653), but it might be used in more places later as well.
This PR only contains changes to the build system, the library
itself needs to be re-compiled.
Ref #118455
Pull Request: https://projects.blender.org/blender/blender/pulls/121816
When building with asan enabled on windows tools such as
msgfmt will run before the install phase which normally
copies the required asan dlls next to the binaries preventing
msgfmt from stating and causing a build error.
This change adds the MSVC path to the PLATFORM_ENV_BUILD_DIRS
so when we run the various tools the asan shared libs can
be found.
This PR adds a cmake option `WITH_WINDOWS_EXTERNAL_MANIFEST`
which is off by default which addresses the following 2 problems:
The CI env occasionally fails to link the manifest into blender.exe
with mt.exe getting file in use error. The solutions mentioned online
vary wildly between, just rebuild, turn off your AV, use this magic
switch. None of them actually point to a root cause we can address.
When building blender with clang and the visual studio generator
it also somehow doesn't embed the manifest.
If the bots stay problematic this option can be turned on for the CI
environment, and will be automatically turned on when it detects clang
and the visual studio generator being used.
Pull Request: https://projects.blender.org/blender/blender/pulls/111683
