Early lobe pruning during ShaderGraph construction

[ppenenko]

Summary

This PR partially implements #2680 - an optional early pruning optimization to MaterialX shader generation. The implementation is heavily inspired by the OpenUSD PR PixarAnimationStudios/OpenUSD#3525

When GenOptions::enableLobePruning is enabled, the system analyzes NodeGraph topology to identify topological ("permutation-defining") inputs (mix weights, multiply factors) that, when hardcoded to 0 or 1 at a call site, allow entire dead branches to be pruned. In contrast to #2499 and #2832 which rely on rewriting the already-constructed ShaderGraph in the optimize call, this PR applies pruning at an earlier stage - during ShaderGraph construction, during the NodeGraph traversal. If a sub-node is found to be prunable, the traversal skips it entirely. This allows us to save time even at the codegen stage.

Key components

• NodeGraphTopology (new): Statically analyzes a NodeGraph to identify topological inputs and which internal nodes each can eliminate. Results are cached per NodeGraph in GenContext via NodeGraphTopologyCache.
• NodeGraphPermutation (new): Lightweight object representing a specific pruning configuration for a call site, produced by NodeGraphTopology::createPermutation().
• CompoundNode / ShaderGenerator changes: Thread the permutation through createShaderNodeImplForNodeGraph() → ShaderGraph::create() → createConnectedNodes(), where shouldPrune() skips dead nodes before they are instantiated.
• GenOptions::enableLobePruning: Runtime flag (default off) to enable the optimization. Wired through test suite options.

Measurement infrastructure

The optimization was measured with a set of companion PRs that add profiling and comparison tooling to the MaterialX test suite:

• Extended tracing instrumentation for shader codegen and rendering #2820 — Extended tracing instrumentation for shader codegen and rendering
• Add envSampleCount and framesPerMaterial test suite options #2821 — envSampleCount and framesPerMaterial test suite options
• Python comparison scripts for test suite output (diff_test_runs) #2822 — Python comparison scripts for test suite output (diff_test_runs)
• GPU async timing instrumentation via MX_TRACE_ASYNC #2824 — GPU async timing instrumentation via MX_TRACE_ASYNC

Results

Measured on the MaterialX test suite (baseline vs. enableLobePruning=true).

GPU frame time has not improved noticeably.

Shader compilation time shows clear improvement for materials with prunable lobes:

The lines of code metric also shows a clear reduction, reflecting the decreased shader complexity:

Further work

This PR performs what is effectively early dead code elimination (DCE) based on input values that are known to be hardcoded for all possible instances of the material - for example, unconnected subnode inputs assuming default values. This is the same optimization that the downstream shader compiler (e.g. glslang + spirv-opt or the video driver compiler) would eventually perform, resulting in an equally optimized final shader binary, which explains the lack of improvement in GPU frame time. However, DCE performed earlier, during MaterialX codegen is cheaper and saves the more expensive time overhead of DCE in the compiler.

A natural follow-up is to proactively generate more optimal shader permutations by specializing on the topological input values encountered at run time, similar to Jerry's approach in PixarAnimationStudios/OpenUSD#3525.

[jstone-lucasfilm]

Thanks for putting together this proposal, @ppenenko! The shader source size and compile-time reductions are great to see, and the benefits of this change are clear.

One choice that I'd like to discuss before we proceed further along this path: What are your thoughts on organizing this as a new ShaderGraphRefactor pass rather than as construction-time pruning? I could imagine a LobePruningRefactor pass composing well with the NodeElisionRefactor, PremultipliedBsdfAddRefactor, and DistributeLayerOverMixRefactor passes that we already have.

Here are a few potential benefits of this approach:

• Shared analysis surface: The framework runs passes inside ShaderGraph::finalize against a constructed graph where node classifications (BSDF | CLOSURE | MIX | LAYER) and resolved connections are already available. The proposed NodeGraphTopology analyzer reimplements reference counting at the document layer with hardcoded category strings ("mix", "multiply", the kWeightedPbrNodes allowlist), most of which the ShaderGraph layer already gives us for free.
• Natural overlap with PremultipliedBsdfAddRefactor: Both passes special-case BSDF mix nodes with weight inputs, and living side-by-side as refactor passes makes that sharing straightforward.
• Composability: Passes run in sequence with removeUnusedNodes between them, so e.g. constant elision can clean up inputs that became unconnected after pruning, with no bespoke plumbing.
• API consistency: Adding a ShaderGraphRefactor pass would require no changes to createShaderNodeImplForNodeGraph, making this PR transparent to custom shader generators.

I think the strongest argument for your construction-time approach is that lobe pruning is call-site-specialized in a way the existing refactor passes aren't. The same NodeGraph needs to yield different ShaderGraphs depending on the parent material's inputs. That's not trivial, but I don't think it's blocking; a refactor pass running inside CompoundNode::initialize already has access to GenContext::getParentNodes, so it can specialize the same way without leaving the framework.

The remaining benefit of your proposed approach is avoiding ShaderNode::create and initialize for pruned nodes. Do you have a sense of how much of the measured code generation time win comes from that specifically, vs. just from emitting fewer nodes downstream? If most of the win is downstream, then a refactor-pass form likely captures most of it while staying consistent with the framework that just landed.

Let me know your thoughts!