This avoid cmake shenanigans to try to make proper
dependency tracking.
The previous code was not tracking changes inside
the create info files.
There is no real benefit for having these headers listed in
the cmakefile itself.
Pull Request: https://projects.blender.org/blender/blender/pulls/129027
This patch adjusts the GLSL compositor code to avoid writing to
inputting as variables. This is to make it easier to port the code to
CPU. Also, write to the output directly instead of per channel.
This patch implements the multi-function procedure operation for the new
CPU compositor, which is a concrete implementation of the PixelOperation
abstraction, much like ShaderOperation, but uses the FN system to more
efficiently evaluate a group of pixel-wise operations.
A few changes were done to FN to support development. The multi-function
builder now allows retrieving the built function. A new builder method
construct_and_set_matching_fn_cb was added to allow using the SI_SO
builders with non static functions. A few other SI_SO were added to. And
a CPP type for float4 was added.
Additionally, the Gamma, Math, Brightness, and Normal nodes were
implemented as an example. The Math node implementation reused the
existing GN math node implementation, so the code was moved to a common
file.
Reference #125968.
Pull Request: https://projects.blender.org/blender/blender/pulls/126988
Avoid processing function arguments directly and instead create
temporary variables for adjustments. This is done to make it easier to
maintain identical code to CPU.
This patch implements the domain realization algorithm for the new CPU
compositor. Only nearest interpolation with no wrapping is implemented
at the moment.
A new sampling method was added to the result class and some relevant
methods were moved into inline functions.
Move most of the string preprocessing used for MSL
compatibility to `glsl_preprocess`.
Enforce some changes like matrix constructor and
array constructor to the GLSL codebase. This is
for C++ compatibility.
Additionally reduce the amount of code duplication
inside the compatibility code.
Pull Request: https://projects.blender.org/blender/blender/pulls/128634
This changes the include directive to use the standard C preprocessor
`#include` directive.
The regex to applied to all glsl sources is:
`pragma BLENDER_REQUIRE\((\w+\.glsl)\)`
`include "$1"`
This allow C++ linter to parse the code and allow easier codebase
traversal.
However there is a small catch. While it does work like a standard
include directive when the code is treated as C++, it doesn't when
compiled by our shader backends. In this case, we still use our
dependency concatenation approach instead of file injection.
This means that included files will always be prepended when compiled
to GLSL and a file cannot be appended more than once.
This is why all GLSL lib file should have the `#pragma once` directive
and always be included at the start of the file.
These requirements are actually already enforced by our code-style
in practice.
On the implementation, the source needed to be mutated to comment
the `#pragma once` and `#include`. This is needed to avoid GLSL
compiler error out as this is an extension that not all vendor
supports.
Rel #127983
Pull Request: https://projects.blender.org/blender/blender/pulls/128076
Activating render region while using the CPU compositor produces corrupt
output for areas outside of the region when using the File Output node.
That's because the Full Frame compositor ignored nodes' render_border
flag, so the areas of interest of nodes that didn't consider render
border like the File Output were corrupt, producing uninitialized
outputs.
To fix this, we just consider the render_border flag when determining
output areas for output nodes in the Full Frame compositor.
Pull Request: https://projects.blender.org/blender/blender/pulls/128546
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
The File Output node doesn't write invalid and single value layers,
which can cause differences in EXR structures when rendering animations.
To fix this, we write a dummy image that has the same dimensions as the
other layers in the file, filled with the value of the single value
input.
Pull Request: https://projects.blender.org/blender/blender/pulls/128454
The Scale node in the Scale To Render size mode is not precise in case
of the use of render size percentage. This is due to floating point
imprecisions and we mitigate it by rounding instead of flooring after
multiplying by the percentage.
The Kuwahara node produces NaNs if the pixels have a very high local
standard deviation and sharpness is also high. This is because the
weighted sum of the Kuwahara sectors can have a zero total weight, which
causes zero division. To fix this, we return the original color if the
total weight is zero.
Pull Request: https://projects.blender.org/blender/blender/pulls/128378
The Alpha Over node has an unexpected output size in GPU mode. If the
Factor and first Image inputs were connected to the same output, the
size of the output will assume the size of the second Image input, even
though the first Image input has a higher domain priority.
That's because the Alpha Over node is compiled into a Shader Operation
which has a single operation input for all inputs connected to the same
output, but only the domain priority of the first input was considered,
so in the case of the Alpha Over node, the domain priority of the Factor
input was assumed, ignoring the priority of the first Image output.
To fix this, we consider the priority of all inputs connected to the
same output, and assume the highest priority of all.
Pull Request: https://projects.blender.org/blender/blender/pulls/128366
Multiple levels nodes in a row causes blender to freeze when combined with other constant operations. Also, current results of standard deviation are wrong.
The problem was that constant folding optimized constant operations away, which caused a cyclic node graph, and therefore the freeze during node graph evaluation. Preventing such optimizations solves the problem.
Pull Request: https://projects.blender.org/blender/blender/pulls/127316
The Lens Distort node is different between CPU and GPU when jitter is
enabled. That's because GPU incorrectly assumed that jitter with no
dispersion would have no effect. So we fix this by adjusting the
identity condition.
Further more, the green channel was not jittered for the GPU, that's
because the jitter was only seeded by the integration steps and was thus
constant for all channels. And since the green channel is the result of
addition of two opposite accumulations, the green channel was left
unaltered. To fix this, we include the start channel of the integration
in the seed to the jitter to make sure different channels get different
jitter.
Pull Request: https://projects.blender.org/blender/blender/pulls/126993
This patch abstracts away the ShaderOperation class into an asbtract
PixelOperation class, which the ShaderOperation now implemenets. This
makes way for a new subclass that uses FN multi-functions for evaluation
for the new CPU compositor.
Reference #125968.
Use snake style naming for all the kernel nodes functions.
Omit kernel prefix in the names since of the using namespace.
Use full forms of the terms
('iter' -> 'iterator', 'ntree' -> 'node_tree', 'rem' -> 'remove', ...).
Pull Request: https://projects.blender.org/blender/blender/pulls/126416
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 adds support for CPU side buffers for the result class. A new
storage type member was added to identify the type of buffer storage,
and allocation will either allocate a GPU texture or a CPU buffer based
on the context's GPU usage.
This patch allows the result to be allocated using new textures as
opposed to using pooled texture. This is useful to allow the result
class to be used for persistent data like cached resources which can't
be pooled since it spans multiple evaluations.
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
Temporary results are essentially results with a default reference count
of 1, so we default to 1 for all results and set the initial reference
count differently as need.
This patch stores a reference to the entire context in the Result class,
as opposed to just the texture pool. This is in preparation for adding
CPU side texture to the result, such that allocations can automatically
allocate CPU or GPU textures based on context.
