PR as discussed on the thread for #134676.
Works by disabling dependent load flag in OIDN, and also switching off OpenMP.
The OIDN bit is just a workaround until they can resolve this properly on their side by fixing the manifest.
The OpenMP bit requires more investigation regarding delayed loading.
Pull Request: https://projects.blender.org/blender/blender/pulls/135319
Quite obscure issue, seemingly caused by the fact that HIP-RT is
passing a large (about 20 MB) global array to a different library
(HIP driver, via hipModuleLoadData). Having global variables of
such size seems to be always problematic as they can not be stored
on stack and, possibly, extra mapping is involved here. It is not
clear whether it is a quirk of the HIP driver, or Linux, or, maybe,
something completely different.
It is possible to work-around the problem by making a temporary
copy of data on heap memory and pass it to the hipModuleLoadData().
This is how other areas are dealing with modules in Blender.
This change contains patch against HIP-RT and the new HIP-RT
library compiled with the patch. It seems to fix the problem
reported in the report.
This change does not resolve OIDN on HIP GPU which seems to have
the same issue. However, it is not a recent regression and the
bug with OIDN GPU denoising can be reproduced using Blender 4.3.
Pull Request: https://projects.blender.org/blender/blender/pulls/135403
This change brings the following improvements on the user level
- Support of GPUs with gfx12 architecture
- New HIP-RT library which in addition to the gfx12 support brings
various bug-fixes.
The known limitation of gfx12 is that OpenImageDenoiser does not yet
support this GPU architecture. This means that while Cycles will use the
full advantage of the gfx12 (including hardware accelerated ray-tracing),
denoising will only be possible on CPU, or secondary gfx11 or below GPU.
This is something that requires a change in OIDN and it is to late to do
it for Blender 4.4, but it is something to look forward for Blender 4.5.
The gfx12 changes for the pre-compiled kernels is rather trivial,
so it comes together (in the same PR) as the bigger HIP-RT change.
On the development side this change brings the following improvements:
- One step compile and link (much simpler CMake rules)
- Embedding BVH binaries in hiprt dll (which makes it easier to package
and load, without relying on special path configuration)
Co-authored-by: Sahar Kashi <sahar.kashi@amd.com>
Co-authored-by: Sergey Sharybin <sergey@blender.org>
Co-authored-by: Brecht Van Lommel <brecht@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/133129
OpenCollada used to rely on PCRE (a Perl Regexp library). Since
switching to Aras' OpenCollada fork (#122270), the library is no
longer needed, but is still required as a dependency.
This patch cleans this up by completely removing it from our build
system and linux system package installation script. This also lets
us remove it from our pre-compiled library platform repos, making the
process of recompiling our libraries from scratch easier as it wasn't
compiled by our dependency builder anymore.
Pull Request: https://projects.blender.org/blender/blender/pulls/134310
This was removed to make building USD plugins easier, without the need to
compile them for Blender specifically. However it also causes errors when
using the bpy module together with the usd-core pip package.
In practice there are not many USD plugins, and often need to be compiled
for Blender specifically anyway due to the monolithic library and DCCs being
on different USD versions.
Additionally, this adds a patch to avoid conflicts when loading the
same USD library version through Blender and usd-core on Windows and macOS.
Fix#127132: Crash using bpy and usd-core pip package together.
Co-authored-by: Ray Molenkamp <github@lazydodo.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/133083
OpenEXR: 3.3.2
OpenColorIO: 2.4.1
OpenVDB: 12.0.0
Also sync up exact FFMPEG version with reference (6.1.1, from
`versions.cmake`), and accept 7.x versions since Blender should also be
compatible with this major release.
See also #128577.
Turns out, `apt-cache` will not use exact package names match, leading
to invalid successful results in case a given package does not exist,
but a extended-name one does (e.g. looking for `python3.11` will return
results for packages like `libpython3.11-stdlib`...).
So add a first check using `apt show`, to ensure the requested package
name does exist first!
Also add a `__repr__` callback to the `PackageInstaller` class.
Although not currently used by `main` Blender, this library has been
tracked by platform maintainers for some times now, so time to also add
it to this script.
See aslo #128577.
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
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.
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
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
