Support thumbnail that shows the file contents instead
of the default blend file icon for all files in Finder.
Some files may still have the usual blender icon as thumbnail
depending on their contents.
blender-thumbnailer process is kept alive by the system
in the background and is invoked by QuickLook when needed.
The checkbox to disable the extension is present in
the Settings app.
It will NOT be an interactive "Preview" that allows richer
interactions like Panning viewport, or rotating 3D objects.
Cycles supports OptiX on Maxwell and up architectures, but the
default in OSL is to generate PTX targeting Pascal and up. Adjust the
OSL target architecture to Maxwell to fix this.
Pull Request: https://projects.blender.org/blender/blender/pulls/133011
- WITH_WINDOWS_EXTERNAL_MANIFEST is now required even for ninja
builds, this previously was not the case. so just apply it
across all build flavours on windows.
- fmsc-version=1922 is no longer needed, was required back when
support for clang on windows landed, is fine without it now.
- /MP gives better build performance when building from the IDE
makes no difference for a ninja build which wasn't struggling in
that department anyhow.
2019 no longer has a preview track, so support for it can
safely be removed. The help also incorrectly advertised
asan as a clang only feature, which is no longer true as
msvc supports it these days.
* Some libraries like Alembic and OpenColorIO for a long time removed
header dependencies on Boost.
* No need to have BOOST_LIBRARIES anymore, only BOOST_PYTHON_LIBRARIES
is a direct dependency through USD headers.
* OpenVDB is no longer a static library, no need to link its dependencies.
Pull Request: https://projects.blender.org/blender/blender/pulls/133424
To easily force a rebuild of a dependency the nuke script will remove all build
artifacts for a specific dependency from the dependency build folder. This includes
- The Debug and Release build folder of the dependency
- The Debug and Release staging output folder of the dependency
- The harvest output folder of the dependency
For dependencies that have a long dependency chain like embree, shaderc and
python extra convenience scripts are added that nuke the additional deps that
need to be removed to obtain a fully clean build.
These scripts have not been updated in years, and locally i had better
versions of them. This commit updates them to the latest i had locally
this should hopefully lower the barrier to building the dependencies by
other developers as all that is needed is a fresh VM with a clean
windows install.
Removed:
buildall.cmd - not useful, we no longer build for 2 vs versions
and 2 architectures , removed
nuke.cmd - same, may come back in the future in some form
New:
vmprep.cmd.txt - This preps a clean windows vm with the correct
versions of visual studio/cuda/git/hip/meson to build all dependencies.
this should only and ever be run on a clean install of windows, do not
under any circumstances run this on a developer workstation.
to prevent people from doing this anyhow this script has a .txt
extension so it cannot be accidentally executed, instructions on how to
run this script are this file.
vmbuild.cmd.txt - Helper build script, vmprep will provision the build
machine with this script.
vsconfig_2019 - installer script for visual studio 2019 to select the
workloads we require.
Previously it was a single version specification which was only
used by Windows.
In practice we actually have two different SDKs for Linux and
Windows. This change makes it possible to specify explicit HIP
version for Linux which could be different from Windows.
No functional changes expected, the same HIP SDK version is
used, just explicitly.
Ref #131976
Pull Request: https://projects.blender.org/blender/blender/pulls/132694
While I implemented pipewire support I forgot that some of the functions I use is not available in older pipewire versions.
This adds proper library version sanity checks for pipewire.
Pull Request: https://projects.blender.org/blender/blender/pulls/131610
This caused build errors on the docs builder, I can't seem to reproduce
locally, so revert for now and have another look at some point in the
future.
Sadly as these changes usually go, this took 5c515e26bb and
2f0fc7fc9f with it as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/132559
Correction to [0] which looks to have missed
relocating some scripts.
Also revert Python 3.6 compatibility as it's not required for tools.
[0]: e83d87f588
The goal of this test is to try to import some critical py scripts with the
system python of the building machine.
The main target is to ensure that these py scripts remain usable by all
buildbot machines, as some of them are using fairly outdated python
versions.
Current status:
* Scripts in `build_files` and `docs` are checked.
* Some python scripts in `build_files` were 'reverted' to be compatible
with older required python version currently (3.6).
* A few scripts are excluded from the test, mostly because they use Blender's
`bpy` module, which means they are only intended to be ran with Blender's
python anyway.
* The test is only enabled for Linux buildbots currently, as they use the
oldest Python by far.
Notes:
* Some more scripts are likely to be moved around in the future.
* Whether these tests need to be enabled on windows or macos platforms remains
an open question.
Pull Request: https://projects.blender.org/blender/blender/pulls/130746
This (optionally) uses the blender mirror for bootstrapping the msys2
environment, this is needed since some upstream providers remove older
packages frequently which makes it difficult to build older libs from
scratch.
Pull Request: https://projects.blender.org/blender/blender/pulls/131617
This commit introduces proper handling of ROCm 5 and ROCm 6 runtimes on
Linux, based on the version of the ROCm compiler used at build time.
Previously, HIPEW (the HIP equivalent of Cuda Wrangler) defaulted to
loading the ROCm 5 runtime. If ROCm 5 was unavailable, it would attempt
to load ROCm 6. However, ROCm 6 introduces changes in certain
structures and functions that are not backward compatible, leading to
potential issues when kernels compiled with the ROCm 6 compiler are
executed on the ROCm 5 runtime.
### Summary of Changes:
**Separation of Structures and Functions:**
Structures and functions are now separated into hipew5 and hipew6 to
accommodate the differences between ROCm versions.
**Build-Time Version Detection:**
The ROCm version is determined during build time, and the corresponding
hipew5 or hipew6 is included accordingly.
**Runtime Default to ROCm 6:**
By default, HIPEW now loads the ROCm 6 runtime and
includes hipew6 (Linux only).
**JIT Compilation Behavior:**
Since ROCm 6 is the default version, JIT compilation is supported only
when the ROCm 6 compiler is detected at runtime.
**HIP-RT Update:**
HIP-RT has been updated to load the ROCm 6 runtime by default.
These changes ensure compatibility and stability when switching
between ROCm versions, avoiding issues caused by runtime
and compiler mismatches.
Co-authored-by: Alaska <alaskayou01@gmail.com>
Co-authored-by: Sergey Sharybin <sergey@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/130153
Both the draw manager and gpu backend used the same compilation
directive for enablement. This PR seperates them into
`WITH_GPU_DRAW_TESTS` for draw manager related tests and
`WITH_GPU_BACKEND_TESTS` for gpu backend related tests.
Pull Request: https://projects.blender.org/blender/blender/pulls/132018
This applies upstream PR 13328 to our copy of dpcpp, which enables
building dpcpp on a many core box. I Upgraded my build env and
ran into this issue.
No rebuilds required, build time fix only.
The build commands for `ninja clean` on Windows were wrong - one had
the cmake executable duplicated and one was not using the correct
environment variable and also had missing quotes for paths that
contained spaces. Tested working on with `make ninja clean` and
`make ninja clean release`.
Pull Request: https://projects.blender.org/blender/blender/pulls/128802
The deps builder currently uses `check/enable_language(CUDA)` but given
it's just a coordinator for external builds, doesn't actually build any
cuda code.
The problem there is, for enable_language(CUDA) to work, the CUDA Visual
studio integration needs to be installed which they refuse to install
when only the VS buildtools are installed, they somehow require the
full IDE to be available. Cmake will try to compile some code and fail.
(this worked previously since i had a full VS install on my build
machine, but that should not be used due to ms not providing a back
catalog of older versions of VS community)
This change, changes things over to use the FindCUDAToolkit module (not
to be confused with the deprecated FindCUDA module), which just locates
the libraries, includes and nvcc but doesn't compile anything.
which neatly sidesteps the issue. None of our downstream deps rely on
the VS integration either, so we are in the clear..... for now..
Pull Request: https://projects.blender.org/blender/blender/pulls/130913
Windows build_deps tweaks:
- Support VS2022 for building x64 dependencies (this is not used yet,
but for local tests might be useful).
- Put artifacts and staging of windows deps builder under git ignore
Pull Request: https://projects.blender.org/blender/blender/pulls/130342
