| Age | Commit message (Collapse) | Author |
|---|
|
|
|
- fix the source package download URL
- patch the `meson.build` file to allow the CentOS 7 meson version to be
used
- only build what we need (`wayland-scanner`), and not the libraries,
documentation, and tests.
Ref: D16074
This also reverts commit f6664217b3214be869afb732d1d5bfc471a88e9a
"Build: temporarily disable wayland dependency".
|
|
This caused problems on centos7, see D16074 for details.
|
|
This is needed to ensure and up to date "wayland-scanner" is used,
as versions before 1.20.0 generate headers incompatible with
dynamic linking (WITH_GHOST_WAYLAND_DYNLOAD).
As the centos7 version of wayland is 1.15 so make this part of Blender's
dependencies on Linux.
We intend to enable Wayland for Blender 3.4 release, this is needed for
the build-bot.
Reviewed By: brecht
Ref D16074
|
|
OpenColorIO failed to build on Linux+GCC-12.2 because of strlen() use.
|
|
We have moved away from duplicating arguments in else() and endif()
commands.
|
|
|
|
Ref T92571, D15286
|
|
This has been a pain, newer OpenVDB forcefully trying to use more recent
system TBB (oneTBB) instead of the one built by this script.
Also include a few minor unrelated fixes.
Ref T99618.
|
|
OIIO: 2.3.18.0
Boost: 1.80.0
Python:3.10.6
NumPy: 1.23.2
Ref T99618.
|
|
|
|
This was already done in the libraries SVN, just the build system
changes got forgotten to be committed.
|
|
More consistent with other libs and avoids issues where it would always be
rebuilt.
|
|
|
|
backport of python PR 31735 [1]
[1] https://github.com/python/cpython/pull/31735
|
|
Should have been part of D15291/rBa296b8f694d1.
ref. T99618
|
|
With libepoxy we can choose between EGL and GLX at runtime, as well as
dynamically open EGL and GLX libraries without linking to them.
This will make it possible to build with Wayland, EGL, GLVND support while
still running on systems that only have X11, GLX and libGL. It also paves
the way for headless rendering through EGL.
libepoxy is a new library dependency, and is included in the precompiled
libraries. GLEW is no longer a dependency, and WITH_SYSTEM_GLEW was removed.
Includes contributions by Brecht Van Lommel, Ray Molenkamp, Campbell Barton
and Sergey Sharybin.
Ref T76428
Differential Revision: https://developer.blender.org/D15291
|
|
|
|
|
|
Ref T98555.
|
|
|
|
Ref T98555.
|
|
Those are used by alembic regression tests.
|
|
This reverts commit 32a9aac3b84f4742937dd8fd2afc14a443cb0248.
|
|
* BLENDER_VERSION_CYCLE set to beta
* Update pipeline_config.yaml to point to 3.2 branches and svn tags
* Update and uncomment BLENDER_VERSION in download.cmake
|
|
tiff now outputs tiffd.lib for debug builds
oiio was not informed about this and had
a build error because of it.
|
|
if alembic builds before imath it'll cause a build error.
|
|
* OpenEXR 3.1.4 -> 3.1.5, this fixes several issues OSS fuzz found.
* libtiff 4.3.0 -> 4.4.0, this fixes several CVE's.
This also converts the harvest of libtiff on windows to a post install handler,
there's a few left but Windows is getting close to being harvest free.
Differential Revision: https://developer.blender.org/D15478
|
|
This is a refresh of our current FFmpeg 5.0.0 (unchanged) version with the
following changes:
* libvpx all platforms: enable SSE3/4/AVX/AVX2 instruction sets. libvpx has a
proper CPUID check in place and will not call the faster kernels unless it is
sure the CPU supports it. So we can safely enable this, this partially
resolves T95743 (completely on Linux and macOS).
* libvpx Windows - threading was disabled due to a shared dependency on
libwinpthreads.dll which we prefer not to distribute. However when configure
cannot find pthreads it will happily fall back on a win32 threads based
emulation layer. This also resolves the final part of T95743.
* libaom-av1 - new dependency required for D14920, this is a somewhat odd
dependency, it's cmake based, but still needs the perl environment setup, so
we have to setup the env and call cmake our selves for the configure, build
and install commands. This dep has the same libwinpthreads issue as vpx on
Windows, however since it's cmake based, it's easier to prevent cmake from
detecting it.
Differential Revision: https://developer.blender.org/D15399
|
|
This reverts the Flex-related parts of commit
rBef268c78933079137288e326704431432adf9ad9, as those caused a build
error on CentOS 7 (which is used for the precompiled Linux libraries).
CentOS 7 only has Automake 1.13, whereas after this commit version 1.15
seems to be required.
Since in its patch description (D15319) it's mentioned that this
"probably doesn't warrant changing", and it's actually blocking the
build of the precompiled libraries for Blender 3.3 now, I'll revert the
Flex-related part of the commit.
|
|
* Allows Apple Silicon machines to use 8-wide BVH, which the release notes
mention give an 8% performance boost.
* An update to this version is also required for OpenPGL.
This patch includes contributions from Jason Fielder and Sebastian Herholz.
Ref D15286, T98555
Differential Revision: https://developer.blender.org/D15482
|
|
They are not strictly needed for compilation and disabling them makes
the compiler more portable without any special trickery.
This change aimed to solve problem which currently happens on the API
documentation build which does not have terminfo installed, but needs
to compile Cycles.
Note that the DPC++ is to be re-compiled.
|
|
rBb9c37608a9e959a896f5358d4ab3d3d001a70833 moved evaluation of
`versions.cmake` before `options.cmake`, as a result of which
`BLENDER_PLATFORM_ARM` was no longer defined in `versions.cmake`,
causing it to choose the wrong OpenSSL version for aarch64. This
reverts that. Also fixes a compiler crash when building flex with some
glibc versions.
Differential Revision: https://developer.blender.org/D15319
|
|
|
|
This patch adds a new Cycles device with similar functionality to the
existing GPU devices. Kernel compilation and runtime interaction happen
via oneAPI DPC++ compiler and SYCL API.
This implementation is primarly focusing on Intel® Arc™ GPUs and other
future Intel GPUs. The first supported drivers are 101.1660 on Windows
and 22.10.22597 on Linux.
The necessary tools for compilation are:
- A SYCL compiler such as oneAPI DPC++ compiler or
https://github.com/intel/llvm
- Intel® oneAPI Level Zero which is used for low level device queries:
https://github.com/oneapi-src/level-zero
- To optionally generate prebuilt graphics binaries: Intel® Graphics
Compiler All are included in Linux precompiled libraries on svn:
https://svn.blender.org/svnroot/bf-blender/trunk/lib The same goes for
Windows precompiled binaries but for the graphics compiler, available
as "Intel® Graphics Offline Compiler for OpenCL™ Code" from
https://www.intel.com/content/www/us/en/developer/articles/tool/oneapi-standalone-components.html,
for which path can be set as OCLOC_INSTALL_DIR.
Being based on the open SYCL standard, this implementation could also be
extended to run on other compatible non-Intel hardware in the future.
Reviewed By: sergey, brecht
Differential Revision: https://developer.blender.org/D15254
Co-authored-by: Nikita Sirgienko <nikita.sirgienko@intel.com>
Co-authored-by: Stefan Werner <stefan.werner@intel.com>
|
|
Latest OpenSubdiv builds without GLEW by default, which is also what we do
for precompiled libraries. So there is no need for compatibility checking
with system GLEW.
Additionally WITH_SYSTEM_GLEW is turned off by default for Blender, and this
logic was presumably added when it was still on by default a few years ago.
Also remove outdated mention of glew-mx, we use intern/glew-mx and no
external library for this.
Differential Revision: https://developer.blender.org/D15281
|
|
Differential Revision: https://developer.blender.org/D15304
|
|
* TBB MEX version is now 2021, since this versin introduces 'oneTBB'
which brings a lot of incompatibilities with previous versions.
* Fix several typos and mistakes in OSD, Embree and OIDN build code that
prevented proper usage of a local TBB build.
|
|
|
|
|
|
Should prevent accidental use of wrong Python.
|
|
Following what is done for LLVM. Being consistent feels good here.
Not strictly needed as the build here passed anyway, but it does
feel good to be consistent.
|
|
Make them to use self-compiled Python, similar to previous fixes
for other libraries.
|
|
llvm was using system python, rather than our copy
this went unnoticed on both linux and windows until
sergey tried to build the deps on a clean system with
no system python installed.
|
|
There is a check to be sure no system python is in the path
on windows to be sure deps do not accidentally build against it.
The problem arises on certain versions of windows that ship a
python.exe that just opens up the MS store to download their
python version. The check takes this to be a real python
installation and refuses to build.
This change fixes the issue by looking for pythonw.exe which a
real python install would have, but the MS store opening one that
windows ships (as of now) would not.
|
|
|
|
Ref. T98555.
|
|
|
|
Disable the new more accurate timing code, this is not needed for Blender.
In USD itself this code is disabled on macOS anyway, so it should operate fine
without it.
Ref T97950, T95206
Differential Revision: https://developer.blender.org/D14928
|
|
|
