Currently, every time blender starts on one of these platforms, we get the following warning (doesn't affect how it runs, all tests pass anyway):
```
TBBmalloc: skip allocation functions replacement in ucrtbase.dll: unknown prologue for function free
```
This is due to TBB_MALLOC_PROXY not working on these platforms (happens with emulated x64 too). I suspect it is fixed in the newer oneTBB releases that have proper support for Windows on Arm, rather than the patch I made to enable 2020u3.
This can be revisited once the TBB version is updated.
Pull Request: https://projects.blender.org/blender/blender/pulls/124148
This required various compiler and SDK updates
* HIP on Windows updated to 5.7.3
* HIP on Linux updated to 6.3.1
* HIP-RT updated to version 2.0.e1ff193
Co-authored-by: Brecht Van Lommel <brecht@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/123256
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
Building with clang on windows isn't an officially supported scenario
but it's something we'd like to keep working, but as it doesn't see
regular use, things tend to bit rot a bit.
0136289cb6 got things back into somewhat working order however the build
log came in at a little over 5.5GiB emitting a total of 11.787.294
warnings (827.847 unique), it was getting to the point where printing
all warnings, was a rather significant contributor to the total build
time.
this PR, suppress every single warning out of that build, one could
argue that some of these warnings are actually genuine and should be
enabled, and dealt with, the thing is, building with clang isn't
supported as of now and I honestly lack the time right now to sift
though this barrage of data.
given MSVC, Clang on mac and GCC on linux currently all build without
warnings, having clang on windows match that baseline seems like a
reasonable thing to do.
I left some notes in cmake flagging the potential cleanup, and added
counts of how often each warn occurred (The one off warns are much more
likely to lead to a genuine bug fix than the ones that produce a whole
lot of noise) so if someone wants to spend some effort they can do so
effectively.
The suppression is guarded with clang on windows specific guard and
should not affect any other platforms.
Pull Request: https://projects.blender.org/blender/blender/pulls/121085
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
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
Exact an exact match with Clang broke building when the compiler ID
was "AppleClang", reverting parts of [0].
[0]: 6549019ae19cecbea524782054dca0e99cb833b8
CMake 3.27 introduced the new policy CMP0144 which makes it so the
find_Package() functions use the upper-case <package>_ROOT variable
when set. It is off by default, but it does check for the possible
interference and warns about it. The warning happens when the upper
case package root variable is set, and a find_package() is called
with a lower case package name.
In practice this leads to issue with CMake on macOS where the
TIFF_ROOT is set to an expected variable, and find_package is used
to find TIFF. THe CMake's FindTIFF.cmake attempts to find CMake
configuration of the tiff library using find_package(tiff CONFIG)
which triggers the policy warning.
This change makes it so the policy is set to NEW, silencing the
warning and bringing us to a more desired/expected behavior.
Pull Request: https://projects.blender.org/blender/blender/pulls/119120
* 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
This adds an option `WITH_EXPERIMENTAL_FEATURES` which is `ON` by default.
Sometimes it's usefull to be able to turn off all experimental features
during development for testing purposes. This option is still enforced to be
`OFF` for release cycles other than `alpha`.
Pull Request: https://projects.blender.org/blender/blender/pulls/118513
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
This adds an sse42 cpu check on startup for both linux and windows,
mac has been excluded, since there are no intel based macs that do
not support SSE42.
The way this works is, we count on the OS to initialize the shared
libraries in the order they are linked (which currently holds true)
before calling the initialization code in the main executable. This
allows us to check the CPU before running any of the code in the main
executable that might not be supported by the current isa.
Changing those build flags is for a future PR, but for now and for
future reference: blender_cpu_check must be build without optimized CPU
flags so it'll be able to run on older CPUs.
some code has been duplicated from blenlib, there's really no way around
that since we cannot link blenlib as it may be build with optimized cpu
flags.
Windows currently gives a popup to inform the user, while linux reports
to the console, there may be better ways to communicate with linux users
with perhaps some generic GUI popup, but I'm unaware of these and will
leave this for the linux platform maintainer to polish.
Part of #116592
Pull Request: https://projects.blender.org/blender/blender/pulls/118054
These are now included in the OSL shared libraries, so no reason to
link against it.
The CMake code for WITH_LLVM remains in case it is useful in the future,
but is not enabled by any Blender feature now.
Pull Request: https://projects.blender.org/blender/blender/pulls/118229
CMake 2.28.2 has a regression that breaks the combination of
precompiled headers and unity builds [1]. Disable unity builds
for this specific cmake version to sidestep the issue.
[1] https://gitlab.kitware.com/cmake/cmake/-/issues/25650
Add silently fail option to GPU based render tests. This is a pre-requisite to enable
render tests on the buildbot. By default these render tests will pass silently.
* Test will pass when using the `--pass-silently` arguments.
* Only crashes will be reported as failed tests.
* To find out failing test, review the test reports.
`WITH_GPU_RENDER_TESTS_SILENT` compile option can be used to let tests pass (default)
or fail (default for developers).
Although some tests fail, they still passed. In the generated render report,
the silently passed failures are correctly reported to be failures.
Pull Request: https://projects.blender.org/blender/blender/pulls/117629
Exceptions:
* Links to personal wiki pages
* Pages that are not in the new developer docs yet (like Human Interface Guidelines)
* tools\check_wiki\check_wiki_file_structure.py needs a refactor
Using pooljobs with default settings should never have any significant impact
on the build speed, and it makes building full debug with sanitizer builds
safe on (almost) all machines.
Quick test showed no significant difference in Release build time with or
without Ninja pooljobs (on linux, with a 16 cores, 64GBb machine).
Update the regular jobs amount computation to follow the same logic as
for the heavy ones. the main difference is that it uses a '2Gb of RAM
per job' base value.
This change is mainly targetted at machines with a relatively low
RAM/cores ratio, since even regular compile jobs can end up using quite
a lot of RAM if many are running in parallel, previous defaults would
likely not work well on machines with e.g. 16Gb of RAM and 16 cores.
Also fix a typo in previous commit (6493d0233c), sorry about that.
This commit simplifies and makes more generic the computation of the
maximum number of parallel heavy build jobs. Essentially, it allows 1
heavy job per 8Gb of RAM.
It also systematically sets the amount of heavy jobs, since we are going
to get more of these in the future (like the 'unity build' units), the
previous heuristic had some loose ends (e,g for a 40Gb RAM, 16 threads
machine, it would not set any limit to heavy jobs, yet said machine
would likely not be able to run 16 3.5+Gb heavy jobs in parallel...).
This is some initial step towards a better handling of 'sanitizer' builds
on the Blender buildbot.
Bundling many tests in a single binary reduces build time and disk space
usage, but is less convenient for running individual tests command line
as filter flags need to be used.
This adds WITH_TESTS_SINGLE_BINARY to generate one executable file per
source file. Note that enabling this option requires a significant amount
of disk space.
Due to refactoring, the resulting ctest names are a bit different than
before. The number of tests is also a bit different depending if this
option is used, as one uses gtests discovery and the other is organized
purely by filename, which isn't always 1:1.
Co-authored-by: Sergey Sharybin <sergey@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/114604
This change solves the following linker error:
ld: warning: __eh_frame section too large (max 16MB) to encode dwarf unwind offsets in compact unwind table
Proposed solution is to disable unwind table when building Blender with
address sanitizer enabled.
It is stated in the comment in the code, but to make it explicit there
could some side-effects of code which relies on frame walking:
- backtrace()
- __attribute__((__cleanup__(f)))
- __builtin_return_address(n), for n > 0
- pthread_cleanup_push when it is implemented using
__attribute__((__cleanup__(f)))
From the local tests it seems that backtrace() provides the same
output as prior to this change (but with classic linker used, as prior
to this change it is not possible to link Blender).
The rest of the possibly functionality is not used by Blender, but
it is a bit hard to tell if it is used by any of the dependent
libraries. However, if the libraries are compiled dynamically, there
will be no affect on them with this change.
I am unable to run the full test suit as some of the tests are
failing prior to this change with classic linker. Overall it seems
to be no unwanted side effects on Blender development.
Note that the change only affects debug builds with ASAN enabled,
so it is a low risk of causing some real problem so might as well
just give it a whirl and see if some unpredicted issue arises.
Pull Request: https://projects.blender.org/blender/blender/pulls/116745
The build scripts are still referring to gpu tests as being opengl.
Although they can also use Metal or Vulkan. This PR only replaces
the work `opengl` with `gpu` for build options.
Special note is that the windows argument `with_opengl_tests` is
also replaced with `with_gpu_tests` for consistency.
Pull Request: https://projects.blender.org/blender/blender/pulls/116030
Asserts historically only have been on in debug builds, however
running the tests in a debug configuration takes a while especially
if Cycles is enabled.
This adds WITH_ASSERT_RELEASE to enable asserts in release
configurations. It is enabled for "make developer" , and will also
be used for CI.
Co-authored-by: Brecht Van Lommel <brecht@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/115071
NDEBUG is part of the C standard and disables asserts. Only this will
now be used to decide if asserts are enabled.
DEBUG was a Blender specific define, that has now been removed.
_DEBUG is a Visual Studio define for builds in Debug configuration.
Blender defines this for all platforms. This is still used in a few
places in the draw code, and in external libraries Bullet and Mantaflow.
Pull Request: https://projects.blender.org/blender/blender/pulls/115774
Harfbuzz and FriBiDi are included in our external libraries for all
platforms. This PR adds the glue to make them available as optional
build components (off by default).
Pull Request: https://projects.blender.org/blender/blender/pulls/114947
Some tests like cycles, sequencer and compositor batch together multiple
tests in a single Blender invocation. This makes them run faster, but
makes debugging harder. This is an option to disable that batching.
Pull Request: https://projects.blender.org/blender/blender/pulls/114603
User a Blender wrapper `tests/utils/blender_headless.py` to runs a
graphical instance of Blender within a headless weston compositor.
Currently only WAYLAND is supported as a back-end, support for other
platforms is possible. The tests can run from X11 since the tests don't
depend on existing instances of X11 or WAYLAND.
- Each test runs a separate headless instance of WESTON
since the overhead is minimal, this allows tests to run in parallel
without interfering with each other.
- There is a CMake option WESTON_BIN, when left empty the weston
from LIBDIR is used. Otherwise this can point to the weston binary
installed on the users system.
- In most cases simulated events are needed to implement these tests
(running blender with `--enable-event-simulate`).
- This commit adds 14 undo tests - simulating user interaction as well
as undo/redo actions, ensuring the desired result is reached.
Other kinds of UI tests could be added in the future.
Ref !114164
