[Bf-blender-cvs] [dbb1afffc8e] temp-viewport-compositor-merge: Realtime Compositor: Rename GPU material related code
Omar Emara
noreply at git.blender.org
Tue May 31 17:27:57 CEST 2022
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. @@
More information about the Bf-blender-cvs
mailing list