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
Integrate an existing implementation of the SLIM unwrapping algorithm
into Blender. More info about SLIM here:
https://igl.ethz.ch/projects/slim/
This commit is based on the integration code written by Aurel Gruber
for Blender 2.7x (unfinished and never merged with the main branch).
This commit is based on Aurel's code, rebased and further improved.
Details:
- Unwrap has been moved into a sub-menu,
slim unwrapping is exposed as: "Minimum Stretch".
- Live unwrap with SLIM refines the solutions using a timer.
- When using SLIM there are options to:
- Set the number of iterations.
- Weight the influence using vertex weights.
- SLIM can be disabled using the `WITH_UV_SLIM` build option.
Co-authored-by: Aurel Gruber <aurel.gruber@infix.ch>
Ref !114545
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
This patches optimizes the Fog Glow Glare node to be about 25x faster
for 4K images. This is mainly achieved by utilizing the FFTW library and
multi-threading support code. Further improvements are still possible by
caching kernels, but the CPU compositor does not support caching yet.
The old Hartley transform was removed, so the node no longer works when
FFTW is disabled as a build time option, much like the OIDN node. A new
BLI library was introduced for FFTW, it includes some helper routines
relevant for FFTW as well as an initialization routine that sets up
multithreading using TBB as well as thread safety.
Build system support for threaded FFTW was also added, which defines the
relevant variables to detect threading support as well as add the
relevant libraries.
We do not currently have the threaded FFTW libs in our precompiled libs,
so the threading code is disabled until the libs lands in the coming
weeks. So currently, the code is only about 9x faster.
The only functional change is that the kernel is now odd sized, which
should produce more accurate results, but the final result is almost
identical and mostly undetectable.
The plan is to port this to the GPU as well similar to how we implement
OIDN until we have a GPU FFT implementation. GPU compositor can also do
caching, so it should be faster, being able to compute a 4K image in
under half a second.
Pull Request: https://projects.blender.org/blender/blender/pulls/121653
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.
Without this canceling cppcheck part way through meant comparing old/new
log-files wasn't possible without manual renaming.
Now the new log-files are only written (and previous execution renamed
to ".old.log") once generating the log has completed.
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
Various changes that simplify running cppcheck, comparing results
from the previous execution.
- Create a summary of the log that groups errors by type,
useful since some kinds of warnings tend to lead to errors in the
code more than others.
- Keep a copy of the previous runs logs - useful for comparisons.
- Log the output in the order of the files selected to check.
- Fix non thread-safe output sometimes mixing warnings from different
processes.
This cleans up our `TEST_SSE_SUPPORT` macro to only test
for SSE42 and passes the flags to the CMAKE_C/CXX_FLAGS
the cpu check module needed to move to its own folder since
the flags at the end of a CMakeLists.txt appear to be used
for all targets inside a CMakeLists file and cpu_check cannot
be build with sse42 flags.
This only affects Mac/Linux since MSVC has no buildflags
to target SSE42
Pull Request: https://projects.blender.org/blender/blender/pulls/118468
MoltenVK original intent was to let developers work on a mac system developing
for the vulkan eco-system. MoltenVK doesn't support all the features that we
require and would require additional workarounds to be actually supported.
It is not expected that we will release Blender with MoltenVK for this reason.
But it still has value for shader developers to validate shaders on metal and
vulkan on a single platform.
Pull Request: https://projects.blender.org/blender/blender/pulls/117940
The script to run cppcheck failed for most files in source/ because
of a syntax error in MEM_guardedalloc.h with attribute functions.
Workaround the error by including BLI_compiler_attrs.h directly.
Other changes:
- Specify c++17 / c11 standards for C++ & C.
- Resolve errors from undefined integer ranges.
- Set the check level to exhaustive so checks always run.
- Suppress noisy missingIncludeSystem warning.
- Move run-time compiler defines into a temporary include
which resolves argument quoting errors when cppcheck is used with
clang's parser.
