The python debugger in Visual Studio for has been broken for years
but the upstream project over at https://github.com/microsoft/PTVS
show hopeful signs of life once in a while, so there is hope that
at one point this will start working again. That being said people
do keep turning this option on and end up disappointed it isn't
working and they spend a whole bunch of time on trying to get it to
work. So for now rather than removing this functionality
completely, just disable it.
* 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
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
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
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
Render tests can still fail. This change will disable them until they
are in a better shape. Reduces confusion when running cycles GPU render
tests.
Known issues:
- Render in batch can take forever due to a locking issue
- Headless rendering is still in development
- Particle hair rendering is broken.
Pull Request: https://projects.blender.org/blender/blender/pulls/131964
This changes the location of the Draco library installation path.
The new location is at the root of addons_core/io_scene_gltf2 addon, as the library is created for this addon only.
This will solve issues where the gltf addon couldn't find the library in case of global python installation or custom script/lib paths
Pull Request: https://projects.blender.org/blender/blender/pulls/131080
This commit adds support for clang-tidy checks during compilation on
macOS, which can now be enabled using the optional `WITH_CLANG_TIDY`
CMake variable.
The clang-tidy executable doesn't need to be separately installed since
CMake will pick up the executable from the LLVM pre-compiled library.
This commit also expands the coverage of clang-tidy checks to
Objective-C/C++, for which checks were enabled in PR #128334.
Pull Request: https://projects.blender.org/blender/blender/pulls/129761
This implements the proposal from #124512. For that it contains the following
changes:
* Remove the global override of `new`/`delete` when `WITH_CXX_GUARDEDALLOC` was
enabled.
* Always use `MEM_CXX_CLASS_ALLOC_FUNCS` where it is currently used. This used
to be guarded by `WITH_CXX_GUARDEDALLOC` in some but not all cases. This means
that a few classes which didn't use our guarded allocator by default before,
are now using it.
Pull Request: https://projects.blender.org/blender/blender/pulls/130181
This allows to use `assert()` directly inside shader source.
The current implementation is just replacing it with a printf
that gives some information about the location of the assert.
It is not that much more helpful than a printf with a condition.
What is useful is that they are disabled by default. So they
can be sprinkle around and only turned on during debugging.
Adding shader name inside the assert report is not trivial and
could be added later (the shader name is only known at compile
time which is too late for string parsing).
Adding which drawcall produced the assert isn't trivial either.
It would require flushing the printf buffer for each drawcall
which might force synchronization and remove bugs.
Pull Request: https://projects.blender.org/blender/blender/pulls/129728
This commit removes support for Vega GPUs from the AMD HIP backend of
Cycles. This is being done as:
- AMD no longer provides official support for Vega GPUs in their
ROCm software.
- Vega GPUs have rendering artifacts on all supported platforms,
and as a result of the reduction of support from AMD, are unlikely
to be fixed. Rendering artifacts include.
- The incorrect shading of volumes (Windows and Linux)
- Missing intersections on many meshes with HIPRT
- Crashing rendering subsurface scattering materials (Linux)
- And more.
Pull Request: https://projects.blender.org/blender/blender/pulls/129523
WITH_VULKAN_GUARDEDALLOC is a development option to use Blenders guarded
allocator when allocating internal vulkan driver resources. It does not provide any benefits
as this should be covered by vulkan validation and drivers are often ignoring this. This
change will remove the option from cmake and source code.
Pull Request: https://projects.blender.org/blender/blender/pulls/129039
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
Integrate an existing implementation of the SLIM unwrapping algorithm
into Blender. More info about SLIM here:
https://igl.ethz.ch/projects/slim/
This commit is based on the integration code written by Aurel Gruber
for Blender 2.7x (unfinished and never merged with the main branch).
This commit is based on Aurel's code, rebased and further improved.
Details:
- Unwrap has been moved into a sub-menu,
slim unwrapping is exposed as: "Minimum Stretch".
- Live unwrap with SLIM refines the solutions using a timer.
- When using SLIM there are options to:
- Set the number of iterations.
- Weight the influence using vertex weights.
- SLIM can be disabled using the `WITH_UV_SLIM` build option.
Co-authored-by: Aurel Gruber <aurel.gruber@infix.ch>
Ref !114545
The Vulkan backend has come a long way and it is time to spread his
wings a bit more. This change will make the vulkan backend available
in a regular release starting from 4.3.
Vulkan is still experimental and performance isn't there yet. But it
gives add-on developers already time to check if their add-ons work.
Main goal for the vulkan project is to get a better understanding which
platforms are supported.
- NVIDIA GTX900 and up should be supported using the official NVIDIA
drivers. This means that support for GTX700/800 is currently not
available. This is related to dynamic rendering.
- AMD Polaris and up are supported using the AMD drivers. When using
the open source drivers I believe the support level is around GCN2.
- Intel CPUs are supported from UHD (6th gen) on Linux. On windows
it requires features that are not available on all latest drivers and
a workaround should be added on our side.
- Intel GPUs are supported preferrable using the latest drivers on
Windows and Linux
Some render artifacts are showing when using EEVEE but the cause is
clear and would assume to solve them before the actual release.
Pull Request: https://projects.blender.org/blender/blender/pulls/127096
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 new version of the graphics compiler solves a performance
regression on Arc, adds support for Battlemage and Lunar Lake GPUs, and
allows to drop older patch to build fat binaries with broad
compatibility.
This latter change requires using -device dg2,mtl naming instead of
passing architecture ids.
Pull Request: https://projects.blender.org/blender/blender/pulls/127371
This only works with GCC and has only been tested on Linux. The main goal is to
automatically generate the code coverage reports on the buildbot and to publish
them. With some luck, this motivates people to increase test coverage in their
respective areas. Nevertheless, it should be easy to generate the reports
locally too (at least on supported software stacks).
Usage:
1. Create a **debug** build using **GCC** with **WITH_COMPILER_CODE_COVERAGE**
enabled.
2. Run tests. This automatically generates `.gcda` files in the build directory.
3. Run `make/ninja coverage-report` in the build directory.
If everything is successful, this will open a browser with the final report
which is stored in `build-dir/coverage/report/`. For a bit more control one can
also run `coverage.py` script directly. This allows passing in the
`--no-browser` option which may be benefitial when running it on the buildbot.
Running `make/ninja coverage-reset` deletes all `.gcda` files which resets the
line execution counts.
The final report has a main entry point (`index.html`) and a separate `.html`
file for every source code file that coverage data was available for. This also
contains some code that is not in Blender's git repository. We could filter
those out, but it also seems interesting (to me anyway), so I just kept it in.
Doing the analysis and writing the report takes ~1 min. The slow part is running
all tests in a debug build which takes ~12 min for me. Since the coverage data
is fairly large and the report also includes the entire source code, file
compression is used in two places:
* The intermediate analysis results for each file are stored in compressed zip
files. This data is still independent from the report html and could be used
to build other tools on top of. I could imagine storing the analysis data for
each day for example to gather greater insights into how coverage changes over
time in different parts of the code.
* The analysis data and source code is compressed and base64 encoded embedded
into the `.html` files. This makes them much smaller than embedding the data
without compression (5-10x).
Pull Request: https://projects.blender.org/blender/blender/pulls/126181
This commit adds a new cmake variable `WITH_CYCLES_TEST_OSL`
that runs every Cycles test a second time with OSL enabled.
At the moment only CPU OSL is enabled. There are plans to enable
OptiX OSL in the future when stability issues with OptiX OSL
have been resolved.
Some render tests have been blocked from running until we can figure
out a fix. The most notiable being all the Pricincipled BSDF tests
as some of them are failing due to noise differences.
Ref #123012
Pull Request: https://projects.blender.org/blender/blender/pulls/124601
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
Currently, every time blender starts on one of these platforms, we get the following warning (doesn't affect how it runs, all tests pass anyway):
```
TBBmalloc: skip allocation functions replacement in ucrtbase.dll: unknown prologue for function free
```
This is due to TBB_MALLOC_PROXY not working on these platforms (happens with emulated x64 too). I suspect it is fixed in the newer oneTBB releases that have proper support for Windows on Arm, rather than the patch I made to enable 2020u3.
This can be revisited once the TBB version is updated.
Pull Request: https://projects.blender.org/blender/blender/pulls/124148
This patches optimizes the Fog Glow Glare node to be about 25x faster
for 4K images. This is mainly achieved by utilizing the FFTW library and
multi-threading support code. Further improvements are still possible by
caching kernels, but the CPU compositor does not support caching yet.
The old Hartley transform was removed, so the node no longer works when
FFTW is disabled as a build time option, much like the OIDN node. A new
BLI library was introduced for FFTW, it includes some helper routines
relevant for FFTW as well as an initialization routine that sets up
multithreading using TBB as well as thread safety.
Build system support for threaded FFTW was also added, which defines the
relevant variables to detect threading support as well as add the
relevant libraries.
We do not currently have the threaded FFTW libs in our precompiled libs,
so the threading code is disabled until the libs lands in the coming
weeks. So currently, the code is only about 9x faster.
The only functional change is that the kernel is now odd sized, which
should produce more accurate results, but the final result is almost
identical and mostly undetectable.
The plan is to port this to the GPU as well similar to how we implement
OIDN until we have a GPU FFT implementation. GPU compositor can also do
caching, so it should be faster, being able to compute a 4K image in
under half a second.
Pull Request: https://projects.blender.org/blender/blender/pulls/121653
