Age | Commit message (Collapse) | Author |
|
Fixed a couple of typos in comments in CMakeLists.txt and GNUmakefile
Reviewed By: #platforms_builds_tests, mont29
Differential Revision: https://developer.blender.org/D9261
|
|
With this patch the build system checks whether the "CUDA10_NVCC_EXECUTABLE" CMake
variable is set and if so will use that to build sm_30 kernels. Similarily for sm_8x kernels it
checks "CUDA11_NVCC_EXECUTABLE". All other kernels are built using the default CUDA
toolkit. This makes it possible to use either the CUDA 10 or CUDA 11 toolkit by default and
only selectively use the other for the kernels where its a hard requirement.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D9179
|
|
`APPLE` platform handles ASan compiler and linker flags using
`add_compile_options` and `add_link_options`. {rB74bcb32c9f02}
Arguments in `CMAKE_{LANG}_FLAGS{_CONFIG}` are also passed to
`try_compile` which will fail due to linker errors, since link flags
are not set. `try_compile` is used by `find_package(Boost)` for
`thread` library.
See CMP0066 [1] also.
[1] https://cmake.org/cmake/help/latest/policy/CMP0066.html
Ref D8855
|
|
NanoVDB is a platform-independent sparse volume data structure that makes it possible to
use OpenVDB volumes on the GPU. This patch uses it for volume rendering in Cycles,
replacing the previous usage of dense 3D textures.
Since it has a big impact on memory usage and performance and changes the OpenVDB
branch used for the rest of Blender as well, this is not enabled by default yet, which will
happen only after 2.82 was branched off. To enable it, build both dependencies and Blender
itself with the "WITH_NANOVDB" CMake option.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D8794
|
|
I didn't realize there were more duplicates while committing
{rBf1fee433be92}.
Original was added in {rB83f8223543f58c3b0881a03b6e9ddffff91}.
Duplicate was added in the merge {rB9e09b5c418c0a436e3c84ccf}.
Ref D8822
|
|
Setting `PLATFORM_LINKLIBS` is not required for clang, compiler and
linker flags are enough. Note that the change made in
{rBa4c5811e2127}) to `platform_apple.cmake` (appending to
`PLATFORM_CFLAGS`) has not been reverted. platform file shouldn't be
overwriting the flags.
`PLATFORM_LINKFLAGS` is overwritten by `platform_apple.cmake`, so no
point in setting it. Fixing that like `PLATFORM_CFLAGS` is out of the
scope of this change.
`PLATFORM_LINKFLAGS_DEBUG` has been replaced with generator expression
to include RelWithDebInfo and MinSizeRel build types also.
|
|
All platforms have landed the libs, this can be on
by default now.
|
|
Set flags directly on the target, and use common function for all cases.
This refactoring helps with the next commit for test executables.
Ref D8714
|
|
While testing for {rB40dcf686f04f}, compiler flags got mixed up and
non-working ASan configuration was committed.
Platform file, which is `include`d after the `CMAKE_C_FLAGS_DEBUG` etc.,
are set, overwrites those flags instead of appending to them. To fix this,
`PLATFORM_CFLAGS` is used to pass the `-fsanitize=*` flags to the C/C++
compiler.
Tested on fresh build using both Xcode and Ninja, with & without ccache.
Also silence a clang warning for multi-config generators:
the object size sanitizer has no effect at -O0, but is explicitly
enabled: -fsanitize=object-size [-Winvalid-command-line-argument]
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D8879
|
|
For work the GP team plans to land soon (T79877) potrace was taken
on as an additional optional dependency.
This diff adds building the library to the deps builder and takes
care of the integration into the build-system with the `WITH_POTRACE`
cmake switch.
Differential Revision: https://developer.blender.org/D8662
Reviewed by: brecht, sergey
|
|
Introduced in rB40dcf686f04f7db8110f9c85621eb8a0bd764080
|
|
This makes it error-proof to disable/enable experimental features
during the release cycles. Since it is handled by CMake it should always
work reliably now (not depending on someone turning this on and off).
Reviewed by Sergey Sharybin.
|
|
Similar to {rB0a5f7061369d53b4eac55362ad2}
but also for Xcode and Ninja multi-config.
This silences 44 pairs of warnings like:
/bin/rm -f build_full/bin/tests/BLI_ghash_performance_test
"build_full/CMakeScripts/XCODE_DEPEND_HELPER.make:42: warning:
ignoring old commands for target
`build_full/bin/tests/BLI_ghash_performance_test'"
/bin/rm -f build_full/bin/tests/BLI_ghash_performance_test
"build_full/CMakeScripts/XCODE_DEPEND_HELPER.make:3523: warning:
overriding commands for target
`build_full/bin/tests/BLI_ghash_performance_test'"
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D8815
|
|
This change allows macOS developers to use
`WITH_COMPILER_ASAN` with every generator.
`CMAKE_C_IMPLICIT_LINK_DIRECTORIES` on macOS points to
`Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/lib`
which is not where the Sanitizer libraries are.
To link the library, rpath could be used but that seems complex,
so linker flags are passed as the documentation says. [1]
If users have `ASAN_OPTIONS=detect_leaks=1` in their environment
variables, it should be removed to avoid a feature-unsupported error
while compiling.
[1]: http://clang.llvm.org/docs/AddressSanitizer.html#usage
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D8817
|
|
This is for design task T67744, Boolean Redesign.
It adds a choice of solver to the Boolean modifier and the
Intersect (Boolean) and Intersect (Knife) tools.
The 'Fast' choice is the current Bmesh boolean.
The new 'Exact' choice is a more advanced algorithm that supports
overlapping geometry and uses more robust calculations, but is
slower than the Fast choice.
The default with this commit is set to 'Exact'. We can decide before
the 2.91 release whether or not this is the right choice, but this
choice now will get us more testing and feedback on the new code.
|
|
MSVC already builds with the /std:c++17 flag but for
'reasons' [1] MSVC still gives the wrong value for the
__cplusplus define.
This change sets an additional cxx flag on supported
compilers to allow the compiler properly identify
C++17 support.
This resolves 2 warnings coming out of bullet about
the register keyword being deprecated.
[1] https://devblogs.microsoft.com/cppblog/msvc-now-correctly-reports-__cplusplus/
|
|
When the OSL_ROOT variable is set this is ignored
by findpackage on cmake < 3.12. CMake 3.12 and up
also ignore it and warn about it. This change
tells cmake it is OK to use the variable and
stop warning
|
|
During alpha the user preferences > experimental featuers are available
to prevent merge issues and allow developers to seek feedback.
This needs to be manually turned off when we branch for beta, otherwise
the RNA of the incomplete features will be exposed.
|
|
I turned on the wrong feature in cmake.
This reverts commit bdf43213b25d21528dfa89dc9aeaa41f8d92116e.
|
|
Remember to turn this off again when we branch out for the next beta (2.91)
|
|
|
|
For 2.90 release this should not be exposed in the RNA API.
In master this needs to be ON by default, that's all.
Differential Revision: https://developer.blender.org/D8589
|
|
Required for the new boolean code, disabled by default
until all platforms have landed the libs and the boolean
code actually lands in master.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D8384
|
|
This bumps the minimally required CMake version from 3.5 to 3.10, as
discussed in D8405.
Since D7649 landed, there has been the `gtest_discover_tests()` call to
discover individual unit tests in `bin/tests/blender_test`. This
function was introduced in CMake 3.10.
Since there were no complaints about this incompatibility, I suspect
that a newer version is already in use by the majority of the
Blender-building people.
|
|
one is found
This patch changes the discovery of pre-compiled kernels, to look for any PTX, even if
it does not match the current architecture version exactly. It works because the driver can
JIT-compile PTX generated for architectures less than or equal to the current one.
This e.g. makes it possible to render on a new GPU architecture even if no pre-compiled
binary kernel was distributed for it as part of the Blender installation.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D8332
|
|
This commit introduces a new way to build unit tests. It is now possible
for each module to generate its own test library. The tests in these
libraries are then bundled into a single executable.
The test executable can be run with `ctest`. Even though the tests
reside in a single executable, they are still exposed as individual
tests to `ctest`, and thus can be selected via its `-R` argument.
Not yet ported tests still build & run as before.
The following rules apply:
- Test code should reside in the same directory as the code under test.
- Tests that target functionality in `somefile.{c,cc}` should reside in
`somefile_test.cc`.
- The namespace for tests is the `tests` sub-namespace of the code under
test. For example, tests for `blender::bke` should be in
`blender::bke:tests`.
- The test files should be listed in the module's `CMakeLists.txt` in a
`blender_add_test_lib()` call. See the `blenkernel` module for an
example.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D7649
|
|
Enabling all `make deps` dependencies with the exception of Embree and OIDN.
After that, Blender can be compiled on an Apple Silicon Mac just like on any
Intel based Mac. There are still compiler warnings that need to be
investigated and there are probably a couple of bug still to be discovered
and to be fixed.
Most patches to the dependencies are simple and are about disabling SSE and
setting the proper architecture to compiile for. Notable exception is Python,
where I back ported a yet to be accepted PR for upstream Python:
https://github.com/python/cpython/pull/21249
Cross compiling or buliding a Universal Binary is not supported yet.
The minimum macOS target version for x86_64 remains at 10.13, the target
for arm64 is 11.00.
Differential Revision: https://developer.blender.org/D8236
|
|
|
|
Clang Tidy is a Clang based "linter" tool which goal is to help
fixing typical programming errors.
It is run as a separate compile step of every file, which slows
compilation down but allows to fully analyze the file the same
way as compiler does and catch non-trivial bugprone cases.
This change includes:
- CMake option called `WITH_CLANG_TIDY` which enables Clang Tidy
linter tool on all source in the `source/` directory.
This option is only available on Linux, as it is currently the
easiest platform to get the Clang Tidy toolchain to work.
- CMake module which is aimed to find latest available Clang Tidy.
- Set of rules which allows to have Blender fully compiled without
extra issues.
The goal of this change is to provide a base ground so that solving
all the warnings can happen later on, as a team effort.
It should be possible to use Clang Tidy side-by-side with both GCC
and Clang, but there seems to be some tweaks to be done in CMake to
make it really work for Blender. For now use Clang toolchain if
there are issues with GCC+Clang Tidy.
It will be worked on in the nearest future to bring seamless
experience for all configurations.
Currently there is no official way of getting Clang Tidy on macOS,
and on Windows there are some difficulties of hooking up Clang Tidy
from LLVM package to the MSVC compiler toolchain.
The actual warnings in the code will be addressed as a part of the
Code Quality Days, task T78535.
Differential Revision: https://developer.blender.org/D7937
|
|
This replaces the cmake options `WITH_NEW_OBJECT_TYPES` and
`WITH_NEW_SIMULATION_TYPE` with two experimental userpref settings:
* `use_new_particle_system`: Enables the point cloud type and the simulation editor.
* `use_new_hair_type`: Only displays the add-operator in the add menu for now.
Note, in the current state you can't do anything productive with the new particle
system or the new hair type. Features will be added step by step in the upcoming
weeks and months.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D8096
|
|
For GPU debugging purposes, it is still possible to render with the same BVH2
on the CPU using the Debug panel in the render properties.
Note that building Blender without Embree will now lead to significantly reduced
performance in CPU rendering, and a few of the Cycles regression tests will fail
due to small pixel differences.
Ref T73778
Depends on D8014
Maniphest Tasks: T73778
Differential Revision: https://developer.blender.org/D8015
|
|
Now that the rest of Blender also relies on TBB, no point in maintaining custom
code for paraller_for and thread local storage.
|
|
Was only happening on unsupported compilers.
|
|
Ref T76783
|
|
Using latest master because of various compilation error fixes.
Brings a lot of recent development. From most interesting parts:
- New threading model.
- Tiny solver.
- Compatibility with C++17.
|
|
This is an intermittent state to get all dependencies to compile.
For example, the latest Ceres is needed to bring C++17 support,
but it has bumped minimal requirement to C++14.
|
|
This is a follup to 0c384362272.
No functional changes to Blender, just the build scripts.
|
|
|
|
No longer enforce WITH_HEADLESS when building as a Python module
as it disables GPU access which is needed for rendering.
|
|
|
|
Having USD disabled by default was an oversight, and could have been
corrected earlier. It's already enabled by default in the
`blender_release.cmake` and `blender_full.cmake`.
|
|
|
|
This diff add supports for crash logs on windows for
release builds. This can be toggled on/off with the
`WITH_WINDOWS_PDB` cmake option. by default it is on.
Things to take into consideration:
Release builds are hightly optimized and the resulting
backtraces can be wrong/misleading, take the backtrace
as a general area where the problem resides rather than
an exact location.
By default we ship a minimized symbol file that can only
resolve the function names. This was chosen to strike
a balance between growth in size of the download vs
functionality gained. If more detailed information is
required such as source file + line number information
a full pdb can be shipped by setting `WITH_WINDOWS_STRIPPED_PDB`
to off.
Differential Revision: https://developer.blender.org/D7520
Reviewed by: brecht
|
|
- Support building only with Wayland.
- In this case, show useful error messages
when Wayland fails to load.
|
|
Matches WITH_GHOST_{SDL|WAYLAND}
|
|
Issues with older cmake.
|
|
This diff add supports for crash logs on windows for
release builds. This can be toggled on/off with the
`WITH_WINDOWS_PDB` cmake option. by default it is on.
Things to take into consideration:
Release builds are hightly optimized and the resulting
backtraces can be wrong/misleading, take the backtrace
as a general area where the problem resides rather than
an exact location.
By default we ship a minimized symbol file that can only
resolve the function names. This was chosen to strike
a balance between growth in size of the download vs
functionality gained. If more detailed information is
required such as source file + line number information
a full pdb can be shipped by setting `WITH_WINDOWS_STRIPPED_PDB`
to off.
The Release in the title of this diff refers to the
release build type, not the official blender releases.
Initially this will only be enabled for nightly build
bot versions of blender, official releases as of now
will not ship with symbols.
Differential Revision: https://developer.blender.org/D7520
Reviewed by: brecht
|
|
Usable with the CMake option 'WITH_GHOST_WAYLAND'
The following functionality is working:
- Building with X11 and Wayland at the same time,
wayland is used when available.
- Keyboard, pointer handling.
- Cursor handling.
- Dedicated off-screen windows.
- Drag & drop.
- Copy & paste.
- Pointer grabbing.
See D6567 for further details.
|
|
Can give considerably faster linking, especially for debug builds.
This may be enabled by default but needs to be more thoroughly tested.
|
|
CentOS on the buildbot still runs Python 3.6, which is also used for the
unit tests. This means that the tests can't use language features that
are available to Blender itself. And testing with a different version of
Python than will be used by the actual code seems like a bad idea to me.
This commit adds `TEST_PYTHON_EXECUTABLE` as advanced CMake option. This
will allow us to set a specific Python executable when we need it. When
not set, a platform-specific default will be used:
- On Windows, the `python….exe` from the installation directory. This is
just like before this patch, except that this patch adds the
overridability.
- On macOS/Linux, the `${PYTHON_EXECUTABLE}` as found by CMake.
Every platform should now have a value (configured by the user or
detected by CMake) for `TEST_PYTHON_EXE`, so there is no need to allow
running without. This also removes the need to have some Python files
marked as executable.
If `TEST_PYTHON_EXE` is not user-configured, and thus the above default
is used, a status message is logged by CMake. I've seen this a lot in
other projects, and I like that it shows which values are auto-detected.
However, it's not common in Blender, so if we want we can either remove
it now, or remove it after the buildbot has been set up correctly.
Differential Revision: https://developer.blender.org/D7395
Reviewed by: campbellbarton, mont29, sergey
|