| Age | Commit message (Collapse) | Author |
|---|
|
Latest Xcode takes up 15GB, command line tools are only 1.2GB.
|
|
* WITH_CPU_SSE was renamed to WITH_CPU_SIMD, and now covers both SSE and Neon.
* For macOS sse2neon.h is included as part of the precompiled libraries.
* For Linux it is enabled if the sse2neon.h header file is detected. However
this library does not have official releases and is not shipped with any Linux
distribution, so manual installation and configuration is required to get this
working.
Ref D8237, T78710
|
|
This required using a fork of Embree, newer LLVM version, unreleased ISPC
version and sse2neon directly from Git. Hopefully over time all the required
changes end up in official releases. For now we deviate from other platforms.
Based on contributions by Apple and Stefan Werner.
Ref D9527, D8237, T78710
|
|
Ref T84819
Build System
============
This is an API breaking new version, and the updated code only builds with
OpenColorIO 2.0 and later. Adding backwards compatibility was too complicated.
* Tinyxml was replaced with Expat, adding a new dependency.
* Yaml-cpp is now built as a dependency on Unix, as was already done on Windows.
* Removed currently unused LCMS code.
* Pystring remains built as part of OCIO itself, since it has no good build system.
* Linux and macOS check for the OpenColorIO verison, and disable it if too old.
Ref D10270
Processors and Transforms
=========================
CPU processors now need to be created to do CPU processing. These are cached
internally, but the cache lookup is not fast enough to execute per pixel or
texture sample, so for performance these are now also exposed in the C API.
The C API for transforms will no longer be needed afer all changes, so remove
it to simplify the API and fallback implementation.
Ref D10271
Display Transforms
==================
Needs a bit more manual work constructing the transform. LegacyViewingPipeline
could also have been used, but isn't really any simpler and since it's legacy
we better not rely on it.
We moved more logic into the opencolorio module, to simplify the API. There is
no need to wrap a dozen functions just to be able to do this in C rather than C++.
It's also tightly coupled to the GPU shader logic, and so should be in the same
module.
Ref D10271
GPU Display Shader
==================
To avoid baking exposure and gamma into the GLSL shader and requiring slow
recompiles when tweaking, we manually apply them in the shader. This leads
to some logic duplicaton between the CPU and GPU display processor, but it
seems unavoidable.
Caching was also changed. Previously this was done both on the imbuf and
opencolorio module levels. Now it's all done in the opencolorio module by
simply matching color space names. We no longer use cacheIDs from OpenColorIO
since computing them is expensive, and they are unlikely to match now that
more is baked into the shader code.
Shaders can now use multiple 2D textures, 3D textures and uniforms, rather
than a single 3D texture. So allocating and binding those adds some code.
Color space conversions for blending with overlays is now hardcoded in the
shader. This was using harcoded numbers anyway, if this every becomes a
general OpenColorIO transform it can be changed, but for now there is no
point to add code complexity.
Ref D10273
CIE XYZ
=======
We need standard CIE XYZ values for rendering effects like blackbody emission.
The relation to the scene linear role is based on OpenColorIO configuration.
In OpenColorIO 2.0 configs roles can no longer have the same name as color
spaces, which means our XYZ role and colorspace in the configuration give an
error.
Instead use the new standard aces_interchange role, which relates scene linear
to a known scene referred color space. Compatibility with the old XYZ role is
preserved, if the configuration file has no conflicting names.
Also includes a non-functional change to the configuraton file to use an
XYZ-to-ACES matrix instead of REC709-to-ACES, makes debugging a little easier
since the matrix is the same one we have in the code now and that is also
found easily in the ACES specs.
Ref D10274
|
|
|
|
Default to Python version 3.9.
Reviewed By: LazyDodo, sybren, sebbas
Ref D10380
|
|
Paths and names of system packages-installed libhpdf on Debian (and
probably its derived distributions?) are slightly different than what
was given to CMake finding script.
|
|
Since GPencil changes depending on libharu may be committed to master
before SVN libraries for all platforms are in place, avoid build issues.
Extension of D9928.
Reviewed By: sybren
Differential Revision: https://developer.blender.org/D10280
|
|
|
|
Standard wiki build instructions for building Blender on macOS can now be used
on Macs with ARM processors.
This contains all libraries except for Embree and OpenImageDenoise, so Cycles
performance does not yet have full performance and features in this build. An
x86-64 build is likely to still render faster than arm64 until Embree is added.
Uses the new lib/darwin_arm64 folder. For simplicity and to keep download size
under control, both for end users and builders, we are not planning to ship
universal binaries. So this is a separate folder from lib/darwin.
Ref T78710
Differential Revision: https://developer.blender.org/D10276
|
|
|
|
Haru depends on some symbols defined in libtiff
which will cause linker errors if not enabled.
Disable haru if WITH_IMAGE_TIFF is off.
|
|
Decision: https://lists.blender.org/pipermail/bf-committers/2020-December/050836.html
Adds CMake dependency builder support. Tested on
macOS and Windows (Thanks @LazyDodo).
Reviewed By: #platform_macos, LazyDodo, sebbas
Maniphest Task: T84836
Differential Revision: https://developer.blender.org/D9928
|
|
Don't overwrite environment variables that may
contain options like suppression files, symboliser etc.
It's similar to rBa181b156399a13fa429159112e30c8005d5e8a59
and rBA589d13408a60cbec34a8bc3cc798c586043743ae .
For Blender Add-ons repo, see the equivalent in D9816.
Reviewed By: Blendify
Differential Revision: https://developer.blender.org/D9815
|
|
|
|
Add them to the standard build configurations, disable properly when library
not found and print as part of configuration overview.
|
|
Much more could be done here, some obvious corrections.
|
|
|
|
When building with more aggressive optimization flags, GCC will add FMA
(Fused Multiply Add) instructions that will slightly alter the floating
point operation results.
This causes some automated tests to fail in blender.
In clang and the intel compiler ffp-contract is set to off per default
it seems from my research. (They do not have the exact same setting,
but the default seems to match the off behavior)
Reviewed By: Brecht
Differential Revision: http://developer.blender.org/D9047
|
|
|
|
Group all tests of a test suite into a single test command invocation.
This reduces the number of invocations by `ctest` by an order of
magnitude.
Since rB56aa5b0d8c6b663, `bin/tests/blender_test` was run for every
individual test. Having over a 1000 tests made testing slower than
necessary. Individual tests can still be run if desired by invocation of
`bin/tests/blender_test --gtest_filter=suitename.testname`.
NOTE: For this commit to have an immediate effect, it may be necessary
to remove the `tests` and `Testing` directories and some CMake files
from your build directory and rebuild. Run `ctest -N` to see the list of
tests; there should be less than 200.
Reviewed By: sergey, LazyDodo, sebbas
Maniphest Tasks: T83222
Differential Revision: https://developer.blender.org/D9649
|
|
Use python3 which is now supported,
only use CLANG_BIND_DIR & CLANG_LIB_DIR when they are set.
Also add immediate mode GPU API function calls.
|
|
This adds an option (WITH_COMPILER_CCACHE) to build using Ccache if it's
found. Makefiles-based, Ninja-based and Xcode generators are supported.
Pass `-DWITH_COMPILER_CCACHE=ON` to cmake to enable Ccache.
Utility option in GNUmakefile is also added: for e.g.,
`make ninja ccache`.
Reviewed By: brecht, ankitm
Differential Revision: https://developer.blender.org/D9665
|
|
Issues were:
* Abusing of `WITH_PYTHON_INSTALL_NUMPY` by both Audaspace and
Mantaflow.
- `PYTHON_INSTALL` options only decide whether we copy python (and
some extra modules) in our Blender installation. On linux it
makes much more sense to use global python installation.
- Now we have instead a proper `WITH_PYTHON_NUMPY`
* Bad assumptions regarding path of headers relative to path of python
module.
- In current Debian testing, modules are under `python3.9`
directory, while headers are under `python3` directory.
- Now we properly `find_path` for headers as well, modifying
`find_python_package` to take an optional argument for headers.
Note that the required changes done to `extern` libraries are in
blender-specific files that do not exist upstream.
Differential Revision: https://developer.blender.org/D9773
|
|
This reverts commit 5d570c875eda8fb9aa3635f7f4edac0dc1eaedc8.
Buildbots are still borken, need more time to investigate.
|
|
Issues were:
* Abusing of `WITH_PYTHON_INSTALL_NUMPY` by both Audaspace and
Mantaflow.
- `PYTHON_INSTALL` options only decide whether we copy python (and
some extra modules) in our Blender installation. On linux it
makes much more sense to use global python installation.
- Now we have instead a proper `WITH_PYTHON_NUMPY`
* Bad assumptions regarding path of headers relative to path of python
module.
- In current Debian testing, modules are under `python3.9`
directory, while headers are under `python3` directory.
- Now we properly `find_path` for headers as well, modifying
`find_python_package` to take an optional argument for headers.
Note that the required changes done to `extern` libraries are in
blender-specific files that do not exist upstream.
Differential Revision: https://developer.blender.org/D9773
|
|
|
|
This enables the use of clang-tidy in the VS IDE.
To use it:
1 - Enable WITH_CLANG_TIDY in your cmake configuration
2 - From the Analyse pull down menu select Run Code Analysis on...
The analyser is currently not enabled by default on build
given it is quite slow and there are quite a few problems
it reports that we still need to deal with.
|
|
This commit expands the Windows-specific code in rBdca9aa0053f7 and Linux-specific code in rB33b7d53df08a.
It also fixes a capitalization issue in FindPugiXML.cmake
|
|
PugiXML was historically shipped hidden embedded into OIIO, the Grease
Pencil team had a requirement for an XML library recently so pugi seems
like a natural choice since it's not really a 'new' library, we just
turn an implicit dependency into an explicit one.
This commit expands the Windows-specific code in rBdca9aa0053f7 to
include Linux. macOS support will be handled in a later commit.
NOTE: run `cmake -U'*PUGIXML*' .` in the build directory to ensure CMake
finds PugiXML in the new location.
For details see D8628
|
|
This separates out PugiXML that was previously
bundled by OIIO.
As this linux/mac libs are not available
this commit only contains the builder and windows
changes, and the option to enable pugixml is
guarded by a platform if, this can be removed
once all platforms have committed the svn libs.
For details see D8628
|
|
Reviewed By: ankitm
Maniphest Tasks: T83174
Differential Revision: https://developer.blender.org/D9664
|
|
Replace `Blender` with `BLENDER` so that it's more clearly a marker, and
not just the name.
No functional changes.
|
|
Left out in {rB7f28a99dd5a57216fb477d844ae1fec5510ad5d5}
|
|
Causes link issues on Xcode's "New Build System" which was introduced
in Xcode 10 and is default on Xcode 12.
https://devtalk.blender.org/t/16273
Differential Revision: https://developer.blender.org/D9624
Reviewed by: brecht, #platform_macos
|
|
This caused warnings when e.g. building the lite profile because NanoVDB was not disabled, but
OpenVDB was. This Fixes this by setting the "WITH_NANOVDB" flag too.
|
|
For blender we disable VCPKG to prevent it from picking
up the wrong libraries from VCPKG rather than our lib folder
some of the cycles tests needed this to link correctly.
reported by @alef on chat
|
|
Stop with an error when the Clang-Tidy executable cannot be found.
Without this check, CMake will happily report "Found Clang-Tidy" but with
the fallback version (0, 0, 0), when `CLANG_TIDY_EXECUTABLE` points to a
non-existing executable.
|
|
Using configue_file(..) would have avoided the breakage from
1daa3c3f0a1cfd, caused by buildinfo not properly escaping quotes.
Rely on CMake to escaping strings instead using configure_file().
|
|
Replace 'set' with 'string(APPEND/PREPEND ...)'.
This avoids duplicating the variable name.
|
|
|
|
|
|
Until it is decided whether to ship JACK with pre-compiled libraries,
search for the same in system directories.
Ref T79261
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D9436
|
|
|
|
The old code was added in {rBbaa4a9c7d4dd}
While the hotfix committed in {rB2ddecfffc3d3a3a1db4ae45e8665ca} fixed
the id_management test, the correct reason was found at
https://bugs.llvm.org/show_bug.cgi?id=47984
This matches the behavior on Linux.
|
|
Setting the stack size only works for executables, for shared libraries
the host application controls it.
|
|
Revert part of {rB83124856d05ee4da605ab247e6}
|
|
This is a stricter version of the change made in
{rBbb872b25f219d1a9bc2446228b6dc}
Cmake must never look into Frameworks when the system
library guards (`without_system_libs_begin`/`without_system_libs_end`)
are present.
OpenAL didn't follow this and OpenAL.framework in Xcode would be used.
The Cmake's `FindOpenAL.cmake` looks for both library (in this case,
the .framework file), and include dir.
Precompiled libraries don't contain the former. So `find_package`
cannot be used, or it becomes the hack that {rBb2c707747da9} removed.
So hardcode the include dir path, and other variables.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D9267
|
|
https://devtalk.blender.org/t/libpng-version-mismatch/15799/
By default, `CMAKE_FIND_FRAMEWORK` is `FIRST`.
CMake searches headers and libraries separately. So library is found
in LIBDIR, and headers like those in Mono are detected before the
headers in LIBDIR, and we get a version mismatch.
So set the priority of Frameworks to `LAST`.
https://gitlab.kitware.com/cmake/cmake/-/issues/18921
https://gitlab.kitware.com/cmake/cmake/-/issues/16427
{rBbac91956ae97} tried to fix the same issue, but it didn't work.
It's fine to keep the changes made there, just removing the comment
that may give false sense of security.
|
|
{rB1f6b7387ad01}
|
