You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
// for making IR nodes before we Merkle Hash them and remove duplicates (so main IR doesn't get bloated)
875
-
core::smart_refctd_ptr<CTrueIR> tmpIR;
876
-
// changes dynamically
877
-
const CFrontendIR* srcAST;
878
-
bool btdfSubtree = false;
879
-
// for going over layers in the AST
880
-
core::vector<const CLayer*> layerStack;
881
-
// Some of the things we must canonicalize:
882
-
// A ( f_0 (B + C) + D f_1 ) = f_0 B A + f_0 C A + f_1 D A
883
-
// Expression nodes of the Frontend AST really come in 4 variants:
884
-
// - add
885
-
// - mul
886
-
// - complement, which is equivalent to 1 ADD (-1 MUL x)
887
-
// - function/other
888
-
// BRDFs can appear only under ADD and MUL nodes in the AST not the function/other/complement, so if we want to canonicalize:
889
-
// 1. The Add above can be ignored, we form full multiplication chain to the top
890
-
// 2. Adds in sibling nodes (below the last add) cause us to have to add a factored copy to the IR
891
-
// DFS from right-to-left (inverse order of adding children to stack), would cause us to keep postifxes of the multiplier chain every time we descend into ADD.
892
-
// We want to essentially visit the parent ADD node again after dealing with its subtree (in-order traversal) then mul chain can be reset just to the parent.
893
-
// If we perform DFS stack push left-to-right, we'll know the contributor already for all the leaf nodes if we push it onto the stack.
894
-
// Then for all other leaf nodes we can accumulate them in the MUL chain, and adding their weighted contributor whenever we're back at an ADD node (be it the ancestor or sibling/cousin).
895
-
// If the contributor is null or multiplied with a null we can keep draining the stack until we're back at its immediate parent ADD node.
896
-
structSContributor
897
-
{
898
-
// the "active" contributor, basically the leftmost item in the subbranch below and ADD
// We only track multiplicative factors, we break down every BRDF equally into the canonical form
907
-
handle_t handle;
908
-
uint8_t negate : 1 = false;
909
-
uint8_t monochrome : 1 = true;
910
-
// extend later when allowing variable bucket count
911
-
uint8_t liveSpectralChannels : 3 = 0b111;
912
-
};
913
-
// here we keep the multiplication chain unsorted so its each to add/remove nodes as we encounter them
914
-
core::vector<SFactor> mulChain;
915
-
// scratch for sorting the mul chain before adding a contributor
916
-
core::vector<SFactor> mulChainSortScratch;
917
-
// By maintaining a hash map of AST nodes which simplify to a Constant (unity, or zero, or other) we could resolve the issue of the `nonMulImmediateAncestorStackEnd`
918
-
// which has us adding the same non-mul node multiple times to stack during the traversal.
919
-
// However how much of that would be moving IR manipulation into the AST ?
// for making IR nodes before we Merkle Hash them and remove duplicates (so main IR doesn't get bloated)
899
+
core::smart_refctd_ptr<CTrueIR> tmpIR;
900
+
// changes dynamically
901
+
const CFrontendIR* srcAST;
902
+
SDotPrinter astPrinter;
903
+
bool btdfSubtree = false;
904
+
// for going over layers in the AST
905
+
core::vector<const CLayer*> layerStack;
906
+
// Some of the things we must canonicalize:
907
+
// A ( f_0 (B + C) + D f_1 ) = f_0 B A + f_0 C A + f_1 D A
908
+
// Expression nodes of the Frontend AST really come in 4 variants:
909
+
// - add
910
+
// - mul
911
+
// - complement, which is equivalent to 1 ADD (-1 MUL x)
912
+
// - function/other
913
+
// BRDFs can appear only under ADD and MUL nodes in the AST not the function/other/complement, so if we want to canonicalize:
914
+
// 1. The Add above can be ignored, we form full multiplication chain to the top
915
+
// 2. Adds in sibling nodes (below the last add) cause us to have to add a factored copy to the IR
916
+
// DFS from right-to-left (inverse order of adding children to stack), would cause us to keep postifxes of the multiplier chain every time we descend into ADD.
917
+
// We want to essentially visit the parent ADD node again after dealing with its subtree (in-order traversal) then mul chain can be reset just to the parent.
918
+
// If we perform DFS stack push left-to-right, we'll know the contributor already for all the leaf nodes if we push it onto the stack.
919
+
// Then for all other leaf nodes we can accumulate them in the MUL chain, and adding their weighted contributor whenever we're back at an ADD node (be it the ancestor or sibling/cousin).
920
+
// If the contributor is null or multiplied with a null we can keep draining the stack until we're back at its immediate parent ADD node.
921
+
structSContributor
922
+
{
923
+
// the "active" contributor, basically the leftmost item in the subbranch below and ADD
// We only track multiplicative factors, we break down every BRDF equally into the canonical form
932
+
handle_t handle;
933
+
uint8_t negate : 1 = false;
934
+
uint8_t monochrome : 1 = true;
935
+
// extend later when allowing variable bucket count
936
+
uint8_t liveSpectralChannels : 3 = 0b111;
937
+
};
938
+
// here we keep the multiplication chain unsorted so its each to add/remove nodes as we encounter them
939
+
core::vector<SFactor> mulChain;
940
+
// scratch for sorting the mul chain before adding a contributor
941
+
core::vector<SFactor> mulChainSortScratch;
942
+
// By maintaining a hash map of AST nodes which simplify to a Constant (unity, or zero, or other) we could resolve the issue of the `nonMulImmediateAncestorStackEnd`
943
+
// which has us adding the same non-mul node multiple times to stack during the traversal.
944
+
// However how much of that would be moving IR manipulation into the AST ?
0 commit comments