* 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.
Exact an exact match with Clang broke building when the compiler ID
was "AppleClang", reverting parts of [0].
[0]: 6549019ae19cecbea524782054dca0e99cb833b8
* Only works on machines with a Qualcomm Snapdragon 8cx Gen3 or above.
Older generation devices are not and will not be supported due to
some driver issues
* Requires VS2022 for building.
* Uses new MSVC preprocessor for sse2neon compatibility.
* SIMD is not enabled, waiting on conversion of blenlib to C++.
Ref #119126
Pull Request: https://projects.blender.org/blender/blender/pulls/117036
When building a non portable build or when not using the precompiled
libraries, do not enable the CPU checker.
Make the cmake configure step error out when building with
WITH_STRICT_BUILD_OPTIONS if the LIBDIR can not be found.
Pull Request: https://projects.blender.org/blender/blender/pulls/118519
This change makes it so build system and update utilities for Blender builds
are using pre-compiled libraries and other resources attached as Git modules
instead of using checkout of SVN repositories in the parent folder.
The directory layout:
```
* release/datafiles/
* assets/ -> blender-assets.git
* publish/
* ...
* README.txt
* lib/
* darwin_x64/ -> lib-darwin_x64.git
* darwin_arm64/ -> lib-darwin_arm64.git
* linux_x64/ -> lib-linux_x64.git
* windows_x64/ -> lib-windows_x64.git
* tests/
* data/ -> blender-test-data.git
```
The changes about configuring the actual Git sub-modules are not included
into this patch, as those require repository to actually exist before it
can be used.
The assets submodule is enabled by default, and the rest of them are
disabled. This means that if someone runs `git submodule update --init`
they will not get heavy libraries. The platform-specific and tests
related submodules are enabled when using `make update` or `make test`.
All the submodules are tracked: this means that when new commits are
done to the submodule, the blender.git repository is to be updated to
point them to the new hash. This causes some extra manual work, but it
allows to more easily update Blender and its dependencies to known good
state when performing operations like bisect.
Ref #108978
Pull Request: https://projects.blender.org/blender/blender/pulls/117946
Blender had a very limited (only uncompressed or MJPEG frames) .avi file
support, for both reading and writing. This is something that ffmpeg can
fully do.
This removes all of that. 3500 lines of code gone, primary motivations being:
- ffmpeg can read and write .avi files just fine, including ones with
uncompressed or MJPEG frames.
- Blender's ffmpeg integration could also be taught to produce uncompressed or
MJPEG .avi files, but TBH I don't see a particular reason to do that. Modern
formats like H264 are better in every way, and already support "lossless"
option if needed.
- The "Lite" blender build configuration was excluding both ffmpeg and avi
anyway, so that config is something that can't read nor write any movies.
User visible changes:
- In scene image output type, under Video section now there's only Ffmpeg Video
(AVI Raw and AVI JPEG are gone)
- Whenever loading an existing file, if output was one of AVI Raw / AVI JPEG,
it is set to Ffmpeg Video.
Pull Request: https://projects.blender.org/blender/blender/pulls/118409
