Implements a crash dialog for Windows.
The crash popup provides the following actions:
- Restart: reopen Blender from the last saved or auto-saved time
- Report a Bug: forward to Blender bug tracker
- View Crash Log: open the .txt file with the crash log
- Close: Closes without any further action
Pull Request: https://projects.blender.org/blender/blender/pulls/129974
Resolve CMake warning, using an undefined variable.
Don't attempt to use OSL_SHADER_DIR in it's own hint,
introduced in fix for #73830.
This was also overwriting the previous assignment from "OSL_COMPILER".
Ref !136961
This PR adds a simple patch to fix libffi compilation errors on Xcode
16.3 / Apple Clang 17. This patch has been ported from libffi Github
PR #857[1] and has now since been included in libffi 3.4.7
[1]: https://github.com/libffi/libffi/pull/857
The reason why we patch libffi v3.4.4 instead of just upgrading to 3.4.7
is that Python require specific versions of its dependencies. (See
comment in build_environment/cmake/versions.cmake about updating Python
version)
Once we upgrade Python and libffi is updated to 3.4.7 or beyond,
this patch can be safely removed.
Pull Request: https://projects.blender.org/blender/blender/pulls/136934
It's better for performance to use a single thread pool for all areas of
Blender, and this gets us closer to that.
Bullet, Quadriflow, Mantaflow and Ceres still contain OpenMP code, but it
was already disabled.
On macOS, our OpenMP libraries are no longer compatible with the latest
Xcode 16.3. By removing OpenMP we no longer have to solve that problem.
OpenMP was disabled for bpy module builds on Windows ARM64, which also no
longer needs to be solved.
Pull Request: https://projects.blender.org/blender/blender/pulls/136865
Only the parallel sparse matrix code was updated. This is used by e.g.
LSCM and ABF unwrap, and performance seems about the same or better.
Parallel GEMM (dense matrix-matrix multiplication) is used by libmv,
for example in libmv_keyframe_selection_test for a 54 x 54 matrix.
However it appears to harm performance, removing parallelization makes
that test run 5x faster on a Apple M3 Max.
There has been no new Eigen release since 2021, however there is active
development in master and it includes support for a C++ thread pool for
GEMM. So we could upgrade, but the algorithm remains the same and
looking at the implementation it just does not seem designed for modern
many core CPUs. Unless the matrix is much larger, there's too much thread
synchronization overhead. So it does not seem useful to enable that
thread pool for us.
Pull Request: https://projects.blender.org/blender/blender/pulls/136865
To make adding a dependeny on TBB easier.
Additional changes:
* Using LIB for libmv tests, as it now brings in includes
* Removing Eigen header listing in iTaSC
Pull Request: https://projects.blender.org/blender/blender/pulls/136865
Disambiguates between Apple Clang 17 (based off LLVM 19) and LLVM
Clang 17. Although an LLVM Clang 17 build is unlikely currently to
succeed on macOS, the subtle differences between the two compilers can
easily led to confusion. So clearly indicate this fix only targets Apple
Clang.
The precompiled library uses incompatible ABI with this version,
leading to linking errors.
There is no easy short-term solution: as per documentation the
OpenMP library must match LLVM version. It is hard to achieve in
a way that both older and newer LLVM versions are supported: it
would need to be multiple OpenMP libraries pre-compiled and chosen
at the build time.
There are not that many places left in Blender when OpenMP is
still used, so it seems better to invest in getting of those
remaining cases. The most challenging one would be Eigen, but
need to check whether the code-paths that are used from Eigen
even contain OpenMP.
Pull Request: https://projects.blender.org/blender/blender/pulls/136828
This is done because the library is necessary to make certain FFTW
functions thread safe, see #136557 as well.
Also pass each library variable separately to
`find_package_handle_standard_args` instead of as a list, as otherwise
it won't correctly detect if `libfftw3f` or `libfftw3f_threads` is
missing. This is because CMake considers a value false if it contains
`-NOTFOUND` at the end, but not if it's in the middle. For example,
CMake considers
`.../libfftw3f.a;.../libfftw3f_threads.a;FFTW3_LIBRARY_D-NOTFOUND` to be
false, but
`.../libfftw3f.a;FFTW3_LIBRARY_THREADS_F-NOTFOUND;.../libfftw3.a` to be
true.
---
I noticed that some other find modules also have the same list issue. I guess it was done this way to make CMake print all the found libraries instead of only the first.
Pull Request: https://projects.blender.org/blender/blender/pulls/136692
The issue is caused by the fact that when both compositors are used,
`fftwf_plan_dft_r2c_2d` can end up being called in parallel, which is
only thread-safe if `fftwf_make_planner_thread_safe` is called before.
This is done by `fftw::initialize_float`, but only if the FFTW threading
support library is available. Said library was not detected correctly on
Windows because of a typo, which this change addresses. This should also
make the fog glow faster on Windows because it'll now use multithreaded
FFT as intended.
This change also moves the call to `initialize_float` to the main
function because the FFTW functions it calls are not thread-safe and
because FFTW is also used by Audaspace, which cannot call it.
Pull Request: https://projects.blender.org/blender/blender/pulls/136557
bpy is not compatible with numpy 2+, as the VFX reference platform uses
1.26 atm. This fix amended the install requirement package to specify
numpy>=1.26,<2.0 to mitigate this issue.
Suggested by Brandy Johnston (@bradyajohnston)
Pull Request: https://projects.blender.org/blender/blender/pulls/134551
The platform tag came from virtualized CPU on which Python 3.9 is
running on the buildbot.
Use the same trick to detect the host CPU as for the message on the
splash screen.
Pull Request: https://projects.blender.org/blender/blender/pulls/136085
DEPENDS is not supported for post_build commands and recent
cmake versions have started emitting warnings about that.
This can be safely removed, as cmake has been silently ignoring
the keyword for years.
This is primarily to solve Intellisense failures with various USD
header files and macros. However, it also unifies Windows x64 with
Windows arm64 (though MSVC is unused for arm64 currently) since it would
be required for proper `sse2neon` support anyhow.
Pull Request: https://projects.blender.org/blender/blender/pulls/135844
PR as discussed on the thread for #134676.
Works by disabling dependent load flag in OIDN, and also switching off OpenMP.
The OIDN bit is just a workaround until they can resolve this properly on their side by fixing the manifest.
The OpenMP bit requires more investigation regarding delayed loading.
Pull Request: https://projects.blender.org/blender/blender/pulls/135319
This makes it so that we ship the test data for every major release
in its own separate archive. (In case someone wants to easily run the
tests for a specific older release without using git)
Pull Request: https://projects.blender.org/blender/blender/pulls/135293
Quite obscure issue, seemingly caused by the fact that HIP-RT is
passing a large (about 20 MB) global array to a different library
(HIP driver, via hipModuleLoadData). Having global variables of
such size seems to be always problematic as they can not be stored
on stack and, possibly, extra mapping is involved here. It is not
clear whether it is a quirk of the HIP driver, or Linux, or, maybe,
something completely different.
It is possible to work-around the problem by making a temporary
copy of data on heap memory and pass it to the hipModuleLoadData().
This is how other areas are dealing with modules in Blender.
This change contains patch against HIP-RT and the new HIP-RT
library compiled with the patch. It seems to fix the problem
reported in the report.
This change does not resolve OIDN on HIP GPU which seems to have
the same issue. However, it is not a recent regression and the
bug with OIDN GPU denoising can be reproduced using Blender 4.3.
Pull Request: https://projects.blender.org/blender/blender/pulls/135403
Seems like ASAN has been broken on debug builds for MSVC ever since
d5e50460e7 (1.5 years ago) the core reason is it's incompatible with
fastlink, it'll appear to work, but in the asan reports no symbols
will be resolved.
While looking into this, some other problems like the symbol format being
not inline with the table in the comment above it, and a warning coming
out of /extern were noted.
All of these issues are addressed in this commit.
This change brings the following improvements on the user level
- Support of GPUs with gfx12 architecture
- New HIP-RT library which in addition to the gfx12 support brings
various bug-fixes.
The known limitation of gfx12 is that OpenImageDenoiser does not yet
support this GPU architecture. This means that while Cycles will use the
full advantage of the gfx12 (including hardware accelerated ray-tracing),
denoising will only be possible on CPU, or secondary gfx11 or below GPU.
This is something that requires a change in OIDN and it is to late to do
it for Blender 4.4, but it is something to look forward for Blender 4.5.
The gfx12 changes for the pre-compiled kernels is rather trivial,
so it comes together (in the same PR) as the bigger HIP-RT change.
On the development side this change brings the following improvements:
- One step compile and link (much simpler CMake rules)
- Embedding BVH binaries in hiprt dll (which makes it easier to package
and load, without relying on special path configuration)
Co-authored-by: Sahar Kashi <sahar.kashi@amd.com>
Co-authored-by: Sergey Sharybin <sergey@blender.org>
Co-authored-by: Brecht Van Lommel <brecht@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/133129
This switches clang to be the default compiler on Windows ARM64, allowing for an override to MSVC.
Turns out MSVC builds have been broken for months, but nobody checked, so I'm just switching them off for now and setting clang as the default.
These updated scripts allow for the msbuild generator to use an external (ie, non-MSVC) clang installation properly, otherwise they failed.
They also allow for users to specify their own desired clang compiler via an environment variable.
An update to the docs will come seperately.
Pull Request: https://projects.blender.org/blender/blender/pulls/134566
the static crt was selected, which isn't a problem as crt
object aren't passed between the host and the shared lib
still it's be nice to use the same runtime between both.
`SHADERC_ENABLE_SHARED_CRT` is a msvc specific option and
doesn't affect other platforms.
also switch build system from msbuild to ninja on windows.
this brings down the shaderc build time from 185 to 47 seconds
for the release libs, and 224 to 53 for the debug libs
total savings: 5 minutes!
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
