When storing multiple binaries in a fatbinary, ocloc stores Intel
Graphics binaries for specific devices and these don't get found when
the device doesn't match fully.
Blender compiles one binary per generation rather than per device, to
gain space and compile time.
We introduce a patch at ocloc level to work around this behavior that
otherwise leads to binaries not being found and recompilation being
attempted.
Pull Request: https://projects.blender.org/blender/blender/pulls/115750
The build scripts are still referring to gpu tests as being opengl.
Although they can also use Metal or Vulkan. This PR only replaces
the work `opengl` with `gpu` for build options.
Special note is that the windows argument `with_opengl_tests` is
also replaced with `with_gpu_tests` for consistency.
Pull Request: https://projects.blender.org/blender/blender/pulls/116030
The NanoVDB headers are not compatible with Metal due to missing address
space qualifiers. We currently have a big patch for NanoVDB header
files, which is difficult to update for OpenVDB 11. Instead extract a
few hundred lines of code from NanoVDB to do just what we need.
Pull Request: https://projects.blender.org/blender/blender/pulls/115992
Simple string replacement failed when one compiler was the exact
prefix of another (`clang` & `clang++` in this case),
resolve by performing string replacement on the list items.
We disabled SSE for OIIO headers in the days we still supported
32 bit builds, as it was giving build errors there. OIIO handles
this internally now so we no longer need to explicitly disable it,
also we stopped shipping 32 bit quite a while ago
Asserts historically only have been on in debug builds, however
running the tests in a debug configuration takes a while especially
if Cycles is enabled.
This adds WITH_ASSERT_RELEASE to enable asserts in release
configurations. It is enabled for "make developer" , and will also
be used for CI.
Co-authored-by: Brecht Van Lommel <brecht@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/115071
vcpkg somewhat forcefully injects itself into the build system
causing some work stations to use the vcpkg headers/libs rather than
the headers from our lib folder,we added some mitigation against this
in 34b3a9583a but still the occasional
user with build issues showed up, this should nip that in the bud once
and for all.
Harfbuzz and FriBiDi are included in our external libraries for all
platforms. This PR adds the glue to make them available as optional
build components (off by default).
Pull Request: https://projects.blender.org/blender/blender/pulls/114947
Previously the cmake code would try to run the LIBDIR specific "findX.cmake" files for both vulkan and shaderc.
However these would pick up system headers and libraries when LIBDIR were not present. This would lead to compilation errors as the system library configurations were not taken into account or queried.
This changes it so that if LIBDIR is not present, the proper pkgconfig files will be used instead.
Pull Request: https://projects.blender.org/blender/blender/pulls/114639
Using /etc/ssl only makes sense when the versions of SSL on the system
is compatible with the version Blender uses.
Failure to load the configuration for e.g. causes SSL to fail entirely
(causing downloading over HTTPS to fail).
Recently [0] de facto standard directory `/etc/ssl` was used however we
can't guarantee files in this path are compatible with Blender's SSL.
Use a known invalid path to resolve#114452.
Ref !114569
[0]: 60a8ae7830
WESTON is used when WITH_UI_TESTS is enabled.
Note that the system WESTON installation can be used by setting
WESTON_BIN to a path on the users system.
Ref !114164.
In order to speedup compilation, we upgrade IGC to 1.0.14828.26 along
with ocloc and the associated dependencies.
We also bump min-driver version accordingly to 26918.
Ref !114341
Configure failed to find vorbis & vorbisenc on Linux with the errors:
ERROR: vorbis not found using pkg-config
ERROR: vorbisenc not found using pkg-config
the issue was caused by configures test program failing to link the test
code against the static library because functions in libm weren't found.
Resolve by adding `$libm_extralibs` to libvorbis.
Note that it's strange this issue didn't come up before,
since it occurs on a clean build it seems necessary.
The last good commit was 8474716abb.
After this commits from main were pushed to blender-v4.0-release. These are
being reverted.
Commits a4880576dc from to b26f176d1a that happend afterwards were meant for
4.0, and their contents is preserved.
Resolve an error with SSL using a hard coded path to certificates on
Linux causing HTTPS access to fail.
request.urlopen(..) couldn't access any HTTPS URL's.
The first public Windows driver version with a higher number is
101.4824, so we bump the min-required driver version on Windows to this
one to ensure compatibility.
Enable dynamic sound library loading so that "make release" produces
binaries that are as portable as buildbot builds.
Remove unnecessary linker flags that are already set by default, and
don't specifiy explicit lib directoy since it is also found by default.
Pull Request: https://projects.blender.org/blender/blender/pulls/113360
This was only used for accessing cursor themes which only worked
with gnome and wasn't used in official releases.
Use the default theme or the theme defined by XCURSOR_THEME.
Eventually wp_cursor_shape_manager_v1 can be supported which avoids
having to access the theme.
When WITH_GHOST_SDL or WITH_HEADLESS were used, the message didn't make
much sense, especially since the features warned about weren't
necessarily enabled or even supported by the platform.
Replace with a `set_and_warn_incompatible` macro which only reports
configuration changes based on incompatible features.
Printing that a library is found every time CMake runs isn't helpful.
Restrict these messages for the first execution so messages are limited
to information developers may need to know such as features being
disabled because of incompatible configurations.
This PR enables vulkan backend as experimental option.
It will only be available in alpha builds on Linux and Windows.
This option is highly experimental and enabled to get some insight
on supported platforms. Don't expect a fully working Blender
yet. Also don't expect it to have usable performance.
**What is known to not work?**
* OCIO textures are not supported on Intel and AMD GPUs. sRGB/Standard is supported
on those platforms.
* AMD Polaris based GPUs on Linux will generate a crash when drawing the 3d cursor as it
doesn't support the needed vertex format. Comment out `DRW_draw_cursor` in `DRW_draw_region_info`.
* The colors in the node editor and sequencer are of as sRGB viewports aren't detected correctly.
* The image / UV editor isn't working as many texture formats haven't been tested yet. Some
tweaks are also needed to do correct depth testing.
* 3D Viewport is known to be flickering. Sometimes workbench doesn't display anything.
* 3D Viewport wireframe will crash as it uses a framebuffer with gaps between color attachments,
which isn't supported yet. (#113141)
* Rotate the view widget is partially drawn due to incompatible depth clipping.
* GPU Selection isn't working. It is expected to be solved when Overlay-Next will become the
default engine. For now disable GPU depth picking in the preferences.
* Cycles/EEVEE are known to not work with Vulkan yet. Cycles requires Vulkan Pixel Buffer.
Cuda <-> Vulkan interop might require a different approach than OpenGL as Vulkan doesn't allow
importing memory from a Cuda context. EEVEE uses features that aren't available yet in the backend
* Workbench is working, except Workbench shadows.
* EEVEE-Next basics are working. Shadows, lights are known to be not working. Materials/Shading
works in simple scenes. Changes are expected in EEVEE-Next that will break Vulkan compatibility
in the near future.
* Systems with multiple GPUs is not expected to work.
* Wayland support is in development and requires some iterations. You can start Blender, but
the protocols are not aligned yet.
* OpenXR hasn't been modified and is expected to fail.
* The backend is very strict when mis-using the GPU module. In debug builds it may crash
on asserts.
* Older drivers/GPUs might not have all the features that we require. The workarounds
for the missing features still need to be implemented.
**A word about performance**
In the project planning we focus first on stability and platform support. The performance of Vulkan is
around 20% of what we want to achieve. The reason is that each command sent to the
GPU is done one at a time. The implementation even waits until we have feedback that the GPU
is idle again.
Geometry is currently stored in System RAM. The GPU will read and cache the data when
accessing geometry. This slows down when using objects with much geometry.
Some performance features like MDI (Multi-Draw-Indirect) hasn't been implemented and
falls back to Single Draw Indirect.
**Why enable it is an experimental option?**
* Ensures that new features are being tested with Vulkan
* Ensure that building with Vulkan is possible on supported platforms
* Get feedback from developers if Vulkan can run on their system or that
there are special cases that we are not aware of. Main development
environment has been Linux/X11 with occasionally testing using Windows.
* Validate Add-ons that use the `gpu` module.
* Possible to enable GLSL validation on the buildbot. (Needs more work).
* Does it compile on all machines or does it require more changes to cmake
config. We expect it to be able to compile without installing the Vulkan SDK.
The Vulkan SDK is a very powerful tool, but only when actually doing GPU
development. Otherwise it is an overhead which slows down other
activities.
**How can the backend be enabled?**
Currently the Vulkan backend can be enabled per Blender session by starting
using the command line argument `--gpu-backend vulkan`. In the future, when
the backend is more mature, we will add a user preference to switch between
OpenGL and Vulkan.
Pull Request: https://projects.blender.org/blender/blender/pulls/113057
Previously this was the double the CPU count because:
- Modern CPU's from AMD & Intel support SMT/hyper-threading which
present twice as many cores, doubling again has little to no benefit.
- Using 2x or 4x the number of physical cores number can use a lot of
memory on systems with many cores which are becoming more common.
CMake decided to link the Debug libs for MaterialX because no specific
RelWithDebInfo configuration was provided, strange default imho but
not difficult to fix.
webp 1.3 changed the filenames on windows to include a `lib` prefix
(ie libwebp.lib rather than webp.lib) now this is a common thing
on linux and cmake has a `CMAKE_FIND_LIBRARY_PREFIXES` variable that
has a list of prefixes to look for during a `find_library` call.
`CMAKE_FIND_LIBRARY_PREFIXES` gets set during the call to the
`project` method in the main CMakeLists of a project. Now for windows
`lib` is *not* a common prefix by CMake, and it doesn't add "lib" to
CMAKE_FIND_LIBRARY_PREFIXES during that call.
so find library doesn't look for it, the libs are not found and an
unhappy time is had by all. Now the most obvious solution would be to
pass `-DCMAKE_FIND_LIBRARY_PREFIXES=lib` to CMake to sidestep this
however, the `project` call will set the variable overwriting
anything you passed through the CLI.
So the fix here is to have `find_library` counter-intuitively look
for both `libwebp` and `webp`
The last webp update changed the filenames of the webp libraries
on windows causing oiio not to find them and oiio silently build
without webp support, which only came to light after all of
blender was build and a test failed.
This change makes the OIIO validate and error out if certain
dependencies are not found at configure time so these mistakes
are caught early.
For Blender 4.0 only, 3.3 and 3.6 keep using the older Xcode version.
The new linker in Xcode 15 gives many warnings due to duplicated
libraries, generated by CMake to resolve circular dependencies. For now
use the old linker to silence these warnings.
Remove legacy flags for libc++, this is the default for a long time and
generates warnings with the new linker.
Reason for upgrade is to take advantage of MetalRT curve support.
Pull Request: https://projects.blender.org/blender/blender/pulls/110243
This broke when we moved the submodules around and no one ever noticed
This will now list:
-The current branch
-The current branch hash
-Addons branch
-Addons branch hash
-Libs url
-Libs revision
-Libs last-changed-date
So it'll be a little easier to diagnose what exactly the state of
things are when someone asks for help building.
zlib's uri is a bit unstable as when they release a new version they
move the last release "elsewhere"
This change switches the upstream URI over to github, which should be
a bit more reliable.
The official SDK was released, add correct paths for that version. The
old paths can be removed once the buildbot uses this SDK.
The SDK installer sets a HIP_PATH environment variable. This is used to
automatically detect the location when HIP_ROOT_DIR is not manually
specified.
Co-authored-by: Brecht Van Lommel <brecht@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/110519
Changes in 42713bf made it ignore the environment variable if there is a
defined but empty CMake variable. Also make similar changes for other
GPU compute APIs, to guard against future problems like this.
Pull Request: https://projects.blender.org/blender/blender/pulls/111928
The sound equalizer is using the Audaspace FFT Convolver.
The blender part creates an array of descriptions of power per "band"
and orders the creation of Equalizer (ISound) in the Audaspace.
Modifier can be created on sound strips. It lets you define
amplification or attenuation over frequency range from 30Hz to 20 kHz.
The power is limited to -30 db - 30 db. This is done using curve
mapping widget.
Co-authored-by: menda <alguien@aqui.es>
Co-authored-by: Richard Antalik <richardantalik@gmail.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/105613
The error message was written assuming the default version was set,
making the error confusing.
Adjust the error message when the non-default version is missing.
Add optional argument `STRIP_LEADING_C_COMMENTS` to CMake macros:
data_to_c_simple & data_to_c.
Strip leading C-style comments that don't bloat binary size.
Comments are replaced with blank lines so line numbers in error messages
match. Reduces Blender's binary size by ~70kb.
Had put my name here since the choice was between the foundation
and me personally, with the blender authors file now being in
place this can be cleaned up.
This changes the default linker options for debug builds to use
fastlinking, this causes the PDB only to be usable on the machine
it is being created on, however since debug builds cannot be
distributed to end users (wont run due to missing debug CRT on
their system) this isn't a problem.
This halves the time required for an incremental link on my system
from 7->3.5 seconds
Regression in [0] which caused `execinfo.h` not to be detected by CMake.
Setting a default variable for other platforms prevented the new
variable from being set.
[0]: f197b1a1f1
The `Find*.cmake` modules originally used uppercase commands to match
CMake's own conventions. Since then CMake uses lower-case and even
within our own find modules, using all uppercase wasn't done
consistently. Opt for lowercase everywhere.
Previously FREETYPE_LIBRARIES would sometimes contain
BROTLI libraries, since some configurations set them separately,
declare them separately under all configurations to avoid
changes to one platform breaking others.
Also quiets uninitialized variable warning.
The recent change to header copyrights [0] unintentionally changed
"Blender Foundation" to "Blender Authors" for the WIN32 file path
which blender is installed into.
Revert lines changed that aren't related to copyright text.
[0]: e955c94ed3
Listing the "Blender Foundation" as copyright holder implied the Blender
Foundation holds copyright to files which may include work from many
developers.
While keeping copyright on headers makes sense for isolated libraries,
Blender's own code may be refactored or moved between files in a way
that makes the per file copyright holders less meaningful.
Copyright references to the "Blender Foundation" have been replaced with
"Blender Authors", with the exception of `./extern/` since these this
contains libraries which are more isolated, any changed to license
headers there can be handled on a case-by-case basis.
Some directories in `./intern/` have also been excluded:
- `./intern/cycles/` it's own `AUTHORS` file is planned.
- `./intern/opensubdiv/`.
An "AUTHORS" file has been added, using the chromium projects authors
file as a template.
Design task: #110784
Ref !110783.
Recent change in [0] caused the CFLAGS variables not to be manipulated
by remove_cc_flag. Unfortunately EVAL is needed to set a variable
that references a variable name.
[0]: e95e6ad66a
Many calls to add_check_c_compiler_flag add_check_cxx_compiler_flag
resulted in over long lines & visual noise. Replace with a function that
takes multiple (cache_var flag) pairs to reduce duplication.
Hydra is a rendering architecture part of USD, designed to abstract the
host application from the renderer. A renderer implementing a Hydra
render delegate can run in any host application supporting Hydra, which
now includes Blender.
For external renderers this means less code to be written, and improved
performance due to a using a C++ API instead of a Python API.
Add-ons need to subclass bpy.types.HydraRenderEngine. See the example in
the Python API docs for details.
An add-on for Hydra Storm will be included as well. This is USD's
rasterizing renderer, used in other applications like usdview. For users
it can provide a preview of USD file export, and for developers it
serves a reference.
There are still limitations and missing features, especially around
materials. The remaining to do items are tracked in #110765.
This feature was contributed by AMD.
Ref #110765
Co-authored-by: Georgiy Markelov <georgiy.m.markelov@gmail.com>
Co-authored-by: Vasyl-Pidhirskyi <vpidhirskyi@gmail.com>
Co-authored-by: Brian Savery <brian.savery@gmail.com>
Co-authored-by: Brecht Van Lommel <brecht@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/104712
- Fix using forward declarations when extracting struct information as
it causing this check to be ignored.
- Fix extracting comments which sometimes included code fragments.
- Fix extracting the outer comment for struct declarations on a single
line.
- Skip source files in the build directory.
request from Thomas, to update the licensing document he needs
a list of all dependencies their versions and their homepage.
for all deps hosted on github the script will do its best to
figure out the landing page, for all others DEPNAME_HOMEPAGE
will have to be set in versions.cmake
To ensure this information is always supplied, the script will
error out with a fatal error informing whoever is working on
the builder to supply this information.
Pull Request: https://projects.blender.org/blender/blender/pulls/109013
When an offline render was done side by side render preview, further
render preview updates requiring BVH to be rebuilt would trigger a
crash.
This will be fixed upstream the same way in Embree 4.2.
Pull Request: https://projects.blender.org/blender/blender/pulls/109966
This utility uses Python's clang module to validate comments intended
to match the struct member names. `cmake_static_check_clang.py` has
been written to support adding other checkers in the future.
`list_assert_duplicates` validates a list that should contain no
duplicates, contains no duplicates, with scope keywords now being
allowed in `INC` sections, there is the situation where multiple
include paths can have the same scope set on them causing
`list_assert_duplicates` to error out.
To remedy this we remove the scope keywords from the list first,
before running the test.
USD has recently renamed their repository from USD to OpenUSD leading
to a change in the URI for this dep and the hash for the previously
released USD 23.05 since the tarball now will have the source in the
OpenUSD-23.05 folder.
This is the minimal change required to start using modern CMake in the
blender build system. This change is designed to allow small
incremental changes to the build system rather than doing it in one
big bang which would be unmaintainable (for me)
The biggest functional change is, previously all libraries in the
`LIB` section of a `blender_add_lib` call had the `INTERFACE` scope,
which is rarely, if ever the correct scope. This diff changes this to
`PRIVATE`
Concrete implications of this diff :
The `LIB`, `INC` and `INC_SYS` sections of an `blender_add_lib` call
now allow scoping keywords (`PUBLIC`, `PRIVATE,` `INTERFACE`) to
declare the scope of the dependency.
Right now the only library using any modern cmake is
`bf_intern_atomic` which is an header only interface library that will
just advertise its include directories.
This allows us to clean up any `CMakeLists.txt` that adds
`../../../intern/atomic` to its `INC` section to remove it in `INC` by
adding a `PRIVATE bf_intern_atomic` to the `LIB` section.
Pull Request: https://projects.blender.org/blender/blender/pulls/107858
Python versions before 3.10 did not have the
`platform.freedesktop_os_release` utils, use the trick based on looking
for distro-specific version files instead as fall-back (same as what was
done in the previous `install_deps.sh` bash script).
When using the `WITH_LINKER_LLD` option, the logic to find the `ld.lld`
binary and actually tell the build system to use it was specific to GCC.
I've copied the Clang-specific logic for Mold and adjusted it to find
LLD.
Not entirely sure why this is necessary, as LLD is actually Clang's
linker. However, without this change, CMake would use regular old slow
`ld` to link.
Pull Request: https://projects.blender.org/blender/blender/pulls/108884
This fixes#108487 by applying upstream OIIO commit 8da473e254
This commit fixes the deps builder to include the patch, the actual
bug will not be fixed until the platform maintainers update the OIIO
library in SVN.
Currently on Windows some dependencies are built with MinGW/GCC 3.x
this commit removes that, in favor of building them with MSVC
via msys2. This will make it easier in the future to offer Win/Arm64
builds of blender.
Notable changes:
- This change drops support for the external libxvid library in favor
of ffmpegs built in support for this format. This has been done with
permission from the VFX module.
Pull Request: https://projects.blender.org/blender/blender/pulls/108983https://projects.blender.org/blender/blender/pulls/105502
idiff sometimes locks up while shutting down when the CPU is
oversubscribed. While blender does not rely on the idiff tool
the tests that run on the CI environment do, which causes tests
to occasionally fail due to a timeout.
The root cause is a bit complex but can be found on the oiio tracker
at https://github.com/OpenImageIO/oiio/issues/3851
This change fixes idiff by :
1- Shutting down the thread pool before the main function exits
2- Have the shutdown wait for the pool threads to actually join, to
prevent the OS from forcefully terminating them while they could
potentially still be holding a lock.
This reverts commit 451751380c.
Seems like this broke linux/mac, likely needs to detect of libxvid
is there or not. For now revert until we sort this out.
Currently, Windows some dependencies are built with MinGW/GCC 3.x
this commit removes that, in favor of building them with MSVC
via msys2. This will make it easier in the future to offer Win/Arm64
builds of blender.
Notable changes:
- This change drops support for the external libxvid library in favor
of ffmpegs built in support for this format. This has been done with
permission from the VFX module.
Pull Request: https://projects.blender.org/blender/blender/pulls/105502
This is fixed in newer boost versions, but stick to the existing version now
for VFX platform compatibility. This change only affects macOS libraries,
since no other platform uses libc++.
Two issues there
- it was picking up release mode libs for oiio/tbb
- TBB had both debug and release libs in a variable that should only
have a single library causing a cmake error.
A lot of files were missing copyright field in the header and
the Blender Foundation contributed to them in a sense of bug
fixing and general maintenance.
This change makes it explicit that those files are at least
partially copyrighted by the Blender Foundation.
Note that this does not make it so the Blender Foundation is
the only holder of the copyright in those files, and developers
who do not have a signed contract with the foundation still
hold the copyright as well.
Another aspect of this change is using SPDX format for the
header. We already used it for the license specification,
and now we state it for the copyright as well, following the
FAQ:
https://reuse.software/faq/
Fix the issue when upstream workflow is used and the addons fork does
not yet have the release branch. In this case create a local branch
which is based on the upstream/<branch> but does not track anything.
Typically with such workflow the local branches will track origin, but
since the origin does not have the branch yet it is not possible to
track it.
Test plan:
- Use upstream workflow
- Have a fork of addons, which does not have blender-v3.6-release
- Run make update
The error message:
```
Updating scripts/addons ...
git fetch origin
git fetch upstream
git checkout -t origin/blender-v3.6-release
fatal: 'origin/blender-v3.6-release' is not a commit and a branch 'blender-v3.6-release' cannot be created from it
make: *** [update] Error 128
```
Pull Request: https://projects.blender.org/blender/blender/pulls/108197
Code gen bugs can happen, ad usually they can be worked around
MSVC 17.6 is not one of those cases:
59% tests passed, 120 tests failed out of 296
There really is no other choice than to refuse to build with this
compiler. Alternates that CAN be used are both 17.5 and the current
17.7 preview builds.
Upstream tracking ticket kindly submitted by @deadpin :
https://developercommunity.visualstudio.com/t/vs176/10293729
If a compiler is released in the 17.6.x series that has the bug
fixed, we can contract the range of blacklisted compiler versions
to cover just the affected range, for now however all of 17.6 marked
bad
Upgrade to the latest SDK, and enable in daily and release builds where it's
available as an option under Preferences > System.
There are some known limitations, see #104110 and release notes.
Pull Request: https://projects.blender.org/blender/blender/pulls/105538
Without this, support for newer NVIDIA cards will not be compiled with pre-compiling the CUDA binaries.
Includes changes needed for the buildbot building pipeline.
Co-authored-by: Sergey Sharybin <sergey@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/107585
When Python is not found, inform developers how they can use a newer
version. Even though it's not officially supported - we typically keep
the latest stable version of Python working.
Preparation for the the 3.6 library update landing.
The filenames for these libs will change a little bit and 3.6 will add
new library for the fp32 version of fftw.
After recent Linux library updates. The EMBREE_SYCL_SUPPORT variable that
this relied on was not cached.
Always install the sycl shared libraries regardless of build options, as
we do for other shared libraries.
Other shared libraries already do this, but for TBB it was off by default.
The conflict would happen when LD_LIBRARY_PATH is set which overrides rpath,
either manually by the user or by the Steam launcher.
Ref #107385, #104895
Pull Request: https://projects.blender.org/blender/blender/pulls/107587
Support string size debug so it can be used for regular development.
It works be writing values into strings, ensuring the buffer size
given is actually available. Developers can use this with memory
checking tools such as ASAN/valgrind to force an error when
the value used for the size of a buffer is larger than the buffer.
Resolve remaining issue with RNA using BLI_strncpy* in generated
callback functions where the size argument didn't represent the
size of the destination buffer.
This is automatically enabled along with ASAN for the
blender_developer.cmake configuration.
Ref PR !107602.
This brings the following improvements:
- Implementation of _MM_SET_FLUSH_ZERO_MODE and _MM_SET_DENORMALS_ZERO_MODE
- Implementation of _mm_round_ss
Does not seem to be any performance impact with just this upgrade.
Pull Request: https://projects.blender.org/blender/blender/pulls/107396
* Add HIP-RT API functions and library loading
* Add more HIP API types and functions
* Find HIP linker executable in CMake module
* New CMake module to find HIP-RT SDK
Co-authored-by: Brecht Van Lommel <brecht@blender.org>
Ref #105538
libdecor is not a hard requirement, so only fail the configure phase if
the building in strict mode.
This makes it behave like most other dependencies in Blender.
Pull Request: https://projects.blender.org/blender/blender/pulls/107304
Brecht Van Lommel
Stefan Werner
Xavier Hallade
Jeroen Bakker
Campbell Barton
Ray Molenkamp
Iyad Ahmed
Harley Acheson
Bastien Montagne
Sebastian Parborg
Werner, Stefan
Hans Goudey
Thomas Dinges
bsavery
Marcos Perez
Jot
Bogdan Nagirniak
Ray molenkamp
Ray Molenkamp
Sybren A. Stüvel
Anthony Roberts
Anthony
Sergey Sharybin
Sahar A. Kashi
Sebastian Parborg
Sebastian Herholz
Sahar A. Kashi