New ("fullframe") CPU compositor backend is being used now, and all the code
related to "tiled" CPU compositor is just never used anymore. The new backend
is faster, uses less memory, better matches GPU compositor, etc.
TL;DR: 20 thousand lines of code gone.
This commit:
- Removes various bits and pieces related to "tiled" compositor (execution
groups, one-pixel-at-a-time node processing, read/write buffer operations
related to node execution groups).
- "GPU" (OpenCL) execution device, that was only used by several nodes of
the tiled compositor.
- With that, remove CLEW external library too, since nothing within Blender
uses OpenCL directly anymore.
Pull Request: https://projects.blender.org/blender/blender/pulls/118819
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.
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/
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
Adds full frame implementation to "Bokeh Image" node, "Track Position"
node, `SetVectorOperation` and `MovieClipAttribute`.
The other nodes in "Input" submenu are implemented separately.
`MovieClipAttribute` needs resolution to calculate its constant value, it can't be constant folded,
which requires it to be a `ConstantOperation`. Now `ConstantOperation` contemplate this case
and any operation that is always constant without depending on inputs should implement it.
If in the future an operation needs to get an input constant element during
`determineResolution` it must first determine its input resolution.
The nodes have no functional changes.
Reviewed By: jbakker
Differential Revision: https://developer.blender.org/D12090
Adds full frame implementation to this node operations.
No functional changes.
Includes a new operation method `init_data` used to initialize any data
needed after operations are linked and resolutions determined.
Once tiled implementation is removed `initExecution` may be renamed
to `init_rendering` and `init_data` to `init_execution`.
Reviewed By: jbakker
Differential Revision: https://developer.blender.org/D11944
Work scheduler needed initialization and execution models are
not created during constant folding. This moves work execution
method to execution system.
Currently there is no clear way to know if an operation is constant
(i.e. when all rendered pixels have same values). Operations may
need to get constant input values before rendering to determine
their resolution or areas of interest. This is the case of scale, rotate
and translate operations. Only "set operations" are known as
constant but many more are constant when all their inputs are so.
Such cases can be optimized by only rendering one pixel.
Current solution for tiled implementation is to get first pixel
from input. This works for root execution groups, others
need previous groups to be rendered.
On full frame implementation this is not possible, because buffers
are created on rendering to reduce peak memory and there is
no per pixel calls.
This patch evaluates all operations that are constant into primitive
operations (Value/Vector/Color) before determining resolutions.
Reviewed By: jbakker
Differential Revision: https://developer.blender.org/D11490
