tmaq
/
tornavis
1
0
Fork 0
Code Issues 2 Pull Requests 29 Packages Projects 24 Releases Wiki Activity
tornavis/source/blender/functions/FN_lazy_function_graph.hh

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

540 lines
12 KiB
C++
Raw Normal View History

License Headers: Set copyright to "Blender Authors", add AUTHORS 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.
2023-08-15 16:20:26 +02:00
/* SPDX-FileCopyrightText: 2023 Blender Authors
Cleanup: Add a copyright notice to files and use SPDX format 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/
2023-05-31 16:19:06 +02:00
*
* SPDX-License-Identifier: GPL-2.0-or-later */
Geometry Nodes: new evaluation system This refactors the geometry nodes evaluation system. No changes for the user are expected. At a high level the goals are: * Support using geometry nodes outside of the geometry nodes modifier. * Support using the evaluator infrastructure for other purposes like field evaluation. * Support more nodes, especially when many of them are disabled behind switch nodes. * Support doing preprocessing on node groups. For more details see T98492. There are fairly detailed comments in the code, but here is a high level overview for how it works now: * There is a new "lazy-function" system. It is similar in spirit to the multi-function system but with different goals. Instead of optimizing throughput for highly parallelizable work, this system is designed to compute only the data that is actually necessary. What data is necessary can be determined dynamically during evaluation. Many lazy-functions can be composed in a graph to form a new lazy-function, which can again be used in a graph etc. * Each geometry node group is converted into a lazy-function graph prior to evaluation. To evaluate geometry nodes, one then just has to evaluate that graph. Node groups are no longer inlined into their parents. Next steps for the evaluation system is to reduce the use of threads in some situations to avoid overhead. Many small node groups don't benefit from multi-threading at all. This is much easier to do now because not everything has to be inlined in one huge node tree anymore. Differential Revision: https://developer.blender.org/D15914
2022-09-13 08:44:26 +02:00
#pragma once
/** \file
* \ingroup fn
*
* This file contains a graph data structure that allows composing multiple lazy-functions into a
* combined lazy-function.
*
* There are two types of nodes in the graph:
* - #FunctionNode: Corresponds to a #LazyFunction. The inputs and outputs of the function become
* input and output sockets of the node.
Functions: refactor lazy-function graph interface Goals of the refactor: * Simplify adding (named) graph inputs and outputs. * Add ability to refer to a graph input or output with an index. * Get rid of the "dummy" terminology which doesn't really help. Previously, one would add "dummy nodes" which can then serve as input and output nodes of the graph. Now one directly adds input and outputs using `Graph.add_input` and `Graph.add_output`. There is one interface node that contains all inputs and another one that contains all outputs. Being able to refer to a graph input or output with an index makes it more efficient to implement some algorithms. E.g. one could have a bit span for a socket that contains all the information what graph inputs this socket depends on. Pull Request: https://projects.blender.org/blender/blender/pulls/112474
2023-09-17 13:54:09 +02:00
* - #InterfaceNode: Is used to indicate inputs and outputs of the entire graph. It can have an
Geometry Nodes: new evaluation system This refactors the geometry nodes evaluation system. No changes for the user are expected. At a high level the goals are: * Support using geometry nodes outside of the geometry nodes modifier. * Support using the evaluator infrastructure for other purposes like field evaluation. * Support more nodes, especially when many of them are disabled behind switch nodes. * Support doing preprocessing on node groups. For more details see T98492. There are fairly detailed comments in the code, but here is a high level overview for how it works now: * There is a new "lazy-function" system. It is similar in spirit to the multi-function system but with different goals. Instead of optimizing throughput for highly parallelizable work, this system is designed to compute only the data that is actually necessary. What data is necessary can be determined dynamically during evaluation. Many lazy-functions can be composed in a graph to form a new lazy-function, which can again be used in a graph etc. * Each geometry node group is converted into a lazy-function graph prior to evaluation. To evaluate geometry nodes, one then just has to evaluate that graph. Node groups are no longer inlined into their parents. Next steps for the evaluation system is to reduce the use of threads in some situations to avoid overhead. Many small node groups don't benefit from multi-threading at all. This is much easier to do now because not everything has to be inlined in one huge node tree anymore. Differential Revision: https://developer.blender.org/D15914
2022-09-13 08:44:26 +02:00
* arbitrary number of sockets.
*/
#include "BLI_linear_allocator.hh"
#include "FN_lazy_function.hh"
BLI: improve node graph export in dot format This makes it bit easier to export node graphs and also allows for more customization of links and sockets.
2022-12-29 15:09:52 +01:00
namespace blender::dot {
class DirectedEdge;
}
Geometry Nodes: new evaluation system This refactors the geometry nodes evaluation system. No changes for the user are expected. At a high level the goals are: * Support using geometry nodes outside of the geometry nodes modifier. * Support using the evaluator infrastructure for other purposes like field evaluation. * Support more nodes, especially when many of them are disabled behind switch nodes. * Support doing preprocessing on node groups. For more details see T98492. There are fairly detailed comments in the code, but here is a high level overview for how it works now: * There is a new "lazy-function" system. It is similar in spirit to the multi-function system but with different goals. Instead of optimizing throughput for highly parallelizable work, this system is designed to compute only the data that is actually necessary. What data is necessary can be determined dynamically during evaluation. Many lazy-functions can be composed in a graph to form a new lazy-function, which can again be used in a graph etc. * Each geometry node group is converted into a lazy-function graph prior to evaluation. To evaluate geometry nodes, one then just has to evaluate that graph. Node groups are no longer inlined into their parents. Next steps for the evaluation system is to reduce the use of threads in some situations to avoid overhead. Many small node groups don't benefit from multi-threading at all. This is much easier to do now because not everything has to be inlined in one huge node tree anymore. Differential Revision: https://developer.blender.org/D15914
2022-09-13 08:44:26 +02:00
namespace blender::fn::lazy_function {
class Socket;
class InputSocket;
class OutputSocket;
class Node;
class Graph;
/**
* A #Socket is the interface of a #Node. Every #Socket is either an #InputSocket or #OutputSocket.
* Links can be created from output sockets to input sockets.
*/
class Socket : NonCopyable, NonMovable {
protected:
/**
* The node the socket belongs to.
*/
Node *node_;
/**
* Data type of the socket. Only sockets with the same type can be linked.
*/
const CPPType *type_;
/**
* Indicates whether this is an #InputSocket or #OutputSocket.
*/
bool is_input_;
/**
* Index of the socket. E.g. 0 for the first input and the first output socket.
*/
int index_in_node_;
Geometry Nodes: deterministic anonymous attribute lifetimes Previously, the lifetimes of anonymous attributes were determined by reference counts which were non-deterministic when multiple threads are used. Now the lifetimes of anonymous attributes are handled more explicitly and deterministically. This is a prerequisite for any kind of caching, because caching the output of nodes that do things non-deterministically and have "invisible inputs" (reference counts) doesn't really work. For more details for how deterministic lifetimes are achieved, see D16858. No functional changes are expected. Small performance changes are expected as well (within few percent, anything larger regressions should be reported as bugs). Differential Revision: https://developer.blender.org/D16858
2023-01-05 14:05:30 +01:00
/**
* Index of the socket in the entire graph. Every socket has a different index.
*/
int index_in_graph_;
Geometry Nodes: new evaluation system This refactors the geometry nodes evaluation system. No changes for the user are expected. At a high level the goals are: * Support using geometry nodes outside of the geometry nodes modifier. * Support using the evaluator infrastructure for other purposes like field evaluation. * Support more nodes, especially when many of them are disabled behind switch nodes. * Support doing preprocessing on node groups. For more details see T98492. There are fairly detailed comments in the code, but here is a high level overview for how it works now: * There is a new "lazy-function" system. It is similar in spirit to the multi-function system but with different goals. Instead of optimizing throughput for highly parallelizable work, this system is designed to compute only the data that is actually necessary. What data is necessary can be determined dynamically during evaluation. Many lazy-functions can be composed in a graph to form a new lazy-function, which can again be used in a graph etc. * Each geometry node group is converted into a lazy-function graph prior to evaluation. To evaluate geometry nodes, one then just has to evaluate that graph. Node groups are no longer inlined into their parents. Next steps for the evaluation system is to reduce the use of threads in some situations to avoid overhead. Many small node groups don't benefit from multi-threading at all. This is much easier to do now because not everything has to be inlined in one huge node tree anymore. Differential Revision: https://developer.blender.org/D15914
2022-09-13 08:44:26 +02:00
friend Graph;
public:
bool is_input() const;
bool is_output() const;
int index() const;
Geometry Nodes: deterministic anonymous attribute lifetimes Previously, the lifetimes of anonymous attributes were determined by reference counts which were non-deterministic when multiple threads are used. Now the lifetimes of anonymous attributes are handled more explicitly and deterministically. This is a prerequisite for any kind of caching, because caching the output of nodes that do things non-deterministically and have "invisible inputs" (reference counts) doesn't really work. For more details for how deterministic lifetimes are achieved, see D16858. No functional changes are expected. Small performance changes are expected as well (within few percent, anything larger regressions should be reported as bugs). Differential Revision: https://developer.blender.org/D16858
2023-01-05 14:05:30 +01:00
int index_in_graph() const;
Geometry Nodes: new evaluation system This refactors the geometry nodes evaluation system. No changes for the user are expected. At a high level the goals are: * Support using geometry nodes outside of the geometry nodes modifier. * Support using the evaluator infrastructure for other purposes like field evaluation. * Support more nodes, especially when many of them are disabled behind switch nodes. * Support doing preprocessing on node groups. For more details see T98492. There are fairly detailed comments in the code, but here is a high level overview for how it works now: * There is a new "lazy-function" system. It is similar in spirit to the multi-function system but with different goals. Instead of optimizing throughput for highly parallelizable work, this system is designed to compute only the data that is actually necessary. What data is necessary can be determined dynamically during evaluation. Many lazy-functions can be composed in a graph to form a new lazy-function, which can again be used in a graph etc. * Each geometry node group is converted into a lazy-function graph prior to evaluation. To evaluate geometry nodes, one then just has to evaluate that graph. Node groups are no longer inlined into their parents. Next steps for the evaluation system is to reduce the use of threads in some situations to avoid overhead. Many small node groups don't benefit from multi-threading at all. This is much easier to do now because not everything has to be inlined in one huge node tree anymore. Differential Revision: https://developer.blender.org/D15914
2022-09-13 08:44:26 +02:00
InputSocket &as_input();
OutputSocket &as_output();
const InputSocket &as_input() const;
const OutputSocket &as_output() const;
const Node &node() const;
Node &node();
const CPPType &type() const;
std::string name() const;
Functions: add debug utility for lazy function graphs This makes it easier to print information about a socket. Just the socket name is sometimes not enough information to know where it is in the graph.
2023-01-20 13:39:10 +01:00
std::string detailed_name() const;
Geometry Nodes: new evaluation system This refactors the geometry nodes evaluation system. No changes for the user are expected. At a high level the goals are: * Support using geometry nodes outside of the geometry nodes modifier. * Support using the evaluator infrastructure for other purposes like field evaluation. * Support more nodes, especially when many of them are disabled behind switch nodes. * Support doing preprocessing on node groups. For more details see T98492. There are fairly detailed comments in the code, but here is a high level overview for how it works now: * There is a new "lazy-function" system. It is similar in spirit to the multi-function system but with different goals. Instead of optimizing throughput for highly parallelizable work, this system is designed to compute only the data that is actually necessary. What data is necessary can be determined dynamically during evaluation. Many lazy-functions can be composed in a graph to form a new lazy-function, which can again be used in a graph etc. * Each geometry node group is converted into a lazy-function graph prior to evaluation. To evaluate geometry nodes, one then just has to evaluate that graph. Node groups are no longer inlined into their parents. Next steps for the evaluation system is to reduce the use of threads in some situations to avoid overhead. Many small node groups don't benefit from multi-threading at all. This is much easier to do now because not everything has to be inlined in one huge node tree anymore. Differential Revision: https://developer.blender.org/D15914
2022-09-13 08:44:26 +02:00
};
class InputSocket : public Socket {
private:
/**
* An input can have at most one link connected to it. The linked socket is the "origin" because
* it's where the data is coming from. The type of the origin must be the same as the type of
* this socket.
*/
OutputSocket *origin_;
/**
* Can be null or a non-owning pointer to a value of the type of the socket. This value will be
* used when the input is used but not linked.
*
* This is technically not needed, because one could just create a separate node that just
* outputs the value, but that would have more overhead. Especially because it's commonly the
* case that most inputs are unlinked.
*/
const void *default_value_ = nullptr;
friend Graph;
public:
OutputSocket *origin();
const OutputSocket *origin() const;
const void *default_value() const;
void set_default_value(const void *value);
};
class OutputSocket : public Socket {
private:
/**
* An output can be linked to an arbitrary number of inputs of the same type.
*/
Vector<InputSocket *> targets_;
friend Graph;
public:
Span<InputSocket *> targets();
Span<const InputSocket *> targets() const;
};
/**
Functions: refactor lazy-function graph interface Goals of the refactor: * Simplify adding (named) graph inputs and outputs. * Add ability to refer to a graph input or output with an index. * Get rid of the "dummy" terminology which doesn't really help. Previously, one would add "dummy nodes" which can then serve as input and output nodes of the graph. Now one directly adds input and outputs using `Graph.add_input` and `Graph.add_output`. There is one interface node that contains all inputs and another one that contains all outputs. Being able to refer to a graph input or output with an index makes it more efficient to implement some algorithms. E.g. one could have a bit span for a socket that contains all the information what graph inputs this socket depends on. Pull Request: https://projects.blender.org/blender/blender/pulls/112474
2023-09-17 13:54:09 +02:00
* A #Node has input and output sockets. Every node is either a #FunctionNode or an #InterfaceNode.
Geometry Nodes: new evaluation system This refactors the geometry nodes evaluation system. No changes for the user are expected. At a high level the goals are: * Support using geometry nodes outside of the geometry nodes modifier. * Support using the evaluator infrastructure for other purposes like field evaluation. * Support more nodes, especially when many of them are disabled behind switch nodes. * Support doing preprocessing on node groups. For more details see T98492. There are fairly detailed comments in the code, but here is a high level overview for how it works now: * There is a new "lazy-function" system. It is similar in spirit to the multi-function system but with different goals. Instead of optimizing throughput for highly parallelizable work, this system is designed to compute only the data that is actually necessary. What data is necessary can be determined dynamically during evaluation. Many lazy-functions can be composed in a graph to form a new lazy-function, which can again be used in a graph etc. * Each geometry node group is converted into a lazy-function graph prior to evaluation. To evaluate geometry nodes, one then just has to evaluate that graph. Node groups are no longer inlined into their parents. Next steps for the evaluation system is to reduce the use of threads in some situations to avoid overhead. Many small node groups don't benefit from multi-threading at all. This is much easier to do now because not everything has to be inlined in one huge node tree anymore. Differential Revision: https://developer.blender.org/D15914
2022-09-13 08:44:26 +02:00
*/
class Node : NonCopyable, NonMovable {
protected:
/**
Functions: refactor lazy-function graph interface Goals of the refactor: * Simplify adding (named) graph inputs and outputs. * Add ability to refer to a graph input or output with an index. * Get rid of the "dummy" terminology which doesn't really help. Previously, one would add "dummy nodes" which can then serve as input and output nodes of the graph. Now one directly adds input and outputs using `Graph.add_input` and `Graph.add_output`. There is one interface node that contains all inputs and another one that contains all outputs. Being able to refer to a graph input or output with an index makes it more efficient to implement some algorithms. E.g. one could have a bit span for a socket that contains all the information what graph inputs this socket depends on. Pull Request: https://projects.blender.org/blender/blender/pulls/112474
2023-09-17 13:54:09 +02:00
* The function this node corresponds to. If this is null, the node is an #InterfaceNode.
Geometry Nodes: new evaluation system This refactors the geometry nodes evaluation system. No changes for the user are expected. At a high level the goals are: * Support using geometry nodes outside of the geometry nodes modifier. * Support using the evaluator infrastructure for other purposes like field evaluation. * Support more nodes, especially when many of them are disabled behind switch nodes. * Support doing preprocessing on node groups. For more details see T98492. There are fairly detailed comments in the code, but here is a high level overview for how it works now: * There is a new "lazy-function" system. It is similar in spirit to the multi-function system but with different goals. Instead of optimizing throughput for highly parallelizable work, this system is designed to compute only the data that is actually necessary. What data is necessary can be determined dynamically during evaluation. Many lazy-functions can be composed in a graph to form a new lazy-function, which can again be used in a graph etc. * Each geometry node group is converted into a lazy-function graph prior to evaluation. To evaluate geometry nodes, one then just has to evaluate that graph. Node groups are no longer inlined into their parents. Next steps for the evaluation system is to reduce the use of threads in some situations to avoid overhead. Many small node groups don't benefit from multi-threading at all. This is much easier to do now because not everything has to be inlined in one huge node tree anymore. Differential Revision: https://developer.blender.org/D15914
2022-09-13 08:44:26 +02:00
* The function is not owned by this #Node nor by the #Graph.
*/
const LazyFunction *fn_ = nullptr;
/**
* Input sockets of the node.
*/
Span<InputSocket *> inputs_;
/**
* Output sockets of the node.
*/
Span<OutputSocket *> outputs_;
/**
* An index that is set when calling #Graph::update_node_indices. This can be used to create
* efficient mappings from nodes to other data using just an array instead of a hash map.
*
* This is technically not necessary but has better performance than always using hash maps.
*/
int index_in_graph_ = -1;
friend Graph;
public:
Functions: refactor lazy-function graph interface Goals of the refactor: * Simplify adding (named) graph inputs and outputs. * Add ability to refer to a graph input or output with an index. * Get rid of the "dummy" terminology which doesn't really help. Previously, one would add "dummy nodes" which can then serve as input and output nodes of the graph. Now one directly adds input and outputs using `Graph.add_input` and `Graph.add_output`. There is one interface node that contains all inputs and another one that contains all outputs. Being able to refer to a graph input or output with an index makes it more efficient to implement some algorithms. E.g. one could have a bit span for a socket that contains all the information what graph inputs this socket depends on. Pull Request: https://projects.blender.org/blender/blender/pulls/112474
2023-09-17 13:54:09 +02:00
bool is_interface() const;
Geometry Nodes: new evaluation system This refactors the geometry nodes evaluation system. No changes for the user are expected. At a high level the goals are: * Support using geometry nodes outside of the geometry nodes modifier. * Support using the evaluator infrastructure for other purposes like field evaluation. * Support more nodes, especially when many of them are disabled behind switch nodes. * Support doing preprocessing on node groups. For more details see T98492. There are fairly detailed comments in the code, but here is a high level overview for how it works now: * There is a new "lazy-function" system. It is similar in spirit to the multi-function system but with different goals. Instead of optimizing throughput for highly parallelizable work, this system is designed to compute only the data that is actually necessary. What data is necessary can be determined dynamically during evaluation. Many lazy-functions can be composed in a graph to form a new lazy-function, which can again be used in a graph etc. * Each geometry node group is converted into a lazy-function graph prior to evaluation. To evaluate geometry nodes, one then just has to evaluate that graph. Node groups are no longer inlined into their parents. Next steps for the evaluation system is to reduce the use of threads in some situations to avoid overhead. Many small node groups don't benefit from multi-threading at all. This is much easier to do now because not everything has to be inlined in one huge node tree anymore. Differential Revision: https://developer.blender.org/D15914
2022-09-13 08:44:26 +02:00
bool is_function() const;
int index_in_graph() const;
Span<const InputSocket *> inputs() const;
Span<const OutputSocket *> outputs() const;
Span<InputSocket *> inputs();
Span<OutputSocket *> outputs();
const InputSocket &input(int index) const;
const OutputSocket &output(int index) const;
InputSocket &input(int index);
OutputSocket &output(int index);
std::string name() const;
};
/**
* A #Node that corresponds to a specific #LazyFunction.
*/
Functions: refactor lazy-function graph interface Goals of the refactor: * Simplify adding (named) graph inputs and outputs. * Add ability to refer to a graph input or output with an index. * Get rid of the "dummy" terminology which doesn't really help. Previously, one would add "dummy nodes" which can then serve as input and output nodes of the graph. Now one directly adds input and outputs using `Graph.add_input` and `Graph.add_output`. There is one interface node that contains all inputs and another one that contains all outputs. Being able to refer to a graph input or output with an index makes it more efficient to implement some algorithms. E.g. one could have a bit span for a socket that contains all the information what graph inputs this socket depends on. Pull Request: https://projects.blender.org/blender/blender/pulls/112474
2023-09-17 13:54:09 +02:00
class FunctionNode final : public Node {
Geometry Nodes: new evaluation system This refactors the geometry nodes evaluation system. No changes for the user are expected. At a high level the goals are: * Support using geometry nodes outside of the geometry nodes modifier. * Support using the evaluator infrastructure for other purposes like field evaluation. * Support more nodes, especially when many of them are disabled behind switch nodes. * Support doing preprocessing on node groups. For more details see T98492. There are fairly detailed comments in the code, but here is a high level overview for how it works now: * There is a new "lazy-function" system. It is similar in spirit to the multi-function system but with different goals. Instead of optimizing throughput for highly parallelizable work, this system is designed to compute only the data that is actually necessary. What data is necessary can be determined dynamically during evaluation. Many lazy-functions can be composed in a graph to form a new lazy-function, which can again be used in a graph etc. * Each geometry node group is converted into a lazy-function graph prior to evaluation. To evaluate geometry nodes, one then just has to evaluate that graph. Node groups are no longer inlined into their parents. Next steps for the evaluation system is to reduce the use of threads in some situations to avoid overhead. Many small node groups don't benefit from multi-threading at all. This is much easier to do now because not everything has to be inlined in one huge node tree anymore. Differential Revision: https://developer.blender.org/D15914
2022-09-13 08:44:26 +02:00
public:
const LazyFunction &function() const;
};
/**
* A #Node that does *not* correspond to a #LazyFunction. Instead it can be used to indicate inputs
* and outputs of the entire graph. It can have an arbitrary number of inputs and outputs.
*/
Functions: refactor lazy-function graph interface Goals of the refactor: * Simplify adding (named) graph inputs and outputs. * Add ability to refer to a graph input or output with an index. * Get rid of the "dummy" terminology which doesn't really help. Previously, one would add "dummy nodes" which can then serve as input and output nodes of the graph. Now one directly adds input and outputs using `Graph.add_input` and `Graph.add_output`. There is one interface node that contains all inputs and another one that contains all outputs. Being able to refer to a graph input or output with an index makes it more efficient to implement some algorithms. E.g. one could have a bit span for a socket that contains all the information what graph inputs this socket depends on. Pull Request: https://projects.blender.org/blender/blender/pulls/112474
2023-09-17 13:54:09 +02:00
class InterfaceNode final : public Node {
Geometry Nodes: new evaluation system This refactors the geometry nodes evaluation system. No changes for the user are expected. At a high level the goals are: * Support using geometry nodes outside of the geometry nodes modifier. * Support using the evaluator infrastructure for other purposes like field evaluation. * Support more nodes, especially when many of them are disabled behind switch nodes. * Support doing preprocessing on node groups. For more details see T98492. There are fairly detailed comments in the code, but here is a high level overview for how it works now: * There is a new "lazy-function" system. It is similar in spirit to the multi-function system but with different goals. Instead of optimizing throughput for highly parallelizable work, this system is designed to compute only the data that is actually necessary. What data is necessary can be determined dynamically during evaluation. Many lazy-functions can be composed in a graph to form a new lazy-function, which can again be used in a graph etc. * Each geometry node group is converted into a lazy-function graph prior to evaluation. To evaluate geometry nodes, one then just has to evaluate that graph. Node groups are no longer inlined into their parents. Next steps for the evaluation system is to reduce the use of threads in some situations to avoid overhead. Many small node groups don't benefit from multi-threading at all. This is much easier to do now because not everything has to be inlined in one huge node tree anymore. Differential Revision: https://developer.blender.org/D15914
2022-09-13 08:44:26 +02:00
private:
friend Node;
Geometry Nodes: improve dot graph export of lazy function graph * Dim default input values. * Print default input values instead of type name. * Add node/socket names to group input/output nodes.
2022-12-16 12:18:49 +01:00
friend Socket;
friend Graph;
Functions: refactor lazy-function graph interface Goals of the refactor: * Simplify adding (named) graph inputs and outputs. * Add ability to refer to a graph input or output with an index. * Get rid of the "dummy" terminology which doesn't really help. Previously, one would add "dummy nodes" which can then serve as input and output nodes of the graph. Now one directly adds input and outputs using `Graph.add_input` and `Graph.add_output`. There is one interface node that contains all inputs and another one that contains all outputs. Being able to refer to a graph input or output with an index makes it more efficient to implement some algorithms. E.g. one could have a bit span for a socket that contains all the information what graph inputs this socket depends on. Pull Request: https://projects.blender.org/blender/blender/pulls/112474
2023-09-17 13:54:09 +02:00
Vector<std::string> socket_names_;
Geometry Nodes: new evaluation system This refactors the geometry nodes evaluation system. No changes for the user are expected. At a high level the goals are: * Support using geometry nodes outside of the geometry nodes modifier. * Support using the evaluator infrastructure for other purposes like field evaluation. * Support more nodes, especially when many of them are disabled behind switch nodes. * Support doing preprocessing on node groups. For more details see T98492. There are fairly detailed comments in the code, but here is a high level overview for how it works now: * There is a new "lazy-function" system. It is similar in spirit to the multi-function system but with different goals. Instead of optimizing throughput for highly parallelizable work, this system is designed to compute only the data that is actually necessary. What data is necessary can be determined dynamically during evaluation. Many lazy-functions can be composed in a graph to form a new lazy-function, which can again be used in a graph etc. * Each geometry node group is converted into a lazy-function graph prior to evaluation. To evaluate geometry nodes, one then just has to evaluate that graph. Node groups are no longer inlined into their parents. Next steps for the evaluation system is to reduce the use of threads in some situations to avoid overhead. Many small node groups don't benefit from multi-threading at all. This is much easier to do now because not everything has to be inlined in one huge node tree anymore. Differential Revision: https://developer.blender.org/D15914
2022-09-13 08:44:26 +02:00
};
Functions: refactor lazy-function graph interface Goals of the refactor: * Simplify adding (named) graph inputs and outputs. * Add ability to refer to a graph input or output with an index. * Get rid of the "dummy" terminology which doesn't really help. Previously, one would add "dummy nodes" which can then serve as input and output nodes of the graph. Now one directly adds input and outputs using `Graph.add_input` and `Graph.add_output`. There is one interface node that contains all inputs and another one that contains all outputs. Being able to refer to a graph input or output with an index makes it more efficient to implement some algorithms. E.g. one could have a bit span for a socket that contains all the information what graph inputs this socket depends on. Pull Request: https://projects.blender.org/blender/blender/pulls/112474
2023-09-17 13:54:09 +02:00
/**
* Interface input sockets are actually output sockets on the input node. This renaming makes the
* code less confusing.
*/
using GraphInputSocket = OutputSocket;
using GraphOutputSocket = InputSocket;
Geometry Nodes: new evaluation system This refactors the geometry nodes evaluation system. No changes for the user are expected. At a high level the goals are: * Support using geometry nodes outside of the geometry nodes modifier. * Support using the evaluator infrastructure for other purposes like field evaluation. * Support more nodes, especially when many of them are disabled behind switch nodes. * Support doing preprocessing on node groups. For more details see T98492. There are fairly detailed comments in the code, but here is a high level overview for how it works now: * There is a new "lazy-function" system. It is similar in spirit to the multi-function system but with different goals. Instead of optimizing throughput for highly parallelizable work, this system is designed to compute only the data that is actually necessary. What data is necessary can be determined dynamically during evaluation. Many lazy-functions can be composed in a graph to form a new lazy-function, which can again be used in a graph etc. * Each geometry node group is converted into a lazy-function graph prior to evaluation. To evaluate geometry nodes, one then just has to evaluate that graph. Node groups are no longer inlined into their parents. Next steps for the evaluation system is to reduce the use of threads in some situations to avoid overhead. Many small node groups don't benefit from multi-threading at all. This is much easier to do now because not everything has to be inlined in one huge node tree anymore. Differential Revision: https://developer.blender.org/D15914
2022-09-13 08:44:26 +02:00
/**
* A container for an arbitrary number of nodes and links between their sockets.
*/
class Graph : NonCopyable, NonMovable {
private:
/**
* Used to allocate nodes and sockets in the graph.
*/
LinearAllocator<> allocator_;
/**
* Contains all nodes in the graph so that it is efficient to iterate over them.
Functions: refactor lazy-function graph interface Goals of the refactor: * Simplify adding (named) graph inputs and outputs. * Add ability to refer to a graph input or output with an index. * Get rid of the "dummy" terminology which doesn't really help. Previously, one would add "dummy nodes" which can then serve as input and output nodes of the graph. Now one directly adds input and outputs using `Graph.add_input` and `Graph.add_output`. There is one interface node that contains all inputs and another one that contains all outputs. Being able to refer to a graph input or output with an index makes it more efficient to implement some algorithms. E.g. one could have a bit span for a socket that contains all the information what graph inputs this socket depends on. Pull Request: https://projects.blender.org/blender/blender/pulls/112474
2023-09-17 13:54:09 +02:00
* The first two nodes are the interface input and output nodes.
Geometry Nodes: new evaluation system This refactors the geometry nodes evaluation system. No changes for the user are expected. At a high level the goals are: * Support using geometry nodes outside of the geometry nodes modifier. * Support using the evaluator infrastructure for other purposes like field evaluation. * Support more nodes, especially when many of them are disabled behind switch nodes. * Support doing preprocessing on node groups. For more details see T98492. There are fairly detailed comments in the code, but here is a high level overview for how it works now: * There is a new "lazy-function" system. It is similar in spirit to the multi-function system but with different goals. Instead of optimizing throughput for highly parallelizable work, this system is designed to compute only the data that is actually necessary. What data is necessary can be determined dynamically during evaluation. Many lazy-functions can be composed in a graph to form a new lazy-function, which can again be used in a graph etc. * Each geometry node group is converted into a lazy-function graph prior to evaluation. To evaluate geometry nodes, one then just has to evaluate that graph. Node groups are no longer inlined into their parents. Next steps for the evaluation system is to reduce the use of threads in some situations to avoid overhead. Many small node groups don't benefit from multi-threading at all. This is much easier to do now because not everything has to be inlined in one huge node tree anymore. Differential Revision: https://developer.blender.org/D15914
2022-09-13 08:44:26 +02:00
*/
Vector<Node *> nodes_;
Functions: refactor lazy-function graph interface Goals of the refactor: * Simplify adding (named) graph inputs and outputs. * Add ability to refer to a graph input or output with an index. * Get rid of the "dummy" terminology which doesn't really help. Previously, one would add "dummy nodes" which can then serve as input and output nodes of the graph. Now one directly adds input and outputs using `Graph.add_input` and `Graph.add_output`. There is one interface node that contains all inputs and another one that contains all outputs. Being able to refer to a graph input or output with an index makes it more efficient to implement some algorithms. E.g. one could have a bit span for a socket that contains all the information what graph inputs this socket depends on. Pull Request: https://projects.blender.org/blender/blender/pulls/112474
2023-09-17 13:54:09 +02:00
InterfaceNode *graph_input_node_ = nullptr;
InterfaceNode *graph_output_node_ = nullptr;
Vector<GraphInputSocket *> graph_inputs_;
Vector<GraphOutputSocket *> graph_outputs_;
Geometry Nodes: deterministic anonymous attribute lifetimes Previously, the lifetimes of anonymous attributes were determined by reference counts which were non-deterministic when multiple threads are used. Now the lifetimes of anonymous attributes are handled more explicitly and deterministically. This is a prerequisite for any kind of caching, because caching the output of nodes that do things non-deterministically and have "invisible inputs" (reference counts) doesn't really work. For more details for how deterministic lifetimes are achieved, see D16858. No functional changes are expected. Small performance changes are expected as well (within few percent, anything larger regressions should be reported as bugs). Differential Revision: https://developer.blender.org/D16858
2023-01-05 14:05:30 +01:00
/**
* Number of sockets in the graph. Can be used as array size when indexing using
* `Socket::index_in_graph`.
*/
int socket_num_ = 0;
Geometry Nodes: new evaluation system This refactors the geometry nodes evaluation system. No changes for the user are expected. At a high level the goals are: * Support using geometry nodes outside of the geometry nodes modifier. * Support using the evaluator infrastructure for other purposes like field evaluation. * Support more nodes, especially when many of them are disabled behind switch nodes. * Support doing preprocessing on node groups. For more details see T98492. There are fairly detailed comments in the code, but here is a high level overview for how it works now: * There is a new "lazy-function" system. It is similar in spirit to the multi-function system but with different goals. Instead of optimizing throughput for highly parallelizable work, this system is designed to compute only the data that is actually necessary. What data is necessary can be determined dynamically during evaluation. Many lazy-functions can be composed in a graph to form a new lazy-function, which can again be used in a graph etc. * Each geometry node group is converted into a lazy-function graph prior to evaluation. To evaluate geometry nodes, one then just has to evaluate that graph. Node groups are no longer inlined into their parents. Next steps for the evaluation system is to reduce the use of threads in some situations to avoid overhead. Many small node groups don't benefit from multi-threading at all. This is much easier to do now because not everything has to be inlined in one huge node tree anymore. Differential Revision: https://developer.blender.org/D15914
2022-09-13 08:44:26 +02:00
public:
Functions: refactor lazy-function graph interface Goals of the refactor: * Simplify adding (named) graph inputs and outputs. * Add ability to refer to a graph input or output with an index. * Get rid of the "dummy" terminology which doesn't really help. Previously, one would add "dummy nodes" which can then serve as input and output nodes of the graph. Now one directly adds input and outputs using `Graph.add_input` and `Graph.add_output`. There is one interface node that contains all inputs and another one that contains all outputs. Being able to refer to a graph input or output with an index makes it more efficient to implement some algorithms. E.g. one could have a bit span for a socket that contains all the information what graph inputs this socket depends on. Pull Request: https://projects.blender.org/blender/blender/pulls/112474
2023-09-17 13:54:09 +02:00
Graph();
Geometry Nodes: new evaluation system This refactors the geometry nodes evaluation system. No changes for the user are expected. At a high level the goals are: * Support using geometry nodes outside of the geometry nodes modifier. * Support using the evaluator infrastructure for other purposes like field evaluation. * Support more nodes, especially when many of them are disabled behind switch nodes. * Support doing preprocessing on node groups. For more details see T98492. There are fairly detailed comments in the code, but here is a high level overview for how it works now: * There is a new "lazy-function" system. It is similar in spirit to the multi-function system but with different goals. Instead of optimizing throughput for highly parallelizable work, this system is designed to compute only the data that is actually necessary. What data is necessary can be determined dynamically during evaluation. Many lazy-functions can be composed in a graph to form a new lazy-function, which can again be used in a graph etc. * Each geometry node group is converted into a lazy-function graph prior to evaluation. To evaluate geometry nodes, one then just has to evaluate that graph. Node groups are no longer inlined into their parents. Next steps for the evaluation system is to reduce the use of threads in some situations to avoid overhead. Many small node groups don't benefit from multi-threading at all. This is much easier to do now because not everything has to be inlined in one huge node tree anymore. Differential Revision: https://developer.blender.org/D15914
2022-09-13 08:44:26 +02:00
~Graph();
/**
* Get all nodes in the graph. The index in the span corresponds to #Node::index_in_graph.
*/
Span<const Node *> nodes() const;
Geometry Nodes: deterministic anonymous attribute lifetimes Previously, the lifetimes of anonymous attributes were determined by reference counts which were non-deterministic when multiple threads are used. Now the lifetimes of anonymous attributes are handled more explicitly and deterministically. This is a prerequisite for any kind of caching, because caching the output of nodes that do things non-deterministically and have "invisible inputs" (reference counts) doesn't really work. For more details for how deterministic lifetimes are achieved, see D16858. No functional changes are expected. Small performance changes are expected as well (within few percent, anything larger regressions should be reported as bugs). Differential Revision: https://developer.blender.org/D16858
2023-01-05 14:05:30 +01:00
Span<Node *> nodes();
Geometry Nodes: new evaluation system This refactors the geometry nodes evaluation system. No changes for the user are expected. At a high level the goals are: * Support using geometry nodes outside of the geometry nodes modifier. * Support using the evaluator infrastructure for other purposes like field evaluation. * Support more nodes, especially when many of them are disabled behind switch nodes. * Support doing preprocessing on node groups. For more details see T98492. There are fairly detailed comments in the code, but here is a high level overview for how it works now: * There is a new "lazy-function" system. It is similar in spirit to the multi-function system but with different goals. Instead of optimizing throughput for highly parallelizable work, this system is designed to compute only the data that is actually necessary. What data is necessary can be determined dynamically during evaluation. Many lazy-functions can be composed in a graph to form a new lazy-function, which can again be used in a graph etc. * Each geometry node group is converted into a lazy-function graph prior to evaluation. To evaluate geometry nodes, one then just has to evaluate that graph. Node groups are no longer inlined into their parents. Next steps for the evaluation system is to reduce the use of threads in some situations to avoid overhead. Many small node groups don't benefit from multi-threading at all. This is much easier to do now because not everything has to be inlined in one huge node tree anymore. Differential Revision: https://developer.blender.org/D15914
2022-09-13 08:44:26 +02:00
Functions: refactor lazy-function graph interface Goals of the refactor: * Simplify adding (named) graph inputs and outputs. * Add ability to refer to a graph input or output with an index. * Get rid of the "dummy" terminology which doesn't really help. Previously, one would add "dummy nodes" which can then serve as input and output nodes of the graph. Now one directly adds input and outputs using `Graph.add_input` and `Graph.add_output`. There is one interface node that contains all inputs and another one that contains all outputs. Being able to refer to a graph input or output with an index makes it more efficient to implement some algorithms. E.g. one could have a bit span for a socket that contains all the information what graph inputs this socket depends on. Pull Request: https://projects.blender.org/blender/blender/pulls/112474
2023-09-17 13:54:09 +02:00
Span<const FunctionNode *> function_nodes() const;
Span<FunctionNode *> function_nodes();
Functions: add lazy-function graph input/output getter methods
2023-10-08 16:01:56 +02:00
Span<GraphInputSocket *> graph_inputs();
Span<GraphOutputSocket *> graph_outputs();
Functions: use array indexing instead of VectorSet in graph executor This avoids the need to build the VectorSet and array indexing is generally faster than a hash table lookup.
2023-09-17 14:27:01 +02:00
Span<const GraphInputSocket *> graph_inputs() const;
Span<const GraphOutputSocket *> graph_outputs() const;
Geometry Nodes: new evaluation system This refactors the geometry nodes evaluation system. No changes for the user are expected. At a high level the goals are: * Support using geometry nodes outside of the geometry nodes modifier. * Support using the evaluator infrastructure for other purposes like field evaluation. * Support more nodes, especially when many of them are disabled behind switch nodes. * Support doing preprocessing on node groups. For more details see T98492. There are fairly detailed comments in the code, but here is a high level overview for how it works now: * There is a new "lazy-function" system. It is similar in spirit to the multi-function system but with different goals. Instead of optimizing throughput for highly parallelizable work, this system is designed to compute only the data that is actually necessary. What data is necessary can be determined dynamically during evaluation. Many lazy-functions can be composed in a graph to form a new lazy-function, which can again be used in a graph etc. * Each geometry node group is converted into a lazy-function graph prior to evaluation. To evaluate geometry nodes, one then just has to evaluate that graph. Node groups are no longer inlined into their parents. Next steps for the evaluation system is to reduce the use of threads in some situations to avoid overhead. Many small node groups don't benefit from multi-threading at all. This is much easier to do now because not everything has to be inlined in one huge node tree anymore. Differential Revision: https://developer.blender.org/D15914
2022-09-13 08:44:26 +02:00
/**
* Add a new function node with sockets that match the passed in #LazyFunction.
*/
FunctionNode &add_function(const LazyFunction &fn);
/**
Functions: refactor lazy-function graph interface Goals of the refactor: * Simplify adding (named) graph inputs and outputs. * Add ability to refer to a graph input or output with an index. * Get rid of the "dummy" terminology which doesn't really help. Previously, one would add "dummy nodes" which can then serve as input and output nodes of the graph. Now one directly adds input and outputs using `Graph.add_input` and `Graph.add_output`. There is one interface node that contains all inputs and another one that contains all outputs. Being able to refer to a graph input or output with an index makes it more efficient to implement some algorithms. E.g. one could have a bit span for a socket that contains all the information what graph inputs this socket depends on. Pull Request: https://projects.blender.org/blender/blender/pulls/112474
2023-09-17 13:54:09 +02:00
* Add inputs and outputs to the graph.
Geometry Nodes: new evaluation system This refactors the geometry nodes evaluation system. No changes for the user are expected. At a high level the goals are: * Support using geometry nodes outside of the geometry nodes modifier. * Support using the evaluator infrastructure for other purposes like field evaluation. * Support more nodes, especially when many of them are disabled behind switch nodes. * Support doing preprocessing on node groups. For more details see T98492. There are fairly detailed comments in the code, but here is a high level overview for how it works now: * There is a new "lazy-function" system. It is similar in spirit to the multi-function system but with different goals. Instead of optimizing throughput for highly parallelizable work, this system is designed to compute only the data that is actually necessary. What data is necessary can be determined dynamically during evaluation. Many lazy-functions can be composed in a graph to form a new lazy-function, which can again be used in a graph etc. * Each geometry node group is converted into a lazy-function graph prior to evaluation. To evaluate geometry nodes, one then just has to evaluate that graph. Node groups are no longer inlined into their parents. Next steps for the evaluation system is to reduce the use of threads in some situations to avoid overhead. Many small node groups don't benefit from multi-threading at all. This is much easier to do now because not everything has to be inlined in one huge node tree anymore. Differential Revision: https://developer.blender.org/D15914
2022-09-13 08:44:26 +02:00
*/
Functions: refactor lazy-function graph interface Goals of the refactor: * Simplify adding (named) graph inputs and outputs. * Add ability to refer to a graph input or output with an index. * Get rid of the "dummy" terminology which doesn't really help. Previously, one would add "dummy nodes" which can then serve as input and output nodes of the graph. Now one directly adds input and outputs using `Graph.add_input` and `Graph.add_output`. There is one interface node that contains all inputs and another one that contains all outputs. Being able to refer to a graph input or output with an index makes it more efficient to implement some algorithms. E.g. one could have a bit span for a socket that contains all the information what graph inputs this socket depends on. Pull Request: https://projects.blender.org/blender/blender/pulls/112474
2023-09-17 13:54:09 +02:00
GraphInputSocket &add_input(const CPPType &type, std::string name = "");
GraphOutputSocket &add_output(const CPPType &type, std::string name = "");
Geometry Nodes: new evaluation system This refactors the geometry nodes evaluation system. No changes for the user are expected. At a high level the goals are: * Support using geometry nodes outside of the geometry nodes modifier. * Support using the evaluator infrastructure for other purposes like field evaluation. * Support more nodes, especially when many of them are disabled behind switch nodes. * Support doing preprocessing on node groups. For more details see T98492. There are fairly detailed comments in the code, but here is a high level overview for how it works now: * There is a new "lazy-function" system. It is similar in spirit to the multi-function system but with different goals. Instead of optimizing throughput for highly parallelizable work, this system is designed to compute only the data that is actually necessary. What data is necessary can be determined dynamically during evaluation. Many lazy-functions can be composed in a graph to form a new lazy-function, which can again be used in a graph etc. * Each geometry node group is converted into a lazy-function graph prior to evaluation. To evaluate geometry nodes, one then just has to evaluate that graph. Node groups are no longer inlined into their parents. Next steps for the evaluation system is to reduce the use of threads in some situations to avoid overhead. Many small node groups don't benefit from multi-threading at all. This is much easier to do now because not everything has to be inlined in one huge node tree anymore. Differential Revision: https://developer.blender.org/D15914
2022-09-13 08:44:26 +02:00
/**
* Add a link between the two given sockets.
* This has undefined behavior when the input is linked to something else already.
*/
void add_link(OutputSocket &from, InputSocket &to);
Geometry Nodes: deterministic anonymous attribute lifetimes Previously, the lifetimes of anonymous attributes were determined by reference counts which were non-deterministic when multiple threads are used. Now the lifetimes of anonymous attributes are handled more explicitly and deterministically. This is a prerequisite for any kind of caching, because caching the output of nodes that do things non-deterministically and have "invisible inputs" (reference counts) doesn't really work. For more details for how deterministic lifetimes are achieved, see D16858. No functional changes are expected. Small performance changes are expected as well (within few percent, anything larger regressions should be reported as bugs). Differential Revision: https://developer.blender.org/D16858
2023-01-05 14:05:30 +01:00
/**
* If the socket is linked, remove the link.
*/
void clear_origin(InputSocket &socket);
Geometry Nodes: new evaluation system This refactors the geometry nodes evaluation system. No changes for the user are expected. At a high level the goals are: * Support using geometry nodes outside of the geometry nodes modifier. * Support using the evaluator infrastructure for other purposes like field evaluation. * Support more nodes, especially when many of them are disabled behind switch nodes. * Support doing preprocessing on node groups. For more details see T98492. There are fairly detailed comments in the code, but here is a high level overview for how it works now: * There is a new "lazy-function" system. It is similar in spirit to the multi-function system but with different goals. Instead of optimizing throughput for highly parallelizable work, this system is designed to compute only the data that is actually necessary. What data is necessary can be determined dynamically during evaluation. Many lazy-functions can be composed in a graph to form a new lazy-function, which can again be used in a graph etc. * Each geometry node group is converted into a lazy-function graph prior to evaluation. To evaluate geometry nodes, one then just has to evaluate that graph. Node groups are no longer inlined into their parents. Next steps for the evaluation system is to reduce the use of threads in some situations to avoid overhead. Many small node groups don't benefit from multi-threading at all. This is much easier to do now because not everything has to be inlined in one huge node tree anymore. Differential Revision: https://developer.blender.org/D15914
2022-09-13 08:44:26 +02:00
/**
* Make sure that #Node::index_in_graph is up to date.
*/
void update_node_indices();
Geometry Nodes: deterministic anonymous attribute lifetimes Previously, the lifetimes of anonymous attributes were determined by reference counts which were non-deterministic when multiple threads are used. Now the lifetimes of anonymous attributes are handled more explicitly and deterministically. This is a prerequisite for any kind of caching, because caching the output of nodes that do things non-deterministically and have "invisible inputs" (reference counts) doesn't really work. For more details for how deterministic lifetimes are achieved, see D16858. No functional changes are expected. Small performance changes are expected as well (within few percent, anything larger regressions should be reported as bugs). Differential Revision: https://developer.blender.org/D16858
2023-01-05 14:05:30 +01:00
/**
* Make sure that #Socket::index_in_graph is up to date.
*/
void update_socket_indices();
/**
* Number of sockets in the graph.
*/
int socket_num() const;
Geometry Nodes: new evaluation system This refactors the geometry nodes evaluation system. No changes for the user are expected. At a high level the goals are: * Support using geometry nodes outside of the geometry nodes modifier. * Support using the evaluator infrastructure for other purposes like field evaluation. * Support more nodes, especially when many of them are disabled behind switch nodes. * Support doing preprocessing on node groups. For more details see T98492. There are fairly detailed comments in the code, but here is a high level overview for how it works now: * There is a new "lazy-function" system. It is similar in spirit to the multi-function system but with different goals. Instead of optimizing throughput for highly parallelizable work, this system is designed to compute only the data that is actually necessary. What data is necessary can be determined dynamically during evaluation. Many lazy-functions can be composed in a graph to form a new lazy-function, which can again be used in a graph etc. * Each geometry node group is converted into a lazy-function graph prior to evaluation. To evaluate geometry nodes, one then just has to evaluate that graph. Node groups are no longer inlined into their parents. Next steps for the evaluation system is to reduce the use of threads in some situations to avoid overhead. Many small node groups don't benefit from multi-threading at all. This is much easier to do now because not everything has to be inlined in one huge node tree anymore. Differential Revision: https://developer.blender.org/D15914
2022-09-13 08:44:26 +02:00
/**
* Can be used to assert that #update_node_indices has been called.
*/
bool node_indices_are_valid() const;
BLI: improve node graph export in dot format This makes it bit easier to export node graphs and also allows for more customization of links and sockets.
2022-12-29 15:09:52 +01:00
/**
* Optional configuration options for the dot graph generation. This allows creating
* visualizations for specific purposes.
*/
class ToDotOptions {
public:
virtual std::string socket_name(const Socket &socket) const;
virtual std::optional<std::string> socket_font_color(const Socket &socket) const;
virtual void add_edge_attributes(const OutputSocket &from,
const InputSocket &to,
dot::DirectedEdge &dot_edge) const;
};
Geometry Nodes: new evaluation system This refactors the geometry nodes evaluation system. No changes for the user are expected. At a high level the goals are: * Support using geometry nodes outside of the geometry nodes modifier. * Support using the evaluator infrastructure for other purposes like field evaluation. * Support more nodes, especially when many of them are disabled behind switch nodes. * Support doing preprocessing on node groups. For more details see T98492. There are fairly detailed comments in the code, but here is a high level overview for how it works now: * There is a new "lazy-function" system. It is similar in spirit to the multi-function system but with different goals. Instead of optimizing throughput for highly parallelizable work, this system is designed to compute only the data that is actually necessary. What data is necessary can be determined dynamically during evaluation. Many lazy-functions can be composed in a graph to form a new lazy-function, which can again be used in a graph etc. * Each geometry node group is converted into a lazy-function graph prior to evaluation. To evaluate geometry nodes, one then just has to evaluate that graph. Node groups are no longer inlined into their parents. Next steps for the evaluation system is to reduce the use of threads in some situations to avoid overhead. Many small node groups don't benefit from multi-threading at all. This is much easier to do now because not everything has to be inlined in one huge node tree anymore. Differential Revision: https://developer.blender.org/D15914
2022-09-13 08:44:26 +02:00
/**
* Utility to generate a dot graph string for the graph. This can be used for debugging.
*/
BLI: improve node graph export in dot format This makes it bit easier to export node graphs and also allows for more customization of links and sockets.
2022-12-29 15:09:52 +01:00
std::string to_dot(const ToDotOptions &options = {}) const;
Geometry Nodes: new evaluation system This refactors the geometry nodes evaluation system. No changes for the user are expected. At a high level the goals are: * Support using geometry nodes outside of the geometry nodes modifier. * Support using the evaluator infrastructure for other purposes like field evaluation. * Support more nodes, especially when many of them are disabled behind switch nodes. * Support doing preprocessing on node groups. For more details see T98492. There are fairly detailed comments in the code, but here is a high level overview for how it works now: * There is a new "lazy-function" system. It is similar in spirit to the multi-function system but with different goals. Instead of optimizing throughput for highly parallelizable work, this system is designed to compute only the data that is actually necessary. What data is necessary can be determined dynamically during evaluation. Many lazy-functions can be composed in a graph to form a new lazy-function, which can again be used in a graph etc. * Each geometry node group is converted into a lazy-function graph prior to evaluation. To evaluate geometry nodes, one then just has to evaluate that graph. Node groups are no longer inlined into their parents. Next steps for the evaluation system is to reduce the use of threads in some situations to avoid overhead. Many small node groups don't benefit from multi-threading at all. This is much easier to do now because not everything has to be inlined in one huge node tree anymore. Differential Revision: https://developer.blender.org/D15914
2022-09-13 08:44:26 +02:00
};
/* -------------------------------------------------------------------- */
/** \name #Socket Inline Methods
* \{ */
inline bool Socket::is_input() const
{
return is_input_;
}
inline bool Socket::is_output() const
{
return !is_input_;
}
inline int Socket::index() const
{
return index_in_node_;
}
Geometry Nodes: deterministic anonymous attribute lifetimes Previously, the lifetimes of anonymous attributes were determined by reference counts which were non-deterministic when multiple threads are used. Now the lifetimes of anonymous attributes are handled more explicitly and deterministically. This is a prerequisite for any kind of caching, because caching the output of nodes that do things non-deterministically and have "invisible inputs" (reference counts) doesn't really work. For more details for how deterministic lifetimes are achieved, see D16858. No functional changes are expected. Small performance changes are expected as well (within few percent, anything larger regressions should be reported as bugs). Differential Revision: https://developer.blender.org/D16858
2023-01-05 14:05:30 +01:00
inline int Socket::index_in_graph() const
{
return index_in_graph_;
}
Geometry Nodes: new evaluation system This refactors the geometry nodes evaluation system. No changes for the user are expected. At a high level the goals are: * Support using geometry nodes outside of the geometry nodes modifier. * Support using the evaluator infrastructure for other purposes like field evaluation. * Support more nodes, especially when many of them are disabled behind switch nodes. * Support doing preprocessing on node groups. For more details see T98492. There are fairly detailed comments in the code, but here is a high level overview for how it works now: * There is a new "lazy-function" system. It is similar in spirit to the multi-function system but with different goals. Instead of optimizing throughput for highly parallelizable work, this system is designed to compute only the data that is actually necessary. What data is necessary can be determined dynamically during evaluation. Many lazy-functions can be composed in a graph to form a new lazy-function, which can again be used in a graph etc. * Each geometry node group is converted into a lazy-function graph prior to evaluation. To evaluate geometry nodes, one then just has to evaluate that graph. Node groups are no longer inlined into their parents. Next steps for the evaluation system is to reduce the use of threads in some situations to avoid overhead. Many small node groups don't benefit from multi-threading at all. This is much easier to do now because not everything has to be inlined in one huge node tree anymore. Differential Revision: https://developer.blender.org/D15914
2022-09-13 08:44:26 +02:00
inline InputSocket &Socket::as_input()
{
BLI_assert(this->is_input());
return *static_cast<InputSocket *>(this);
}
inline OutputSocket &Socket::as_output()
{
BLI_assert(this->is_output());
return *static_cast<OutputSocket *>(this);
}
inline const InputSocket &Socket::as_input() const
{
BLI_assert(this->is_input());
return *static_cast<const InputSocket *>(this);
}
inline const OutputSocket &Socket::as_output() const
{
BLI_assert(this->is_output());
return *static_cast<const OutputSocket *>(this);
}
inline const Node &Socket::node() const
{
return *node_;
}
inline Node &Socket::node()
{
return *node_;
}
inline const CPPType &Socket::type() const
{
return *type_;
}
/** \} */
/* -------------------------------------------------------------------- */
/** \name #InputSocket Inline Methods
* \{ */
inline const OutputSocket *InputSocket::origin() const
{
return origin_;
}
inline OutputSocket *InputSocket::origin()
{
return origin_;
}
inline const void *InputSocket::default_value() const
{
return default_value_;
}
inline void InputSocket::set_default_value(const void *value)
{
default_value_ = value;
}
/** \} */
/* -------------------------------------------------------------------- */
/** \name #OutputSocket Inline Methods
* \{ */
inline Span<const InputSocket *> OutputSocket::targets() const
{
return targets_;
}
inline Span<InputSocket *> OutputSocket::targets()
{
return targets_;
}
/** \} */
/* -------------------------------------------------------------------- */
/** \name #Node Inline Methods
* \{ */
Functions: refactor lazy-function graph interface Goals of the refactor: * Simplify adding (named) graph inputs and outputs. * Add ability to refer to a graph input or output with an index. * Get rid of the "dummy" terminology which doesn't really help. Previously, one would add "dummy nodes" which can then serve as input and output nodes of the graph. Now one directly adds input and outputs using `Graph.add_input` and `Graph.add_output`. There is one interface node that contains all inputs and another one that contains all outputs. Being able to refer to a graph input or output with an index makes it more efficient to implement some algorithms. E.g. one could have a bit span for a socket that contains all the information what graph inputs this socket depends on. Pull Request: https://projects.blender.org/blender/blender/pulls/112474
2023-09-17 13:54:09 +02:00
inline bool Node::is_interface() const
Geometry Nodes: new evaluation system This refactors the geometry nodes evaluation system. No changes for the user are expected. At a high level the goals are: * Support using geometry nodes outside of the geometry nodes modifier. * Support using the evaluator infrastructure for other purposes like field evaluation. * Support more nodes, especially when many of them are disabled behind switch nodes. * Support doing preprocessing on node groups. For more details see T98492. There are fairly detailed comments in the code, but here is a high level overview for how it works now: * There is a new "lazy-function" system. It is similar in spirit to the multi-function system but with different goals. Instead of optimizing throughput for highly parallelizable work, this system is designed to compute only the data that is actually necessary. What data is necessary can be determined dynamically during evaluation. Many lazy-functions can be composed in a graph to form a new lazy-function, which can again be used in a graph etc. * Each geometry node group is converted into a lazy-function graph prior to evaluation. To evaluate geometry nodes, one then just has to evaluate that graph. Node groups are no longer inlined into their parents. Next steps for the evaluation system is to reduce the use of threads in some situations to avoid overhead. Many small node groups don't benefit from multi-threading at all. This is much easier to do now because not everything has to be inlined in one huge node tree anymore. Differential Revision: https://developer.blender.org/D15914
2022-09-13 08:44:26 +02:00
{
return fn_ == nullptr;
}
inline bool Node::is_function() const
{
return fn_ != nullptr;
}
inline int Node::index_in_graph() const
{
return index_in_graph_;
}
inline Span<const InputSocket *> Node::inputs() const
{
return inputs_;
}
inline Span<const OutputSocket *> Node::outputs() const
{
return outputs_;
}
inline Span<InputSocket *> Node::inputs()
{
return inputs_;
}
inline Span<OutputSocket *> Node::outputs()
{
return outputs_;
}
inline const InputSocket &Node::input(const int index) const
{
return *inputs_[index];
}
inline const OutputSocket &Node::output(const int index) const
{
return *outputs_[index];
}
inline InputSocket &Node::input(const int index)
{
return *inputs_[index];
}
inline OutputSocket &Node::output(const int index)
{
return *outputs_[index];
}
/** \} */
/* -------------------------------------------------------------------- */
/** \name #FunctionNode Inline Methods
* \{ */
inline const LazyFunction &FunctionNode::function() const
{
BLI_assert(fn_ != nullptr);
return *fn_;
}
/** \} */
/* -------------------------------------------------------------------- */
/** \name #Graph Inline Methods
* \{ */
inline Span<const Node *> Graph::nodes() const
{
return nodes_;
}
Functions: use array indexing instead of VectorSet in graph executor This avoids the need to build the VectorSet and array indexing is generally faster than a hash table lookup.
2023-09-17 14:27:01 +02:00
inline Span<Node *> Graph::nodes()
{
return nodes_;
}
Functions: refactor lazy-function graph interface Goals of the refactor: * Simplify adding (named) graph inputs and outputs. * Add ability to refer to a graph input or output with an index. * Get rid of the "dummy" terminology which doesn't really help. Previously, one would add "dummy nodes" which can then serve as input and output nodes of the graph. Now one directly adds input and outputs using `Graph.add_input` and `Graph.add_output`. There is one interface node that contains all inputs and another one that contains all outputs. Being able to refer to a graph input or output with an index makes it more efficient to implement some algorithms. E.g. one could have a bit span for a socket that contains all the information what graph inputs this socket depends on. Pull Request: https://projects.blender.org/blender/blender/pulls/112474
2023-09-17 13:54:09 +02:00
inline Span<const FunctionNode *> Graph::function_nodes() const
{
return nodes_.as_span().drop_front(2).cast<const FunctionNode *>();
}
inline Span<FunctionNode *> Graph::function_nodes()
{
return nodes_.as_span().drop_front(2).cast<FunctionNode *>();
}
Functions: add lazy-function graph input/output getter methods
2023-10-08 16:01:56 +02:00
inline Span<GraphInputSocket *> Graph::graph_inputs()
{
return graph_inputs_;
}
inline Span<GraphOutputSocket *> Graph::graph_outputs()
{
return graph_outputs_;
}
Functions: use array indexing instead of VectorSet in graph executor This avoids the need to build the VectorSet and array indexing is generally faster than a hash table lookup.
2023-09-17 14:27:01 +02:00
inline Span<const GraphInputSocket *> Graph::graph_inputs() const
Geometry Nodes: deterministic anonymous attribute lifetimes Previously, the lifetimes of anonymous attributes were determined by reference counts which were non-deterministic when multiple threads are used. Now the lifetimes of anonymous attributes are handled more explicitly and deterministically. This is a prerequisite for any kind of caching, because caching the output of nodes that do things non-deterministically and have "invisible inputs" (reference counts) doesn't really work. For more details for how deterministic lifetimes are achieved, see D16858. No functional changes are expected. Small performance changes are expected as well (within few percent, anything larger regressions should be reported as bugs). Differential Revision: https://developer.blender.org/D16858
2023-01-05 14:05:30 +01:00
{
Functions: use array indexing instead of VectorSet in graph executor This avoids the need to build the VectorSet and array indexing is generally faster than a hash table lookup.
2023-09-17 14:27:01 +02:00
return graph_inputs_;
}
inline Span<const GraphOutputSocket *> Graph::graph_outputs() const
{
return graph_outputs_;
Geometry Nodes: deterministic anonymous attribute lifetimes Previously, the lifetimes of anonymous attributes were determined by reference counts which were non-deterministic when multiple threads are used. Now the lifetimes of anonymous attributes are handled more explicitly and deterministically. This is a prerequisite for any kind of caching, because caching the output of nodes that do things non-deterministically and have "invisible inputs" (reference counts) doesn't really work. For more details for how deterministic lifetimes are achieved, see D16858. No functional changes are expected. Small performance changes are expected as well (within few percent, anything larger regressions should be reported as bugs). Differential Revision: https://developer.blender.org/D16858
2023-01-05 14:05:30 +01:00
}
inline int Graph::socket_num() const
{
return socket_num_;
}
Geometry Nodes: new evaluation system This refactors the geometry nodes evaluation system. No changes for the user are expected. At a high level the goals are: * Support using geometry nodes outside of the geometry nodes modifier. * Support using the evaluator infrastructure for other purposes like field evaluation. * Support more nodes, especially when many of them are disabled behind switch nodes. * Support doing preprocessing on node groups. For more details see T98492. There are fairly detailed comments in the code, but here is a high level overview for how it works now: * There is a new "lazy-function" system. It is similar in spirit to the multi-function system but with different goals. Instead of optimizing throughput for highly parallelizable work, this system is designed to compute only the data that is actually necessary. What data is necessary can be determined dynamically during evaluation. Many lazy-functions can be composed in a graph to form a new lazy-function, which can again be used in a graph etc. * Each geometry node group is converted into a lazy-function graph prior to evaluation. To evaluate geometry nodes, one then just has to evaluate that graph. Node groups are no longer inlined into their parents. Next steps for the evaluation system is to reduce the use of threads in some situations to avoid overhead. Many small node groups don't benefit from multi-threading at all. This is much easier to do now because not everything has to be inlined in one huge node tree anymore. Differential Revision: https://developer.blender.org/D15914
2022-09-13 08:44:26 +02:00
/** \} */
} // namespace blender::fn::lazy_function