If LFS hooks are installed manually the automatic installation would
fail.
This change makes it so `lfs` is a valid command of `git`, ensuring
that the package is installed. If the installation fails assume it
is due to tricky local setup, and do not fail.
Pull Request: https://projects.blender.org/blender/blender/pulls/118618
- git lfs install was called a bit too late, after the libraries
has been checked out, leaving the checkout in a non-resolved
state.
- Update blender code first, allowing proper submodule hash to
be pulled.
Pull Request: https://projects.blender.org/blender/blender/pulls/118615
This change makes it so build system and update utilities for Blender builds
are using pre-compiled libraries and other resources attached as Git modules
instead of using checkout of SVN repositories in the parent folder.
The directory layout:
```
* release/datafiles/
* assets/ -> blender-assets.git
* publish/
* ...
* README.txt
* lib/
* darwin_x64/ -> lib-darwin_x64.git
* darwin_arm64/ -> lib-darwin_arm64.git
* linux_x64/ -> lib-linux_x64.git
* windows_x64/ -> lib-windows_x64.git
* tests/
* data/ -> blender-test-data.git
```
The changes about configuring the actual Git sub-modules are not included
into this patch, as those require repository to actually exist before it
can be used.
The assets submodule is enabled by default, and the rest of them are
disabled. This means that if someone runs `git submodule update --init`
they will not get heavy libraries. The platform-specific and tests
related submodules are enabled when using `make update` or `make test`.
All the submodules are tracked: this means that when new commits are
done to the submodule, the blender.git repository is to be updated to
point them to the new hash. This causes some extra manual work, but it
allows to more easily update Blender and its dependencies to known good
state when performing operations like bisect.
Ref #108978
Pull Request: https://projects.blender.org/blender/blender/pulls/117946
People running `make update` first time, will not have a lib
folder yet, and get a warning about python being missing, this
sends some of them off onto somewhat of a wild goose chase
installing python when this is really not needed since it's
included in our libraries.
This change, changes the warning to only emit when the lib
folder exists, but python is missing in the lib folder and
there actually is likely an issue with the lib folder.
Blender had a very limited (only uncompressed or MJPEG frames) .avi file
support, for both reading and writing. This is something that ffmpeg can
fully do.
This removes all of that. 3500 lines of code gone, primary motivations being:
- ffmpeg can read and write .avi files just fine, including ones with
uncompressed or MJPEG frames.
- Blender's ffmpeg integration could also be taught to produce uncompressed or
MJPEG .avi files, but TBH I don't see a particular reason to do that. Modern
formats like H264 are better in every way, and already support "lossless"
option if needed.
- The "Lite" blender build configuration was excluding both ffmpeg and avi
anyway, so that config is something that can't read nor write any movies.
User visible changes:
- In scene image output type, under Video section now there's only Ffmpeg Video
(AVI Raw and AVI JPEG are gone)
- Whenever loading an existing file, if output was one of AVI Raw / AVI JPEG,
it is set to Ffmpeg Video.
Pull Request: https://projects.blender.org/blender/blender/pulls/118409
Main improvements:
* Spatial structure (Kd-tree) build is now multithreaded.
* Kd-tree switched to use cache-friendlier TreeLets.
* Field fixed some non-deterministic behavior when spatial cache does
not receive any training data during a training iteration due to a
large number of training iterations.
* Fixed build problems on (non-Mac) ARM systems.
Pull Request: https://projects.blender.org/blender/blender/pulls/118328
This was already the minimum requirement for Intel and Apple Silicon
GPUs. It is required for the Metal backend to work correctly.
Previously the minimum for AMD GPUs was 10.15.
Pull Request: https://projects.blender.org/blender/blender/pulls/118287
Turns out we were not building OSL with OptiX enabled anymore.
Also check now if the OSL builds has OptiX support and if not
disable it in Cycles.
Building OSL with support for this (still) does not require
either the OptiX SDK or CUDA, it only needs LLVM.
Pull Request: https://projects.blender.org/blender/blender/pulls/118234
- Commands which have arguments split over multiple lines use
indented lines.
- Wrap lines where multiple commands run using "&&".
- Blank lines between multiple commands helps the text from becoming
too dense.
This is not a hard requirement to be able to build the libraries, but
these versions should be written down somewhere. So compare compiler
versions as part of make deps setup.
Pull Request: https://projects.blender.org/blender/blender/pulls/117457
Flex's bundled configure depended on aclocal-1.15 which has been
updated to 1.16.
Resolve by regenerating configure files on Linux which in turn adds a
new dependency on texinfo.
Flex's bundled configure depended on aclocal-1.15 which has been
updated to 1.16.
Resolve by regenerating configure files on Linux which in turn adds a
new dependency on texinfo.
This is supported on Apple Silicon GPUs and macOS 13.0+.
Co-authored-by: Stefan Werner <stefan.werner@intel.com>
Co-authored-by: Attila Afra <attila.t.afra@intel.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/116124
NOTE: Blender does not seem to build with older OpenImageIO versions
(2.4.x and before) anymore. Since this library is now mandatory, it
means that Blender cannot be built without using the pre-compiled libs
on most Debian system, currently.
Ref. #113157.
Since the addition of Meteor Lake binaries, prebuilt GPU binaries
are now stored as fatbinaries. When running on a platform for which
prebuilt binaries are lacking or considered incompatible, the DPC++
SYCL runtime caching logic failed storing the (re)compiled
compatible version. This patch to DPC++ SYCL runtime fixes it.
Pull Request: https://projects.blender.org/blender/blender/pulls/117844
Add silently fail option to GPU based render tests. This is a pre-requisite to enable
render tests on the buildbot. By default these render tests will pass silently.
* Test will pass when using the `--pass-silently` arguments.
* Only crashes will be reported as failed tests.
* To find out failing test, review the test reports.
`WITH_GPU_RENDER_TESTS_SILENT` compile option can be used to let tests pass (default)
or fail (default for developers).
Although some tests fail, they still passed. In the generated render report,
the silently passed failures are correctly reported to be failures.
Pull Request: https://projects.blender.org/blender/blender/pulls/117629
This change fixes confusion situation when the render output
is an RGBA image: the difference in color was not visible in
the report because alpha channel was all zeros. This is due
to idiff performing per-channel difference.
The solution to this problem is to have separate images for
color and alpha difference, which makes it clear where the
difference actually is coming from.
