Seems like ASAN has been broken on debug builds for MSVC ever since
d5e50460e7 (1.5 years ago) the core reason is it's incompatible with
fastlink, it'll appear to work, but in the asan reports no symbols
will be resolved.
While looking into this, some other problems like the symbol format being
not inline with the table in the comment above it, and a warning coming
out of /extern were noted.
All of these issues are addressed in this commit.
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
In contrast to libamdhip64, for which blender searches in multiple directories,
libhiprt64 only had limited support for non-standard installation directories.
With this commit, the library lookup for HIPRT is handled in a similar way in
the original HIP/ROCm module. This also fixes issues for downstream Linux
distributions where HIPRT support was enabled during build time but was not
available at runtime.
Co-authored-by: Torsten Keßler <t.kessler@posteo.de>
Pull Request: https://projects.blender.org/blender/blender/pulls/131046
Extract Boykov-Kolmogorov max flow algorithm from boost::graph. As part
of work towards removing Boost as a Blender dependency.
Together with #133347 this removes the last direct Blender dependency
on Boost.
Pull Request: https://projects.blender.org/blender/blender/pulls/132142
There's a "Render -> Render Audio" operator that pretty much calls into Audaspace functionality directly. This PR adds two new options in there, that boThere's a "Render -> Render Audio" operator that pretty much calls
into Audaspace functionality directly. This PR adds two new options in
there, that both feel like an oversight:
- There's an option for AAC container, when someone wants to render
into .aac file. Previously you could render AAC audio, but only in
MKV (Matroska) container. This is a user request #131980.
- When using MKV (Matroska) or Ogg container, it did not list Opus as
an audio codec that can be used. This felt like an oversight; both
the rest of Blender and Audaspace can handle that, jus the option
was not spelled out in the RNA enums.
Pull Request: https://projects.blender.org/blender/blender/pulls/132877th feel like an oversight:
- There's an option for AAC container, when someone wants to render into `.aac` file. Previously you _could_ render AAC audio, but only in MKV (Matroska) container. This is a user request #131980.
- When using MKV (Matroska) or Ogg container, it did not list Opus as an audio codec that can be used. This felt like an oversight; both the rest of Blender and Audaspace can handle that, jus the option was not spelled out in the RNA enums. Note however that without fix in #132872 the Matroska container continues to be useless in that it produces wrong result.
Upstream Audaspace PR for the 2nd point: https://github.com/neXyon/audaspace/pull/47 (was just merged!)
Pull Request: https://projects.blender.org/blender/blender/pulls/132877
Matroska container really really wants to internally keep on using
milliseconds as a time base. Even if at initialization time both the
m_stream and m_codecCtx are set to use {1, sample_rate} timebase,
later during the avformat_write_header call the audio stream gets set
to {1, 1000}.
Doing av_packet_rescale_ts for each packet after receiving it but
before writing it seems to do all the correct work. This is what is
being done inside Blender movie_write_audio.cc, and in official ffmpeg
mux.c example.
Pull Request: https://projects.blender.org/blender/blender/pulls/132872
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 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
Python 3.12 no longer supports calls to PyImport_AppendInittab
once initialized.
The call was redundant as Blender's `bpy_internal_modules` already
includes the "manta" module.
Resolve by disabling the call when Python's lifecycle isn't being
managed by manta-flow.
CMake 3.31 has begun to emit the following warning:
```
CMake Deprecation Warning at extern/audaspace/CMakeLists.txt:17
Compatibility with CMake < 3.10 will be removed from a future version of
CMake.
Update the VERSION argument <min> value or use a ...<max> suffix to tell
CMake that the project does not need compatibility with older versions.
```
The main blender CMakeLists has a `cmake_minimum_required(VERSION 3.10)`
already so it's likely the one in audaspace isn't needed. given it is there
however and i'm not entirely sure about the history why it is there i bumped
it to `3.10` so it aligns with the main blender one.
Pull Request: https://projects.blender.org/blender/blender/pulls/130566
This is being added straight to 4.2, prior to the `make license` command
which will use this to generate a more complete license file.
Licenses information and ambiguities worked with Dalai Felinto.
Part of !129018.
This change switches Cycles to an opensource HIP-RT library which
implements hardware ray-tracing. This library is now used on
both Windows and Linux. While there should be no noticeable changes
on Windows, on Linux this adds support for hardware ray-tracing on
AMD GPUs.
The majority of the change is typical platform code to add new
library to the dependency builder, and a change in the way how
ahead-of-time (AoT) kernels are compiled. There are changes in
Cycles itself, but they are rather straightforward: some APIs
changed in the opensource version of the library.
There are a couple of extra files which are needed for this to
work: hiprt02003_6.1_amd.hipfb and oro_compiled_kernels.hipfb.
There are some assumptions in the HIP-RT library about how they
are available. Currently they follow the same rule as AoT
kernels for oneAPI:
- On Windows they are next to blender.exe
- On Linux they are in the lib/ folder
Performance comparison on Ubuntu 22.04.5:
```
GPU: AMD Radeon PRO W7800
Driver: amdgpu-install_6.1.60103-1_all.deb
main hip-rt
attic 0.1414s 0.0932s
barbershop_interior 0.1563s 0.1258s
bistro 0.2134s 0.1597s
bmw27 0.0119s 0.0099s
classroom 0.1006s 0.0803s
fishy_cat 0.0248s 0.0178s
junkshop 0.0916s 0.0713s
koro 0.0589s 0.0720s
monster 0.0435s 0.0385s
pabellon 0.0543s 0.0391s
sponza 0.0223s 0.0180s
spring 0.1026s 1.5145s
victor 0.1901s 0.1239s
wdas_cloud 0.1153s 0.1125s
```
Co-authored-by: Brecht Van Lommel <brecht@blender.org>
Co-authored-by: Ray Molenkamp <github@lazydodo.com>
Co-authored-by: Sergey Sharybin <sergey@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/121050
Disable dynamic SDL loading as well as disable SDL for release builds.
This was only used for audio output which can already use OpenAL
if there are back-ends not natively supported by Blender.
- Remove extern/sdlew/
- Remove the WITH_SDL_DYNLOAD build option.
- Remove `bpy.app.sdl.available`.
Ref !127554
This gets Windows ARM64 to compile with clang-cl, which gives up to 40% performance improvements in certain scenes rendered with cycles, compared to MSVC.
This is all tested using LLVM 18.1.8 and a VS2022 `vcvarsall` window.
Subsequent PRs with various lib version updates, etc to go in at a later point.
Pull Request: https://projects.blender.org/blender/blender/pulls/124182
This continues the cmake modernization effort and introduces support for
allowing our optional dependencies to integrate properly. TBB is added
here as it's proven troublesome to maintain correctly.
Currently the only Blender project which uses the TBB headers directly
is `blenlib`. However, all downstream projects which require blenlib as
their dependency, and wish to properly make use of its threading
facilities, needed to define various TBB items in their CMake files. Not
only is this unnecessary and arcane, but several projects didn't do this
and ended up not using threading as well as producing ODR violations
along the way[1].
This PR makes TBB a modern dependency and exposes it PUBLIC'ly from
`blenlib`. All downstream projects which depend on blenlib will now
receive everything they require from TBB automatically. This includes
the `WITH_TBB` define, the headers, and the library itself.
[1] blender/blender@05241f47f5
Pull Request: https://projects.blender.org/blender/blender/pulls/124916
Turns out closing AudioUnit handle could interfere with other software.
It is something Apple is investigating, to see if it is API not used
correctly, or whether there is something to be fixed in the Core Audio.
Until then disable the code which closes audio handles. It rolls back
to the situation when the computer might not be able to sleep properly,
but it is how the previous release was, and overall it is less annoying
than causing an interference.
Once the issue is looked into by Apple we will re-iterate over having
both issues (interference and power management) resolved.
Pull Request: https://projects.blender.org/blender/blender/pulls/124400
