Blender crashes when using the GPU compositor sometimes. This is because
compositor render data was accessed before it was updated in the
realtime compositor when detecting compositing device. So fix that by
first updating compositor data before calling any context methods.
The Legacy Cryptomatte node doesn't work in GPU execution mode if
Precision is set to Auto. That's because the colors picked from the Pick
layer might be in half precision and thus will not match the colors in
the Cryptomatte layers. This is due to the compositor using the
context's precision for Viewer outputs as opposed to the precision of
the image that actually needs to be viewed in the Viewer node.
To fix this, we set the Viewer node precision to be the precision of its
input, that way, the Cryptomatte pick layer will be output in full
precision as intended.
Pull Request: https://projects.blender.org/blender/blender/pulls/128495
This patch supports the viewer node in the new CPU compositor. To do
that, the context viewer output mechanism was refactored to allow CPU
storage by utilizing the result class as opposed to a GPU texture.
This patch introduces a new experimental option for the new CPU
compositor under development. This is to make development easier such
that it happens directly in main, but the compositor is not expected to
work and will probably crash.
Pull Request: https://projects.blender.org/blender/blender/pulls/125960
The viewport compositor slows down complex scenes even if it has very
simple setups. That's because it internally computes previews which
involves a fair bit of CPU computation, however, those previews are
actually never written to the original tree, so previewers weren't
really visible so it is effectively redundantly computations.
To fix this, we double down on disabling previews for the viewport
compositor and avoid any redundant computations in that case.
The vector pass and potentially other vectors that store 4 values are
stored wrongly, in particular, the last channel is ignored. To fix this
we identify if a vector pass is 4D and store the information in the
result meta data, then use this information to either save a 3D or a 4D
pass in the File Output node.
This is a partial fix for the GPU compositor only. The complete fix for
the CPU compositor will be submitted separately as it is not
straightforward and will likely require a refactor.
Pull Request: https://projects.blender.org/blender/blender/pulls/124522
This patch adds support for meta data in the GPU compositor much like
the mechanism that already exist in the CPU compositor. Only Cryptomatte
meta data is handled at the moment because that is the only meta data
that the compositor supports.
The is_data member of the result was moved to the meta data structure for
consistency with the CPU compositor.
Fixes#124222.
Pull Request: https://projects.blender.org/blender/blender/pulls/124460
Blender crashes when rendering a scene strip that references a scene
with a GPU compositor active. This is because when rendering a scene
strip, a new render with a nullptr system GPU context is created for the
scene it references, which is then used for compositing.
Ideally, the strip scene would have its own context, but we can't ensure
its context because we are not in the main thread. The alternative is to
then identify scenes that will be rendered before hand and set their
renders before starting the job, which doesn't seem like a great
solution. So for now, we just use the DST context in those cases.
Pull Request: https://projects.blender.org/blender/blender/pulls/123057
The system context is expected to be bound prior to the Blender
can be properly initialized. Otherwise GHOST will be doing OpenGL
calls without system context bound.
This follows code from DRW_render_context_enable().
Pull Request: https://projects.blender.org/blender/blender/pulls/122708
This patch refactors the GPU context handing in the GPU compositor.
First, GPU context handling in the GPU compositor constructor was
removed, that's because the constructor does nothing GPU related.
Second, the destructor and the execute methods were unified to use the
global DST context for main thread execution and a dedicated system GPU
context for threaded execution. The former is the case for blocking
rendering as well as background mode, so the blocking due to the global
DST is not an issue, but it makes the code more robust to implementation
errors like #122070.
Pull Request: https://projects.blender.org/blender/blender/pulls/122389
This patch adds support for timing GPU compositor executions. This was
previously not possible since there was no mechanism to measure GPU
calls, which is still the case. However, since 2cf8b5c4e1, we now flush
GPU calls immediately for interactive editing, so we can now measure the
GPU evaluation on the host, which is not a very accurate method, but it
is better than having no timing information. Therefore, timing is only
implemented for interactive editing.
This is different from the CPU implementation in that it measures the
total evaluation time, including any preprocessing of the inputs like
implicit type conversion as well as things like previews.
The profiling implementation was moved to the realtime compositor since
the compositor module is optional.
Pull Request: https://projects.blender.org/blender/blender/pulls/122230
The issue originates to the change in default view transform from Filmic
to AgX, which does slightly different clipping, and clips color to black
if there is any negative values.
This change implements an idea of skipping view transform for viewer
node when it is connected to the Pick output of the cryptomatte node.
It actually goes a bit deeper than this and any operation can tag its
result as a non-color data, and the viewer node will respect that.
It is achieved by passing some extra meta-data along the evaluation
pipeline. For the CPU compositor it is done via MetaData, and for the
GPU compositor it is done as part of Result.
Connecting any other node in-between of viewer and Cryptomatte's Pick
will treat the result as color values, and apply color management.
Connecting Pick to the Composite output will also consider it as color,
since there is no concept of non-color-managed render result.
An alternative approaches were tested, including:
- Doing negative value clamping at the viewer node.
It does not work for legacy cryptomatte node, as it needs to have
access to original non-modified Pick result.
- Change the order of components, and store ID in another channel.
Using one of other of Green or Blue channels might work for some view
transforms, but it does not work for AgX.
Using Alpha channel seemingly works better, but it is has different
issues caused by the fact that display transform de-associates alpha,
leading to over-exposed regions which are hard to see in the file from
the report. And might lead to the similar issues as the initial report
with other objects or view transforms.
- Use positive values in the Pick channel.
It does make things visible, but they are all white due to the nature
of how AgX works, making it not so useful as a result.
Pull Request: https://projects.blender.org/blender/blender/pulls/122177
Blender crashes when calling the python render operator when GPU
compositor execution is enabled. This is due to a missing system GPU
context, which is not initialized for blocking rendering. So this patch
ensures the system GPU context before compositing. Additionally, it
removes the assert that ensures a non main thread execution, since the
assumption apparently does not really hold.
Pull Request: https://projects.blender.org/blender/blender/pulls/122176
This allows to expose these settings in the Performance panel in the
render buttons. Also moves compositor-specific options away from the
generic node tree structure.
For the backwards-compatibility the options are still present in the
DNA for the bNodeTree. This is to minimize the impact on the Studio
which has used the GPU compositor for a while now. They can be
removed in a future release.
There is no functional changes expected.
Pull Request: https://projects.blender.org/blender/blender/pulls/121583
The compositor execute functions have a `rendering` argument to specify
if the compositor is executing as part of the render pipeline. But the
render context argument is null if we are not rendering, so the
`rendering` arguement is redundant and can be removed.
Additionally, we no longer use use_file_output as a hack to detect
rendering.
Pull Request: https://projects.blender.org/blender/blender/pulls/120659
This patch improves the interactivity of the GPU compositor for
interactive node tree edits by waiting on GPU work to finish to support
more granular canceling.
This does have a performance penalty, but it does not affect final
rendering and it seems worth it because even though it is slower it will
feel faster for users.
Pull Request: https://projects.blender.org/blender/blender/pulls/120656
This patch refactors the backdrop offset to be stored as a float instead
of an int and to be stored in the image runtime structure instead of the
image itself.
Pull Request: https://projects.blender.org/blender/blender/pulls/119877
This required to apply a small fix in the Metal texture uploader.
Without synchronization pixels of a wrong pass can be uploaded to
a wrong texture. This is because this code path is heavily reusing
temporary allocations, and at some point the allocation is not
considered as still in use, unless the command buffer used by the
texture uploader is submitted.
Ref #118919
Pull Request: https://projects.blender.org/blender/blender/pulls/118920
The non-locking context activation expects the render engine to
have its own GPU contexts, which is not necessarily the case when
compositing happens from the command line.
Ensure that the contexts exist prior to attempt of activating them.
Pull Request: https://projects.blender.org/blender/blender/pulls/118496
The GPU compositor does not take the border region into consideration,
which means it reads more than it should, leading to corruption. Fix
this by taking the border region into account when computing render
width and height.
It is not required to hold the lock of DST when performing
compositing on GPU, as the compositor implementation uses the
GPU module directly, bypassing the draw manager.
However, currently this is known to cause issues on macOS,
and is not yet tested on Windows.
On Linux it works correctly, and avoids lock while compositor
is running.
There could still be a small locking hiccup, when the GPU
context is created and disposed. This needs to be looked
into.
Pull Request: https://projects.blender.org/blender/blender/pulls/118286
An assert that ensures the GPU compositor executes in a non main thread
wrongly fires in background mode, that's because in background mode,
rendering happens in the main thread. So add a condition for background
mode.
This patches refactors the compositor File Output mechanism and
implements the file output node for the Realtime Compositor. The
refactor was done for the following reasons:
1. The existing file output mechanism relied on a global EXR image
resource where the result of each compositor execution for each
view was accumulated and stored in the global resource, until the
last view is executed, when the EXR is finally saved. Aside from
relying on global resources, this can cause effective memory leaks
since the compositor can be interrupted before the EXR is written and
closed.
2. We need common code to share between all compositors since we now
have multiple compositor implementations.
3. We needed to take the opportunity to fix some of the issues with the
existing implementation, like lossy compression of data passes,
and inability to save single values passes.
The refactor first introduced a new structure called the Compositor
Render Context. This context stores compositor information related to
the render pipeline and is persistent across all compositor executions
of all views. Its extended lifetime relative to a single compositor
execution lends itself well to store data that is accumulated across
views. The context currently has a map of File Output objects. Those
objects wrap a Render Result structure and can be used to construct
multi-view images which can then be saved after all views are executed
using the existing BKE_image_render_write function.
Minor adjustments were made to the BKE and RE modules to allow saving
using the BKE_image_render_write function. Namely, the function now
allows the use of a source image format for saving as well as the
ability to not save the render result as a render by introducing two new
default arguments. Further, for multi-layer EXR saving, the existent of
a single unnamed render layer will omit the layer name from the EXR
channel full name, and only the pass, view, and channel ID will remain.
Finally, the Render Result to Image Buffer conversion now take he number
of channels into account, instead of always assuming color channels.
The patch implements the File Output node in the Realtime Compositor
using the aforementioned mechanisms, replaces the implementation of the
CPU compositor using the same Realtime Compositor implementation, and
setup the necessary logic in the render pipeline code.
Pull Request: https://projects.blender.org/blender/blender/pulls/113982
The Realtime compositor currently relies on the GPU cache in image IDs.
That cache only supports single layer images, so multi-layer images will
be acquired without a cache, introducing significant IO bottlenecks for
the GPU compositor.
This patch ignores the image GPU cache and stores the images in the
static cache manager of the compositor. Draw data was introduced to the
image ID for proper cache invalidation, like other IDs such as masks.
The downside is that the cache will no longer be shared between EEVEE
and the compositor. But realistically, images are not typically shared
between materials and compositors.
This is just a temporary solution until we have proper GPU storage
support for image buffers.
Pull Request: https://projects.blender.org/blender/blender/pulls/115511
This patch adds support for full precision compositing for the Realtime
Compositor. A new precision option was added to the compositor to change
between half and full precision compositing, where the Auto option uses
half for the viewport compositor and the interactive render compositor,
while full is used for final renders.
The compositor context now need to implement the get_precision() method
to indicate its preferred precision. Intermediate results will be stored
using the context's precision, with a number of exceptions that can use
a different precision regardless of the context's precision. For
instance, summed area tables are always stored in full float results
even if the context specified half float. Conversely, jump flooding
tables are always stored in half integer results even if the context
specified full. The former requires full float while the latter has no
use for it.
Since shaders are created for a specific precision, we need two variants
of each compositor shader to account for the context's possible
precision. However, to avoid doubling the shader info count and reduce
boilerplate code and development time, an automated mechanism was
employed. A single shader info of whatever precision needs to be added,
then, at runtime, the shader info can be adjusted to change the
precision of the outputs. That shader variant is then cached in the
static cache manager for future processing-free shader retrieval.
Therefore, the shader manager was removed in favor of a cached shader
container in the static cache manager.
A number of utilities were added to make the creation of results as well as
the retrieval of shader with the target precision easier. Further, a
number of precision-specific shaders were removed in favor of more
generic ones that utilizes the aforementioned shader retrieval
mechanism.
Pull Request: https://projects.blender.org/blender/blender/pulls/113476
The experimental GPU compositor is leaking memory in any setup.
This is because the current implementation of the render texture pool
always created a new texture and only freed the textures upon deletion.
This was a temporary implementation until a proper implementation that
uses the DRW textures pool was used.
This patch implements a small texture pool as a temporary fix until the
aforementioned DRW texture pool implementation is done.
The GPU compositor crops the viewed images to the render resolution.
While the original size and content of the input to the viewer should be
retained as is.
This patch fixes that by specializing compositors that can use composite
outputs to be able to view images of any arbitrary size. This is still
missing the translation offset of the viewer, but this shall be tackled
separately.
The experimental GPU compositor always returned the first view in
multi-view rendering. This patch fixes that by also checking for the
view name of the context when searching for the appropriate pass.
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.
The C-style API is still in place, but the implementation
is moved to a virtual method.
This is part of unification of viewport and final render
structure.
Should be no functional changes.
Ref #108618
Pull Request: https://projects.blender.org/blender/blender/pulls/110696
Historically, the OCIO based color management implementation in Blender
had exceptions to treat specific configurations differently. It was a
compatibility with the legacy "No color management" option.
With time and more development in the area there are better ways of
achieving this goal, if needed.
This commit removes the named-based exception, which also solves confusion
about why certain similar configurations (from OCIO stand point) give
different results. As well as allows to create a cleaner plate for an
upcoming additions in the OCIO configuration such as AgX.
Quite simple and technical change which constant-folds the check for
whether the scene color management enabled or not with "true" value.
Ref #110685
Pull Request: https://projects.blender.org/blender/blender/pulls/110580
This change fixes crash which happens when a viewer node is used for
backdrop, and the scene render size is modified. After the modification
the render size and the texture size gets out of sync since the texture
was never adapting for the size change.
Pull Request: https://projects.blender.org/blender/blender/pulls/110590
Doing so avoids having duplicated logic for working with pixel
data which is being passed throughout the render pipeline.
Notable changes:
- ImBug can now store GPU texture.
This is not very finished part of the API, which will be
worked further to support tiling for very-high-res images.
- Implicit sharing is removed from the image buffer, as it is
no longer needed.
There should be no functional changes on user level with this
change.
Ref #108618
Pull Request: https://projects.blender.org/blender/blender/pulls/109788
