* Leave code for building the render delegate against other applications and
their USD libraries to the Cycles repository, since this is not a great fit.
In the Blender repository, always use Blender's USD libraries now that they
include Hydra support.
* Hide non-USD symbols from the hdCycles shared library, to avoid library
version conflicts.
* Share Apple framework linking between the standalone app and plugin.
* Add cycles_hydra module, to be shared between the standalone app and plugin.
* Bring external libs code in sync with standalone repo, adding various missing
libraries.
* Move some cmake include directories to the top level cycles source folder
because we need to control their global order, to ensure we link against the
correct headers with mixed Blender libraries and external USD libraries.
* Add missing GLEW and hgiGL libraries for Hydra
* Fix wrong case sensitive include
* Fix link errors by adding external libs to static Hydra lib
* Work around weird Hydra link error with MAX_SAMPLES
* Use Embree by default for Hydra
* Sync external libs code with standalone
* Update version number to match Blender
* Remove unneeded CLEW/GLEW from test executable
None of this should affect Cycles in Blender.
Ref T96731
Adds support for linking with some of the dependencies of a USD
build instead of the precompiled libraries from Blender, specifically
OpenSubdiv, OpenVDB and TBB. Other dependencies keep using the
precompiled libraries from Blender, since they are linked statically
anyway so it does't matter as much. Plus they have interdependencies
that are difficult to resolve when only using selected libraries from
the USD build and can't simply assume that USD was built with all
of them.
This patch also makes building the Hydra render delegate via the
standalone repository work and fixes various small issues I ran into
in general on Windows (e.g. the use of both fixed paths and
`find_package` did not seem to work correctly). Building both the
standalone Cycles application and the Hydra render delegate at the
same time is supported now as well (the paths in the USD plugin JSON
file are updated accordingly).
All that needs to be done now to build is to specify a `PXR_ROOT`
or `USD_ROOT` CMake variable pointing to the USD installation,
everything else is taken care of automatically (CMake targets are
loaded from the `pxrTargets.cmake` of USD and linked into the
render delegate and OpenSubdiv, OpenVDB and TBB are replaced
with those from USD when they exist).
Differential Revision: https://developer.blender.org/D14523
Currently only supports single image frames (no animation possible).
If quality slider is set to 100 then lossless compression will be used,
otherwise lossy compression is used.
Gives about 35% reduction of filesize save when re-saving splash screens with lossless
compression.
Also saves much faster, up to 15x faster than PNG with a better compression ratio as a plus.
Note, this is currently left disabled until we have WebP libs (see T95206)
For testing precompiled libs can be downloaded from Google:
https://storage.googleapis.com/downloads.webmproject.org/releases/webp/index.html
Differential Revision: https://developer.blender.org/D1598
GLUT does not support offscreen contexts, which is required for the new
display driver. So we use SDL instead. Note that this requires using a
system SDL package, the Blender precompiled SDL does not include the video
subsystem.
There is currently no text display support, instead info is printed to
the terminal. This would require adding an embedded font and GLSL shaders,
or using GUI library.
Another improvement to be made is supporting OpenColorIO display transforms,
right now we assume Rec.709 scene linear and display.
All OpenGL, GLEW and SDL code was move out of core cycles and into
app/opengl. This serves as a template for apps that want to integrate
Cycles interactive rendering, with a simple OpenGLDisplayDriver example.
In general this would be adapted to the graphics API and color management
used by the app.
Ref T91846
* Replace license text in headers with SPDX identifiers.
* Remove specific license info from outdated readme.txt, instead leave details
to the source files.
* Add list of SPDX license identifiers used, and corresponding license texts.
* Update copyright dates while we're at it.
Ref D14069, T95597
Use a shorter/simpler license convention, stops the header taking so
much space.
Follow the SPDX license specification: https://spdx.org/licenses
- C/C++/objc/objc++
- Python
- Shell Scripts
- CMake, GNUmakefile
While most of the source tree has been included
- `./extern/` was left out.
- `./intern/cycles` & `./intern/atomic` are also excluded because they
use different header conventions.
doc/license/SPDX-license-identifiers.txt has been added to list SPDX all
used identifiers.
See P2788 for the script that automated these edits.
Reviewed By: brecht, mont29, sergey
Ref D14069
No need for it now since all the threading queries and
scheduling is done via TBB.
Should be no functional changes as all the removed code
is supposed to be unused.
This adds the remaining bits to enable Metal on macOS. There are still
performance optimizations and other improvements planned, but it should
now be ready for early testing.
This is currently only enabled on in Arm builds for M1 GPUs. It is not
yet working on AMD or Intel GPUs.
Ref T92212
Differential Revision: https://developer.blender.org/D13503
This patch adds the Metal host-side code:
- Add all core host-side Metal backend files (device_impl, queue, etc)
- Add MetalRT BVH setup files
- Integrate with Cycles device enumeration code
- Revive `path_source_replace_includes` in util/path (required for MSL compilation)
This patch also includes a couple of small kernel-side fixes:
- Add an implementation of `lgammaf` for Metal [Nemes, Gergő (2010), "New asymptotic expansion for the Gamma function", Archiv der Mathematik](https://users.renyi.hu/~gergonemes/)
- include "work_stealing.h" inside the Metal context class because it accesses state now
Ref T92212
Reviewed By: brecht
Maniphest Tasks: T92212
Differential Revision: https://developer.blender.org/D13423
NOTE: this feature is not ready for user testing, and not yet enabled in daily
builds. It is being merged now for easier collaboration on development.
HIP is a heterogenous compute interface allowing C++ code to be executed on
GPUs similar to CUDA. It is intended to bring back AMD GPU rendering support
on Windows and Linux.
https://github.com/ROCm-Developer-Tools/HIP.
As of the time of writing, it should compile and run on Linux with existing
HIP compilers and driver runtimes. Publicly available compilers and drivers
for Windows will come later.
See task T91571 for more details on the current status and work remaining
to be done.
Credits:
Sayak Biswas (AMD)
Arya Rafii (AMD)
Brian Savery (AMD)
Differential Revision: https://developer.blender.org/D12578
This includes much improved GPU rendering performance, viewport interactivity,
new shadow catcher, revamped sampling settings, subsurface scattering anisotropy,
new GPU volume sampling, improved PMJ sampling pattern, and more.
Some features have also been removed or changed, breaking backwards compatibility.
Including the removal of the OpenCL backend, for which alternatives are under
development.
Release notes and code docs:
https://wiki.blender.org/wiki/Reference/Release_Notes/3.0/Cycleshttps://wiki.blender.org/wiki/Source/Render/Cycles
Credits:
* Sergey Sharybin
* Brecht Van Lommel
* Patrick Mours (OptiX backend)
* Christophe Hery (subsurface scattering anisotropy)
* William Leeson (PMJ sampling pattern)
* Alaska (various fixes and tweaks)
* Thomas Dinges (various fixes)
For the full commit history, see the cycles-x branch. This squashes together
all the changes since intermediate changes would often fail building or tests.
Ref T87839, T87837, T87836
Fixes T90734, T89353, T80267, T80267, T77185, T69800
The Xcode IDE can also benefit from the options:
- WINDOWS_USE_VISUAL_STUDIO_SOURCE_FOLDERS
- WINDOWS_USE_VISUAL_STUDIO_PROJECT_FOLDERS
So add suport to these options and also renames them as they are no
longer limited to just Windows and Visual Studio.
Reviewed By: brecht, ankitm
Differential Revision: https://developer.blender.org/D12132
After tests were bundled in a single executable and cycles and libmv
created their own tests, the warnings on macOS have gone over 800.
The reason is setting `*_LIBRARIES` to names of the libraries
and later using `link_directories` to link them properly.
https://cmake.org/cmake/help/latest/command/link_directories.html
> Note This command is rarely necessary and should be avoided where
> there are other choices. Prefer to pass full absolute paths to
> libraries where possible, since this ensures the correct library
> will always be linked. The find_library() command provides the
> full path, which can generally be used directly in calls to
> target_link_libraries().
Warnings like the following popup for every target/executable,
for every library it links to.
```
ld: warning: directory not found for option
'-L/Users/me/blender-build/blender/../lib/darwin/jpeg/lib/Debug'
```
The patch completes a step towards removing `link_directories` as
mentioned in TODO at several places.
The patch uses absolute paths to link libraries and removes
all `*_LIBPATH`s except `PYTHON_LIBPATH` from
`platform_apple.cmake` file. (The corner case where it's used seems
like dead code. Python is no longer shipped with that file structure.)
Also, unused code for LLVM-3.4 has been removed.
Also, guards to avoid searching libraries in system directories have
been added.
`APPLE` platform now no longer needs `setup_libdirs`,
`cycles_link_directories`, and `link_directories`.
The number of warnings now is less than 100, most of them being
deprecation ones in dependencies.
This patch depended on {rBb746179d0add}, {rB2fdbe4d05011},
{rB402a4cadba49} and {rBd7f482f88ecb}.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D8855
Caused by f04260d8c6.
Cycles' CMake defines macros with the same name as Blender, which
override the Blender ones. There's however a small difference in the
re-defined `remove_cc_flag()`, the Cycles version only takes one flag at
a time. So I guess Blender's calls to it would only result in the first
flag being removed.
Of course Cycles shouldn't override any Blender macros, but I'll leave
that up to Brecht to fix properly.
* Support precompiled libraries on Linux
* Add license headers
* Refactoring to deduplicate code
Includes work by Ray Molenkamp and Grische for precompiled libraries.
Ref D8769
This change enables the developer option `WITH_CYCLES_NATIVE_ONLY`
for MSVC. This allows a developer to just build the cycles
CPU kernel for their specific system rather than all kernels,
speeding up development.
Other platforms have had this option for years, but MSVC lacks
the compiler switch to target the host architecture hence it
always build all kernels.
This change uses a small helper program to detect the required
flags.
Only AVX/AVX2 are tested, for the following reasons
- SSE2 is enabled by default and requires no flags
- SSE3/4 have no specific build flags for msvc
- AVX512 is not yet supported by cycles
Differential Revision: https://developer.blender.org/D8775
Reviewed by: brecht, sergey
The spelling and capitalization of package name passed to find_package()
and find_package_handle_standard_args() needs to match.
Silences CMake warning about mismatch.
Differential Revision: https://developer.blender.org/D8247
This is a more correct fix to the issue Brecht was fixing in D6600.
While the fix in that patch worked fine for linking it broke ASAN
runtime under some circumstances.
For example, `make full debug developer` would compile, but trying
to start blender will cause assert failure in ASAN (related on check
that ASAN is not running already).
Top-level idea: leave it to CMake to keep track of dependency graph.
The root of the issue comes to the fact that target like "blender" is
configured to use a lot of static libraries coming from Blender sources
and to use external static libraries. There is nothing which ensures
order between blender's and external libraries. Only order of blender
libraries is guaranteed.
It was possible that due to a cycle or other circumstances some of
blender libraries would have been passed to linker after libraries
it uses, causing linker errors.
For example, this order will likely fail:
libbf_blenfont.a libfreetype6.a libbf_blenfont.a
This change makes it so blender libraries are explicitly provided
their dependencies to an external libraries, which allows CMake to
ensure they are always linked against them.
General rule here: if bf_foo depends on an external library it is
to be provided to LIBS for bf_foo.
For example, if bf_blenkernel depends on opensubdiv then LIBS in
blenkernel's CMakeLists.txt is to include OPENSUBDIB_LIBRARIES.
The change is made based on searching for used include folders
such as OPENSUBDIV_INCLUDE_DIRS and adding corresponding libraries
to LIBS ion that CMakeLists.txt. Transitive dependencies are not
simplified by this approach, but I am not aware of any downside of
this: CMake should be smart enough to simplify them on its side.
And even if not, this shouldn't affect linking time.
Benefit of not relying on transitive dependencies is that build
system is more robust towards future changes. For example, if
bf_intern_opensubiv is no longer depends on OPENSUBDIV_LIBRARIES
and all such code is moved to bf_blenkernel this will not break
linking.
The not-so-trivial part is change to blender_add_lib (and its
version in Cycles). The complexity is caused by libraries being
provided as a single list argument which doesn't allow to use
different release and debug libraries on Windows. The idea is:
- Have every library prefixed as "optimized" or "debug" if
separation is needed (non-prefixed libraries will be considered
"generic").
- Loop through libraries passed to function and do simple parsing
which will look for "optimized" and "debug" words and specify
following library to corresponding category.
This isn't something particularly great. Alternative would be to
use target_link_libraries() directly, which sounds like more code
but which is more explicit and allows to have more flexibility
and control comparing to wrapper approach.
Tested the following configurations on Linux, macOS and Windows:
- make full debug developer
- make full release developer
- make lite debug developer
- make lite release developer
NOTE: Linux libraries needs to be compiled with D6641 applied,
otherwise, depending on configuration, it's possible to run into
duplicated zlib symbols error.
Differential Revision: https://developer.blender.org/D6642
Use CMake's target_link_libraries instead of manually maintaining
library dependencies in a single list.
In practice adding new libraries often ended up being guess-work,
now each library lists the libraries it uses.
This was used for the game player executable so libraries
could optionally link to stubs.
If we need this functionality it can be done using target-properties
as described in T46725.
Note that this is turned off by default and must be enabled at build time with the CMake WITH_CYCLES_EMBREE flag.
Embree must be built as a static library with ray masking turned on, the `make deps` scripts have been updated accordingly.
There, Embree is off by default too and must be enabled with the WITH_EMBREE flag.
Using Embree allows for much faster rendering of deformation motion blur while reducing the memory footprint.
TODO: GPU implementation, deduplication of data, leveraging more of Embrees features (e.g. tessellation cache).
Differential Revision: https://developer.blender.org/D3682
I've limited it to just the RGB<->XYZ stuff for now, correct image handling is the next step.
Reviewers: brecht, sergey
Differential Revision: https://developer.blender.org/D3478
This patch changes the huge list of projects in visual studio into a nice tree matching the source folder structure. see D2823 for details.
Differential Revision: http://developer.blender.org/D2823
It is disabled by default, so should not affect existing configurations.
Main benefits of this goes as:
- Linux distros can use that to avoid libraries duplication and link
blender package against gflags package from the system.
- It it easier to test whether Blender works with updated version of
Gflags prior to re-bundling the library.
After CUDA dynload changes having CUDA toolkit became required
in order to compile Cycles. This only happened due to wrong
default value to the option.
The main purpose of such linking is to make Blender compatible with
NVidia's debuggers and profilers which are doing some LD_PRELOAD
magic to intercept some function calls. Such magic conflicts with
our CUDA wrangler magic and causes segmentation faults.
The option is disabled by default, so there's no affect on any of
artists.
In order to make Blender linked directly against CUDA library use
the WITH_CUDA_DYNLOAD CMake option (it's marked as advanced).
This commit contains all the tweaks which were missing in initial patch
re-integration from the standalone Cycles repository.
This commit also contains an utility cmake macro to help linking targets
with different libraries for release/debug builds, the name currently is
target_link_libraries_decoupled
it gets a target and list of libraries and makes sure debug builds are
using libraries with "_d" suffix.
After all this changes it'll hopefully be easier to interchange patches
between blender and standalone repositories, because they're now quite
identical.
This way it is now possible to use gflags >= 2.1, where all the
functions were moved from google to gflags namespace.
This isn't currently used in blender, but for standalone repository
this change is essential.
This applies to an application comiling from the standalone Cycles repository
only.
There's still lack of proper install target, so currently pthreads
library is to be copied next to cycles.exe manually.
