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
The new Clang which came with XCode 15 introduced the new
warning: -Wsingle-bit-bitfield-constant-conversion. It is a bit
too noisy in the Bullet code.
Since the warning is in the code which we do not maintain suppress
it similar to other similar warnings.
Pull Request: https://projects.blender.org/blender/blender/pulls/113136
Tests must be enabled manually using the CMake flag `WITH_COMPOSITOR_REALTIME_TEST`. Reasons are F12 for realtime compositor is experimental and buildbots have no GPU. Failing tests are excluded.
Pull Request: https://projects.blender.org/blender/blender/pulls/109878
This renames the WITH_WINDOWS_PDB and WITH_WINDOWS_STRIPPED_PDB cmake
options to WITH_WINDOWS_RELEASE_PDB WITH_WINDOWS_RELEASE_STRIPPED_PDB
The Stripped PDB isn't cost free to generate, and is only needed for
builds that are distributed to end users. There is no benefit in making
one for a debug build as the debugger locally will prefer to use the
bigger un-stripped PDB anyhow.
This also stops the copy/install of the PDB for anything but a release
build, this file is about 1.6G for a debug build, and there is really
no need to do this for local development, as the debugger will find/use
the PDB from its original location.
This brings down the time needed for an incremental link on a debug
build by about 30% (10->7 seconds on my local system)
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.
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
The maximum OpenGL versions supported on mac
doesn't meet the minimum required version (>=4.3) anymore.
This removes all the OpenGL paths in GHOST
Cocoa backend and from the drop down menu in
the user preferences.
Pull Request: https://projects.blender.org/blender/blender/pulls/110185
Ever since #107858 landed builds of a single library from a clean state
were significant heavier than they used to the since the full dependency
chain is being build. While this is desired behavior since some projects
emit artefacts (like bf_dna's dna_type_offsets.h) for others given we
are building static libraries that don't actually get linked until the
very end this is unneeded. CMake offers a flag here to optimize this
called CMAKE_OPTIMIZE_DEPENDENCIES. See the CMake docs for details
what this exactly does.
This diff changes the default for CMAKE_OPTIMIZE_DEPENDENCIES from
Off to On for all CMake versions that support it. If people desire to
do so, this flag can still be changed though CMakeCache.txt
Pull Request: https://projects.blender.org/blender/blender/pulls/109672
The -Wundef was already added to the GCC compiler, but not
to the Clang compiler.
This allows catching cases when code accesses define variable
which has not been defined yet, for example `#if SOME_VAR` without
having `#define SOME_WAV <value>`.
The exact difference between undef and undef-prefix is not fully
clear, this is just something that seems empirically be needed.
This change discovers access to undefined WITH_METAL in the
GHOST_ContextCGL.mm, which needs to be looked into separately.
Happens with specific GPUs like NVIDIA A100-SXM4-40GB. They use the
compute capability 8.0, which is not explicitly compiled as a cubin,
and since 7fca0ee76a the PTX is not suitable for it either.
The safest solution is to revert the change to a known good state,
and re-iterate as needed.
Revert "Cycles: Increase the compute model for the PTX kernel"
This reverts commit 7fca0ee76a.
This change would need to be cherry-picked to the 3.6 LTS.
Pull Request: https://projects.blender.org/blender/blender/pulls/109636
Keep the PTX compute capability at the same level as the latest
architecture-optimized CUDA kernel.
Should help performance of the future cards when running older
Blender, and maybe will allow to perform JIT optimization faster.
Pull Request: https://projects.blender.org/blender/blender/pulls/109007
This PR adds conversion template to convert between Low Precision float
formats. These include Binary32 floats and lower. It also adds support
to convert between unsigned and signed float formats and float formats
with different mantissa and exponents.
Additionally overflows (values that don't fit in the target float
format) will be clamped to the maximum value.
**Reasoning**:
Up to now the Vulkan backend only supported float and half float
formats, but to support workbench, 11 and 10 unsigned floats have to be
supported as well. The available libraries that support those float
formats targets scientific applications. Where the final code couldn't
be optimized that well by the compiler.
Data conversion for color pixels have different requirements about
clamping and sign, what could eliminate some clamping code in other
areas in Blender as well. Also could fix some undesired overflow when
using pixels with high intensity that didn't fit in the texture format
leading to known artifects in Eevee and slow-down in the image editor.
**Future**
In the future we might want to move this to the public part of the GPU
module so we can use this as well in other areas (Metal backend), Imbuf clamping
See 3c658d2c2e69e9cf97dfaa7a3c164262aefb9e76 for a commit that uses
this and improves image editor massively as it doesn't need to reiterate over
the image buffer to clamp the values into a known range.
Pull Request: https://projects.blender.org/blender/blender/pulls/108168
While the multiscattering GGX code is cool and solves the darkening problem at higher roughnesses, it's also currently buggy, hard to maintain and often impractical to use due to the higher noise and render time.
In practice, though, having the exact correct directional distribution is not that important as long as the overall albedo is correct and we a) don't get the darkening effect and b) do get the saturation effect at higher roughnesses.
This can simply be achieved by adding a second lobe (https://blog.selfshadow.com/publications/s2017-shading-course/imageworks/s2017_pbs_imageworks_slides_v2.pdf) or scaling the single-scattering GGX lobe (https://blog.selfshadow.com/publications/turquin/ms_comp_final.pdf). Both approaches require the same precomputation and produce outputs of comparable quality, so I went for the simple albedo scaling since it's easier to implement and more efficient.
Overall, the results are pretty good: All scenarios that I tested (Glossy BSDF, Glass BSDF, Principled BSDF with metallic or transmissive = 1) pass the white furnace test (a material with pure-white color in front of a pure-white background should be indistinguishable from the background if it preserves energy), and the overall albedo for non-white materials matches that produced by the real multi-scattering code (with the expected saturation increase as the roughness increases).
In order to produce the precomputed tables, the PR also includes a utility that computes them. This is not built by default, since there's no reason for a user to run it (it only makes sense for documentation/reproducibility purposes and when making changes to the microfacet models).
Pull Request: https://projects.blender.org/blender/blender/pulls/107958
Windows file associations using ProgID, needed because of the launcher.
This fixes "pin to taskbar" and Recent Documents lists, allow per-
version jump lists and an "Open with" list with multiple versions.
Pull Request: https://projects.blender.org/blender/blender/pulls/107013
The file is specific for the builds created by the Blender Foundation
and strictly speaking should only be used by builds created on our
release environment.
This change introduces a CMake option which is disabled by default and
which will be enabled on our buildbot.
Ref #107295
Pull Request: https://projects.blender.org/blender/blender/pulls/108191
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
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.
HIP RT enables AMD hardware ray tracing on RDNA2 and above, and falls back to a
to shader implementation for older graphics cards. It offers an average 25%
sample rendering rate improvement in Cycles benchmarks, on a W6800 card.
The ray tracing feature functions are accessed through HIP RT SDK, available on
GPUOpen. HIP RT traversal functionality is pre-compiled in bitcode format and
shipped with the SDK.
This is not yet enabled as there are issues to be resolved, but landing the
code now makes testing and further changes easier.
Known limitations:
* Not working yet with current public AMD drivers.
* Visual artifact in motion blur.
* One of the buffers allocated for traversal has a static size. Allocating it
dynamically would reduce memory usage.
* This is for Windows only currently, no Linux support.
Co-authored-by: Brecht Van Lommel <brecht@blender.org>
Ref #105538
Using the new HIP SDK 5.5 that includes a fix for the compiler bug.
This also enables the light tree.
For Linux the binaries are still disabled. ROCm 5.5 is planned to
include the same fix but not released yet. When that happens we
should be able to enable Linux as well.
Ref #104786Fix#104085
Pull Request: https://projects.blender.org/blender/blender/pulls/107098
This checkin will use OIIO to replace the image save/load code for BMP,
DDS, DPX, HDR, PNG, TGA, and TIFF.
This simplifies our build environment, reduces binary duplication,
removes large amounts of hard to maintain code, and fixes some bugs
along the way.
It should also help reduce rare differences between Blender and Cycles
which already uses OIIO for most situations. Or potentially makes them
easier to solve once discovered.
This is a continuation of the work for #101413
Pull Request: https://projects.blender.org/blender/blender/pulls/105785
When using ASAN on Clang / Linux, the call to `find_library(... asan ...)`
works against us, as it finds GCC's `libasan.so`. To work with Clang,
we should simply not pass any explicit library, as Clang will figure things
out by itself with the `-fsanitize=xxx` options.
Furthermore, Clang is incompatible with `-fsanitize=object-size`, so that's
now also no longer passed on Linux (mimicking the Apple) configuration.
For the long run, it would be better to rewrite this entire section to
select behaviour on a per-compiler basis, rather than per platform. That's
tracked in #105956
Pull Request: https://projects.blender.org/blender/blender/pulls/106675
OpenEXR has some dependecies that other other modules in Blender
requires. When disabling OpenEXR these dependecies could not match
and building blender would fail.
This PR disables the next options when `WITH_IMAGE_OPENEXR=Off`
- `WITH_OPENVDB`
- `WITH_ALEMBIC`
- `WITH_VULKAN_BACKEND`
- `WITH_CYCLES_OSL`
Additionally windows stores the IMath libraries in `IMATH_LIBRARIES`
Linux and Mac stored the IMath libraries in `IMATH_LIBRARY`. This
change will also adds `IMATH_LIBRARIES` variable to all platforms.
Pull Request: https://projects.blender.org/blender/blender/pulls/106209
The goal is to solve confusion of the "All rights reserved" for licensing
code under an open-source license.
The phrase "All rights reserved" comes from a historical convention that
required this phrase for the copyright protection to apply. This convention
is no longer relevant.
However, even though the phrase has no meaning in establishing the copyright
it has not lost meaning in terms of licensing.
This change makes it so code under the Blender Foundation copyright does
not use "all rights reserved". This is also how the GPL license itself
states how to apply it to the source code:
<one line to give the program's name and a brief idea of what it does.>
Copyright (C) <year> <name of author>
This program is free software ...
This change does not change copyright notice in cases when the copyright
is dual (BF and an author), or just an author of the code. It also does
mot change copyright which is inherited from NaN Holding BV as it needs
some further investigation about what is the proper way to handle it.
This PR uses renderdoc for frame capturing when enabled.
It enabled an easier workflow for frame capturing.
- Capture GPU API calls from test cases
- Capture GPU API calls from background threads
- Capture GPU API calls from background rendering.
Renderdoc is an important GPU debugger used by the Eevee/
Viewport module. Previously we needed to change code in
order to record background rendering, that could on its own
lead to other side-effects.
The integration with renderdoc can be enabled using
`WITH_RENDERDOC=On` compiler option. `GPU_debug_capture_begin`
and `GPU_debug_capture_end` can be added to the section
of the code you want to debug. When running Blender inside
renderdoc this part will automatically be captured.
All GPU test cases are now guarded by these calls. In order
to capture the test cases you need to start the test cases
from renderdoc and the captured GPU API calls will appear
where each capture is a single test case.
Pull Request: https://projects.blender.org/blender/blender/pulls/105921
Campbell Barton
Jeroen Bakker
Sergey Sharybin
Habib Gahbiche
Ray Molenkamp
Brecht Van Lommel
bsavery
Bogdan Nagirniak
Clément Foucault
Lukas Stockner
Harley Acheson
Sebastian Parborg
Sahar A. Kashi
Brecht Van Lommel
Ankit Meel
Jesse Yurkovich
Sybren A. Stüvel