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
The issue was caused by an integer overflow in the `FFMPEGReader::seek`, which
lead to different results depending on an exact compiler version and platform.
The overflow happened in the equation which calculates `m_position`, in its
`packet.pts - st_time` part, which is effectively `int64_t - uint64_t` which is
expected to result in `uint64_t` due to the way how upcasting works in C++.
With the values `packet.pts=0` and `st_time=353600` from the test file the
calculation resulted in a negative value, which then wrapped around due to the
unsigned nature of the type, resulting in very big value on arm64. The value
was wrong, but it did not manifest itself as an error, since the seek code
believed it found the place.
However, when built on x86 platform, the result value was very large negative
value. It is possible that the type upcasting went different, due to the
multiplication with a double value later in the formula. And this large negative
value lead to the seeking code to read the entire file, trying to make it so
the `m_position` is not less than the requested position.
Fortunately, the `AVStream::start_time` is `int64_t`, which leads to a simple
fix which avoids signed/unsigned cast, making the seeking code to properly
calculate `m_position` on both arm64 and x64 platforms, regardless of the
compiler.
Pull Request: https://projects.blender.org/blender/blender/pulls/122149
Use COM smart pointer (`ComPtr`) to simplify memory management in WASAPI driver.
This reduces chances of calling `Release()` when a COM object has not been allocated.
Pull Request: https://projects.blender.org/blender/blender/pulls/121828
`xxHash` is a fast non-cryptographic hashing library. It significantly outperforms
md5 which we use in some places currently while also having great collision
resistance if not attacked explicitly.
The library is added to `extern` because that was the easiest way to do it and has
the least impact on others. I expect this library to become a required dependency
instead of an optional one. It's licence is `BSD 2-Clause` which seems to be the
first of its kind in Blender (there is `BSD 3-Clause` a couple of times).
For now, I used the library only for data deduplication when baking geometry nodes
where the same geometry is generated for each frame. The bake time in my test
goes down from >6s to <1s (note that this includes more than just the hashing time).
Pull Request: https://projects.blender.org/blender/blender/pulls/120139
After 91eb50ec2f, we would get random crashes/asserts from the pulseaudio library like:
`Assertion 'e->mainloop->n_enabled_defer_events > 0' failed at ../pulseaudio-17.0/src/pulse/mainloop.c:261, function mainloop_defer_enable(). Aborting.`
It seems like we would run into a race condition if we didn't guard the
pulseaudio flush command with the pulseaudio mutex.
This is probably because the pulseaudio thread would try to read the
buffer for a tiny bit even after pausing the playback.
Sadly the only way to reproduce this is to playback any scene (seem to happen more often if A/V sync is on) and spam play/pause.
Note that I could not reproduce this on every computer I tested this on.
But by expanding the main pulseaudio mutex lock, I can't seem to reproduce this anymore.
So I think that is the correct solution.
Pull Request: https://projects.blender.org/blender/blender/pulls/120072
This patch ports the GLSL SMAA library to the CPU compositor in order to
unify the anti-aliasing behavior between the CPU and GPU compositor.
Additionally, the SMAA texture generator was removed since it is now
unused.
Previously, we used an external C++ library for SMAA anti-aliasing,
which is itself a port of the GLSL SMAA library. However, the code
structure and results of the library were different, which made it quite
difficult to match results between CPU and GPU, hence the decision to
port the library ourselves.
The port was performed through a complete copy of the library to C++,
retaining the same function and variable names, even if they are
different from Blender's naming conversions. The necessary code changes
were done to make it work in C++, including manually doing swizzling
which changes the code structure a bit.
Even after porting the library, there were still major differences
between CPU and GPU, due to different arithmetic precision. To fix this
some of the bilinear samplers used in branches and selections were
carefully changed to use point samplers to avoid discontinuities around
branches, also resulting in a nice performance improvement. Some slight
differences still exist due to different bilinear interpolation, but
they shall be looked into later once we have a baseline implementation.
The new implementation is slower than the existing implementation, most
likely due to the liberal use of bilinear interpolation, since it is
quite cheap on GPUs and the code even does more work to use bilinear
interpolation to avoid multiple texture fetches, except this causes a
slow down on CPUs. Some of those were alleviated as mentioned in the
previous section, but we can probably look into optimizing it further.
Pull Request: https://projects.blender.org/blender/blender/pulls/119414
This file is generated by the attribution builder for every release
and it's up to the release team to check the log for extern and others to make sure this is up to date.
