This bumps OSL to 1.11.10.0. OSL Has a new build time
dependency: Clang, and more importantly it expects
clang and llvm to share a library folder, which it
previously for us did not.
This patch changes:
-OSL Update to 1.11.10.0
-refactor the llvm/clang/clang-tools-extra builds into the llvm
build using the llvm-project tarball for building that has all
of the subprojects in it.
-update ispc/openmp builds since clang no longer its own dependency
and they have to depend on the llvm build now.
-Update the windows builder to use the 64 bit host tools since it
ran out of ram linking clang
-Since OSL now needs clang to link successfully a findclang.cmake
has been provided for linux/OSX
Differential Revision: https://developer.blender.org/D10212
Reviewed By: brecht, sebbas, sybren
rBc70eb30240f8b5d5a8f2ac509f0eb585936142b5 added patch to use static
zlib on Linux. But also added flags to use the zlib in LIBDIR for
Python on macOS. That causes some shared libraries (binascii for one)
to link against libz.1.dylib which will not be there on users' systems.
Reuse the said patch for macOS also to avoid rpath issues.
Fix T85648.
Reviewed By: #platform_macos, brecht
Differential Revision: https://developer.blender.org/D10479
This updates platform/platform_win32.cmake to support
both the old and new library names for OpenXR.
The new version links against one additional system
library and the debug library filename changed ever
so slightly.
This is a temporary workaround and can be removed
once the new lib versions have landed.
Rather than hardcoding the lib names, read
boosts version.hpp and extract the version
from there.
This will make it easier to land lib changes
in the near future.
* 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
Building NumPy from source with default options of builder
causes it to link against Accelerate framework which is buggy and
raises a warning mentioned in [2].
"RankWarning: Polyfit may be poorly conditioned"
Accelerate is deprecated with NumPy 1.20+.[1]
So either we build OpenBLAS in dependencies also and set appropriate
env variables suggested in [1] while building NumPy for it to find
OpenBLAS. Or download NumPy wheel from pip and never allow pip to
build NumPy from source while installing.
After this change, pip wheels are used for NumPy for macOS with x86_64.
[1] https://numpy.org/doc/stable/user/building.html#lapack
[2] https://github.com/numpy/numpy/issues/15947
Reviewed By: #platform_macos, sebbas
Differential Revision: https://developer.blender.org/D10368
USD version 21.02 includes two of the changes Blender used to patch in,
which have now been removed from `usd.diff`. Unfortunately 21.02
introduces another issue where LZ4 symbols are accidentally exported,
causing linker errors. Fortunately these symbols are only used for
resting, so I added a patch hunk that simply removes their `extern "C"`
declaration.
The LZ4 linker issue has been reported upstream at
https://github.com/PixarAnimationStudios/USD/issues/1447.
Reviewed By: sebbas, mont29
Differential Revision: https://developer.blender.org/D10367
Straight up version bump
Things of note:
They started using API calls only available in windows 8, however given
the Python 3.9 update will forcibly bump us to 8.1+ anyhow this is not
an issue.
Will require some minor tweaks to platform_win32.cmake after adding the
libs to svn which are not included in this diff so this diff can land
without having to have the libs in place yet.
Reviewed By: sebbas, sybren
Differential Revision: https://developer.blender.org/D10349
Straight forward version bump, some of the variables to detect a static
OpenEXR changed and the folder structure seemingly changed a little
requiring updates to the diff
Reviewed By: sebbas, sybren
Differential Revision: https://developer.blender.org/D10340
Version bump + no longer using Boost.
Building Alembic with Boost gave compiler errors, and having one less
inter-dependency is good as well.
Reviewed By: sebbas, sybren
Differential Revision: https://developer.blender.org/D10329
Straight forward version bump.
2020U2 is significantly louder in the deprecated header usage warning
department, we should probably see if we need to act on this: P1949
Differential Revision: https://developer.blender.org/D10359
This resolves build error with Py3.9x, use meson build system
since autoconf/automake are no longer supported.
This adds ninja & meson as dependencies for Linux.
Reviewed By: brecht, sybren
Ref D10282
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
Create zero-byte manual page files `nasm.1` and `ndisasm.1` such that
nasm's `make install` step succeeds.
Installing nasm requires that its manual pages are built. This requires
local packages `asciidoc` and `xmlto` to be installed.
Not only does `asciidoc` pull in 110 MB of packages (itself +
dependencies), there is also no need for these manual pages. Nasm is
just used for building other dependencies, and not even part of our
precompiled libraries in SVN.
Reviewed By: sebbas
Differential Revision: https://developer.blender.org/D10396
- Move non-blender build targets into their own section.
- Expand 'make help' text, noting a local 'make deps' overrides.
- Note where the spell checkers word-list is maintained.
- Note on why sqlite is built without 'tcl'.
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.
For the debug version of cython pip was trying to link
against the release version of python for some strange
reason. Passing some flags to explicitly target the
debug version fixes the issue.
Given other platforms do not have different builds for
debug/release this is not an issue there.
The following packages also have received updates:
- IDNA 2.10
- CHARDET 4.0.0
- URLLIB3 1.26.3
- CERTIFI 2020.12.5
- REQUESTS 2.25.1
- NUMPY 1.19.5
numpy has gained a hard dependency on cython:
- CYTHON 0.29.21
Notes:
- This only updates the build environment files,
once these are built, Blender can default to Python 3.9.
- The 'm' suffix for Python binaries/libs has been removed.
- The macOS patch in Python 3.7 is has been removed.
Reviewed By: sybren, campbellbarton, sebbas
Ref D10257
The repository information for cloning the OpenXR repository, rather than just
downloading the source archive, was outdated.
* Use the OpenXR-SDK repository link, not the OpenXR-SDK-Source one. Only the
former is needed, it contains pregenerated files with minimum dependencies.
The latter contains additional tools and the un-generated source files.
* Update the commit hash to the version we currently use, 1.0.14 (was 1.0.6).
Differential Revision: https://developer.blender.org/D10373
Reviewed by: Bastien Montagne
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
Unfortunately one issue raising another one, this ended up being a
fairly big update, with:
*Fixes:
** Dependencies between libraries are better handled (would fail
previously in some cases when the lib was also available as package).
** Dependency of Boost over Python is now taken into account.
** Fix CMake flags to use local own built boost.
** Fix building numpy.
*Changes:
** We now use pip for all python modules (including numpy).
** Added all missing python modules (requests etc.).
*Updates:
**USD: 20.08, Due to build failing with 20.05 (missing include).
Good news is, this version support LLVM 11.
But it was a serious pain to get working, even ended having to add an
ugly hack to manually specify the OIIO include dir...
Ref: T83631.
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
Build sqlite without `tcl` support, as it's causes an error on
installation when `tcl` is installed into the systems `/usr/lib/` and
install isn't running as root.
This could be resolves by adding `tcl` as a dependency
however it's not needed for Python's sqlite integration.
Linux distributions (Debian & Arch at least) split this off
into a separate package (which Python doesn't depend on),
so there is no need for Blender to include sqlite's `tcl`
integration either.
Reviewed By: brecht, LazyDodo
Ref D10281
