CodeGen: Update codegen optimization code to handle `ifgreatereq`

[kwokcb]

Issue:

compare was removed in 1.37 but not updated in code optimization for igreatereq which was added.

Proposal

Consider adding this optimization back in to test if the upstream decision argument is a constant. If so then add back in code optimization.

It might be worthwhile to consider making optimizations based on conditionals to be a code generation option. This way if an integration wants to not have to regenerate on conditional changes they can.

[jstone-lucasfilm]

As with #1526, I'd recommend that we consider this in the context of broader improvements to the interface reduction rules in MaterialX shader generation, rather than simply restoring a feature from 1.37.

Since these constant folding optimizations represent tradeoffs for the client, improving runtime performance but requiring additional shader recompilation when inputs are modified, it seems important to implement them with broad user controls over which categories of optimizations are applied to shader generation.

[JGamache-autodesk]

I would recommend pruning to be done as a "constant propagation" pass. Which means it would be initiated by the presence of constant nodes (and probably with a shadergen option to enable that optimization pass).

A good constant propagation pass would:

• elide any conditional node where the selector inputs are constant
• compute a constant math result for any math nodes where all inputs are constant
• specialize the NodeGraph used as implementation for a node if some of the inputs of the node are constant by propagating those constant nodes into the nested ShaderGraph by cutting the interface connections and replacing then with constant nodes. We can then initiate a constant propagation pass on this nested shader graph and see if we can optimize further.
• If a NodeGraph ends up completely elided following a constant propagation pass, then the resulting value of the graph output can be used as a constant to elide all shader graph nodes that call this nested graph.

It would be extremely interesting to code, but we need to consider that both the GLSL and OSL compilers are supposed to have a fully functioning optimizer, so maybe we should simply make sure that a constant node with the value 0.18 ends up writing nothing but:

const float myConstant_value = 0.18;

In the generated code, and does not create a uniform shader parameter, thus properly signaling the GLSL and OSL compilers that these values are constant as far as the compiler and optimizer are concerned. A lot less interesting, but also easier to achieve.

[jstone-lucasfilm]

Let's close out this issue along with #1526, in order to keep the focus on designing client-side controls for constant folding and reduced interfaces in shader generation.