Commit: dbb1afffc8eb96b8bf25feee05a5e6972baaf7f3
Author: Omar Emara
Date: Tue May 31 16:51:16 2022 +0200
Branches: temp-viewport-compositor-merge
https://developer.blender.org/rBdbb1afffc8eb96b8bf25feee05a5e6972baaf7f3
Realtime Compositor: Rename GPU material related code
===================================================================
M source/blender/blenkernel/BKE_node.h
M source/blender/compositor/realtime_compositor/CMakeLists.txt
M source/blender/compositor/realtime_compositor/COM_compile_state.hh
M source/blender/compositor/realtime_compositor/COM_evaluator.hh
R095 source/blender/compositor/realtime_compositor/COM_gpu_material_node.hh
source/blender/compositor/realtime_compositor/COM_shader_node.hh
R069
source/blender/compositor/realtime_compositor/COM_gpu_material_operation.hh
source/blender/compositor/realtime_compositor/COM_shader_operation.hh
M source/blender/compositor/realtime_compositor/COM_utilities.hh
M source/blender/compositor/realtime_compositor/intern/compile_state.cc
M source/blender/compositor/realtime_compositor/intern/evaluator.cc
M source/blender/compositor/realtime_compositor/intern/scheduler.cc
R090
source/blender/compositor/realtime_compositor/intern/gpu_material_node.cc
source/blender/compositor/realtime_compositor/intern/shader_node.cc
R073
source/blender/compositor/realtime_compositor/intern/gpu_material_operation.cc
source/blender/compositor/realtime_compositor/intern/shader_operation.cc
M source/blender/compositor/realtime_compositor/intern/utilities.cc
M source/blender/nodes/composite/nodes/node_composite_alpha_over.cc
M source/blender/nodes/composite/nodes/node_composite_brightness.cc
M source/blender/nodes/composite/nodes/node_composite_channel_matte.cc
M source/blender/nodes/composite/nodes/node_composite_chroma_matte.cc
M source/blender/nodes/composite/nodes/node_composite_color_matte.cc
M source/blender/nodes/composite/nodes/node_composite_color_spill.cc
M source/blender/nodes/composite/nodes/node_composite_colorbalance.cc
M source/blender/nodes/composite/nodes/node_composite_colorcorrection.cc
M source/blender/nodes/composite/nodes/node_composite_curves.cc
M source/blender/nodes/composite/nodes/node_composite_diff_matte.cc
M source/blender/nodes/composite/nodes/node_composite_distance_matte.cc
M source/blender/nodes/composite/nodes/node_composite_exposure.cc
M source/blender/nodes/composite/nodes/node_composite_gamma.cc
M source/blender/nodes/composite/nodes/node_composite_hue_sat_val.cc
M source/blender/nodes/composite/nodes/node_composite_huecorrect.cc
M source/blender/nodes/composite/nodes/node_composite_invert.cc
M source/blender/nodes/composite/nodes/node_composite_luma_matte.cc
M source/blender/nodes/composite/nodes/node_composite_map_range.cc
M source/blender/nodes/composite/nodes/node_composite_map_value.cc
M source/blender/nodes/composite/nodes/node_composite_math.cc
M source/blender/nodes/composite/nodes/node_composite_mixrgb.cc
M source/blender/nodes/composite/nodes/node_composite_normal.cc
M source/blender/nodes/composite/nodes/node_composite_posterize.cc
M source/blender/nodes/composite/nodes/node_composite_premulkey.cc
M source/blender/nodes/composite/nodes/node_composite_sepcomb_hsva.cc
M source/blender/nodes/composite/nodes/node_composite_sepcomb_rgba.cc
M source/blender/nodes/composite/nodes/node_composite_sepcomb_xyz.cc
M source/blender/nodes/composite/nodes/node_composite_sepcomb_ycca.cc
M source/blender/nodes/composite/nodes/node_composite_sepcomb_yuva.cc
M source/blender/nodes/composite/nodes/node_composite_setalpha.cc
M source/blender/nodes/composite/nodes/node_composite_val_to_rgb.cc
===================================================================
diff --git a/source/blender/blenkernel/BKE_node.h
b/source/blender/blenkernel/BKE_node.h
index fcc125dc20b..d142a8796c2 100644
--- a/source/blender/blenkernel/BKE_node.h
+++ b/source/blender/blenkernel/BKE_node.h
@@ -113,7 +113,7 @@ class MFDataType;
namespace realtime_compositor {
class Context;
class NodeOperation;
-class GPUMaterialNode;
+class ShaderNode;
} // namespace realtime_compositor
} // namespace blender
@@ -131,12 +131,12 @@ using NodeGatherSocketLinkOperationsFunction =
using NodeGetCompositorOperationFunction =
blender::realtime_compositor::NodeOperation
*(*)(blender::realtime_compositor::Context &context, blender::nodes::DNode
node);
-using NodeGetCompositorGPUMaterialNodeFunction =
- blender::realtime_compositor::GPUMaterialNode *(*)(blender::nodes::DNode
node);
+using NodeGetCompositorShaderNodeFunction =
+ blender::realtime_compositor::ShaderNode *(*)(blender::nodes::DNode node);
#else
typedef void *NodeGetCompositorOperationFunction;
-typedef void *NodeGetCompositorGPUMaterialNodeFunction;
+typedef void *NodeGetCompositorShaderNodeFunction;
typedef void *NodeMultiFunctionBuildFunction;
typedef void *NodeGeometryExecFunction;
typedef void *NodeDeclareFunction;
@@ -326,9 +326,9 @@ typedef struct bNodeType {
* responsibility of the caller. */
NodeGetCompositorOperationFunction get_compositor_operation;
- /* Get an instance of this node's compositor GPU material node. Freeing the
instance is the
+ /* Get an instance of this node's compositor shader node. Freeing the
instance is the
* responsibility of the caller. */
- NodeGetCompositorGPUMaterialNodeFunction get_compositor_gpu_material_node;
+ NodeGetCompositorShaderNodeFunction get_compositor_shader_node;
/* Build a multi-function for this node. */
NodeMultiFunctionBuildFunction build_multi_function;
diff --git a/source/blender/compositor/realtime_compositor/CMakeLists.txt
b/source/blender/compositor/realtime_compositor/CMakeLists.txt
index e0abc9314e4..589fab6c099 100644
--- a/source/blender/compositor/realtime_compositor/CMakeLists.txt
+++ b/source/blender/compositor/realtime_compositor/CMakeLists.txt
@@ -20,8 +20,6 @@ set(SRC
intern/conversion_processor_operation.cc
intern/domain.cc
intern/evaluator.cc
- intern/gpu_material_node.cc
- intern/gpu_material_operation.cc
intern/input_single_value_operation.cc
intern/node_operation.cc
intern/operation.cc
@@ -30,6 +28,8 @@ set(SRC
intern/reduce_to_single_value_processor_operation.cc
intern/result.cc
intern/scheduler.cc
+ intern/shader_node.cc
+ intern/shader_operation.cc
intern/shader_pool.cc
intern/texture_pool.cc
intern/unsupported_node_operation.cc
@@ -40,8 +40,6 @@ set(SRC
COM_conversion_processor_operation.hh
COM_domain.hh
COM_evaluator.hh
- COM_gpu_material_node.hh
- COM_gpu_material_operation.hh
COM_input_descriptor.hh
COM_input_single_value_operation.hh
COM_node_operation.hh
@@ -51,6 +49,8 @@ set(SRC
COM_reduce_to_single_value_processor_operation.hh
COM_result.hh
COM_scheduler.hh
+ COM_shader_node.hh
+ COM_shader_operation.hh
COM_shader_pool.hh
COM_texture_pool.hh
COM_unsupported_node_operation.hh
diff --git a/source/blender/compositor/realtime_compositor/COM_compile_state.hh
b/source/blender/compositor/realtime_compositor/COM_compile_state.hh
index 344ae7f3923..ba2dbe9f13e 100644
--- a/source/blender/compositor/realtime_compositor/COM_compile_state.hh
+++ b/source/blender/compositor/realtime_compositor/COM_compile_state.hh
@@ -7,9 +7,9 @@
#include "NOD_derived_node_tree.hh"
#include "COM_domain.hh"
-#include "COM_gpu_material_operation.hh"
#include "COM_node_operation.hh"
#include "COM_scheduler.hh"
+#include "COM_shader_operation.hh"
namespace blender::realtime_compositor {
@@ -24,17 +24,15 @@ using namespace nodes::derived_node_tree_types;
*
* First, it stores a mapping between all nodes and the operations they were
compiled into. The
* mapping are stored independently depending on the type of the operation in
the node_operations_
- * and gpu_material_operations_ maps. So those two maps are mutually
exclusive. The compiler should
- * call the map_node_to_node_operation and map_node_to_gpu_material_operation
methods to populate
- * those maps as soon as it compiles a node into an operation. Those maps are
used to retrieve the
- * results of outputs linked to the inputs of operations. See the
get_result_from_output_socket
- * method for more details. For the node tree shown below, nodes 1, 2, and 6
are mapped to their
- * compiled operations in the node_operation_ map. While nodes 3 and 4 are
both mapped to the first
- * GPU material operation, and node 5 is mapped to the second GPU material
operation in the
- * gpu_material_operations_ map.
+ * and shader_operations_ maps. So those two maps are mutually exclusive. The
compiler should call
+ * the map_node_to_node_operation and map_node_to_shader_operation methods to
populate those maps
+ * as soon as it compiles a node into an operation. Those maps are used to
retrieve the results of
+ * outputs linked to the inputs of operations. See the
get_result_from_output_socket method for
+ * more details. For the node tree shown below, nodes 1, 2, and 6 are mapped
to their compiled
+ * operations in the node_operation_ map. While nodes 3 and 4 are both mapped
to the first shader
+ * operation, and node 5 is mapped to the second shader operation in the
shader_operations_ map.
*
- *
- * GPU Material 1 GPU Material
2
+ * Shader Operation 1 Shader
Operation 2
* +-----------------------------------+
+------------------+
* .------------. | .------------. .------------. | |
.------------. | .------------.
* | Node 1 | | | Node 3 | | Node 4 | | | | Node 5
| | | Node 6 |
@@ -48,38 +46,38 @@ using namespace nodes::derived_node_tree_types;
* | |
* '------------'
*
- * Second, it stores the GPU material compile group as well as its domain. One
should first go over
- * the discussion in COM_evaluator.hh for a high level description of the
mechanism of the compile
- * group. The one important detail in this class is the
should_compile_gpu_material_compile_group
- * method, which implements the criteria of whether the compile group should
be compiled given the
- * node currently being processed as an argument. Those criteria are described
as follows. If the
- * compile group is empty as is the case when processing nodes 1, 2, and 3,
then it plainly
- * shouldn't be compiled. If the given node is not a GPU material node, then
it can't be added to
- * the compile group and the group is considered complete and should be
compiled, as is the case
- * when processing node 6. If the computed domain of the given node is not
compatible with the
- * domain of the compiled group, then it can't be added to the group and the
group is considered
- * complete and should be compiled, as is the case when processing node 5,
more on this in the next
- * section. Otherwise, the given node is compatible with the compile group and
can be added to it,
- * so the group shouldn't be compiled just yet, as is the case when processing
node 4.
+ * Second, it stores the shader compile unit as well as its domain. One should
first go over the
+ * discussion in COM_evaluator.hh for a high level description of the
mechanism of the compile
+ * unit. The one important detail in this class is the
should_compile_shader_compile_unit method,
+ * which implements the criteria of whether the compile unit should be
compiled given the node
+ * currently being processed as an argument. Those criteria are described as
follows. If the
+ * compile unit is empty as is the case when processing nodes 1, 2, and 3,
then it plainly
+ * shouldn't be compiled. If the given node is not a shader node, then it
can't be added to the
+ * compile unit and the unit is considered complete and should be compiled, as
is the case when
+ * processing node 6. If the computed domain of the given node is not
compatible with the domain of
+ * the compiled unit, then it can't be added to the unit and the unit is
considered complete and
+ * should be compiled, as is the case when processing node 5, more on this in
the next section.
+ * Otherwise, the given node is compatible with the compile unit and can be
added to it, so the
+ * unit shouldn't be compiled just yet, as is the case when processing node 4.
*
* Special attention should be given to the aforementioned domain
compatibility criterion. One
* should first go over the discussion in COM_domain.hh for more information
on domains. When a
- * compile group gets eventually compiled to a GPU material operation, that
operation will have a
- * certain operation domain, and any node that gets added to the compile group
should itself have a
- * computed node domain that is compatible with that operation domain,
otherwise, had the node been
- * compiled into its own operation separately, the result would have been be
different. For
- * instance, consider the above node tree where node 1 outputs a 100x100
result, node 2 outputs a
- * 50x50 result, the first input in node 3 has the highest domain priority,
and the second input in
- * node 5 has the highest domain priority. In this case, GPU Material 1 will
output a 100x100
- * result, and GPU Material 2 will output a 50x50 result, because that's the
computed operation
+ * compile unit gets eventually compiled to a shader operation, that operation
will have a certain
+ * operation domain, and any node that gets added to the compile unit should
itself have a computed
+ * node domain that is compatible with that operation domain, otherwise, had
the node been compiled
+ * into its own operation separately, the result would have been be different.
For instance,
+ * consider the above node tree where node 1 outputs a 100x100 result, node 2
outputs a 50x50
+ * result, the first input in node 3 has the highest domain priority, and the
second input in node
+ * 5 has the highest domain priority. In this case, shader operation 1 will
output a 100x
@@ Diff output truncated at 10240 characters. @@
_______________________________________________
Bf-blender-cvs mailing list
[email protected]
List details, subscription details or unsubscribe:
https://lists.blender.org/mailman/listinfo/bf-blender-cvs