MaterialX: Optimize Lobe Pruning For GPU Performance

Introduction

This article delves into the proposal to integrate Lobe Pruning optimization directly into the MaterialX core. Currently, this optimization exists in external renderers. By bringing it into the core, we aim to enhance runtime GPU performance for all renderers that utilize MaterialX. This will lead to more efficient and faster rendering across various platforms.

Motivation

The MaterialX community is actively seeking ways to optimize shader performance, as highlighted in issue #2480. Complex shading models, such as OpenPBR and Standard Surface, generate intricate shader code with numerous BSDF lobes (subsurface, transmission, coat, etc.). However, when certain material parameters disable these lobes—for instance, by setting subsurface_weight to 0—the generated shader still contains the evaluation code for those unused features, which leads to shader bloat, and wasted GPU cycles evaluating unused BSDFs.

This inefficiency manifests in several critical issues:

• Bloated Shader Code: Makes navigation and debugging more difficult due to the increased complexity.
• Texture and Uniform Limits: Pushes the boundaries of available resources, particularly on platforms like WebGPU, hindering performance.
• Wasted GPU Cycles: Resources are spent evaluating BSDFs and their associated input networks that ultimately contribute nothing to the final rendered output.
• Increased Register Pressure: Reduces GPU occupancy, which significantly impacts performance, especially on mobile and integrated GPUs.

Lobe Pruning offers a solution by analyzing the shader graph before code generation and eliminating branches that do not contribute to the final result. When lobe weight parameters are compile-time constants (akin to constexpr in C++), meaning their values are known during shader generation, entire subgraphs can be safely removed.

Expected Performance Impact

An implementation of the Lobe Pruning algorithm in OpenUSD PR #3525 has demonstrated runtime performance improvements of up to x4. We anticipate similar performance gains with the MaterialX implementation. This improvement translates to significantly faster rendering times and a more efficient use of GPU resources, ultimately enhancing the user experience.

Prior Work

Currently, there are two open-source implementations of the Lobe Pruning optimization developed by @JGamache-autodesk. These implementations have been thoroughly tested and have demonstrated significant performance benefits in real-world scenarios.

Core Algorithm

Both implementations utilize the same core optimization algorithm, which consists of three primary pruning rules:

1. Mix Nodes: If the mix factor is 0 or 1, forward the appropriate input and remove the mix node.
2. Multiply Nodes: If either input is 0, propagate the zero value upstream and remove the multiply node.
3. BSDF Nodes: If a weight parameter is 0, replace the BSDF node with a no-op "dark" BSDF and remove the original node.

These implementations target standard PBR BSDF nodes from the MaterialX specification (e.g., burley_diffuse_bsdf, conductor_bsdf, subsurface_bsdf, dielectric_bsdf, sheen_bsdf) and generate special "dark" BSDF nodes as no-op replacements for zero-weight BSDFs (e.g., dark_base_bsdf, dark_layer_bsdf).

When enabled, the optimizer traverses the shader graph and removes entire subgraphs that are deemed unnecessary.

Example: For a Standard Surface material with subsurface_weight = 0.0:

1. The entire subsurface BSDF evaluation is eliminated.
2. All upstream texture fetches and math nodes feeding into the subsurface are removed.
3. The final mix operations are simplified, resulting in a leaner and more efficient shader.

Maya USD Implementation

Maya USD features a production implementation of Lobe Pruning for a non-Storm Hydra render delegate drawing via Maya's Viewport 2.0, which was introduced in November 2024.

Key characteristics:

• MaterialX APIs: It leverages MaterialX APIs, ensuring no USD dependencies in the core logic, making it highly portable and reusable.
• NodeGraph Level: Operates at the MaterialX document/NodeGraph level, providing a high-level optimization strategy.
• Topology-Neutral Graph Generation: Tightly integrated with topology-neutral graph generation for efficient shader caching, further enhancing performance.

Hydra Storm Implementation

Autodesk has also developed and submitted Lobe Pruning to Hydra Storm in OpenUSD PR #3525 (under review since February 2025).

Unlike the Maya USD implementation, this version operates on Hydra material networks instead of MaterialX node graphs. This is essential for seamless integration with USD's material workflows. These Hydra networks are created from MaterialX documents and are eventually converted back to MaterialX documents for code generation.

Proposal: ShaderGraph-Level Integration

The proposal is to integrate Lobe Pruning at the ShaderGraph level.

Motivation for the ShaderGraph Target

MaterialX Issue #2566 proposes a fundamental architectural change to shader generation. The Visitor Pattern API will enable MaterialX to generate shaders directly from non-MaterialX data sources, such as Hydra material networks, without requiring an initial conversion to a MaterialX document.

This architectural shift has critical implications for Lobe Pruning:

• Forward Compatibility: Implementing Lobe Pruning at the document/NodeGraph level would render it obsolete once the Visitor Pattern changes are implemented.
• Universal Applicability: Optimizations at the ShaderGraph level benefit all input sources, including MaterialX documents, USD networks, and custom formats.
• Architectural Layer: ShaderGraph serves as the runtime representation during code generation, making it the ideal location for generation-time optimizations.

Integration Point: ShaderGraph::optimize()

MaterialX already provides optimization infrastructure within ShaderGraph::optimize(), as demonstrated in PR #2499.

Relationship with Existing Optimizations

Premultiplied Add

Core Algorithm

The Premultiplied Add optimization transforms mix(a, b, weight) operations into the add(a * (1 - weight), b * weight) pattern. This transformation enables a runtime GPU hardware optimization: when weight has a uniform value, modern GPUs can skip evaluating the zero-weighted term.

However, it is essential to note that this transformation can be counterproductive for path tracing targets (OSL, MDL) that benefit from early elimination of terms with zero contributions.

Manual Implementation (NodeGraph Level)

MaterialX PRs #2459, #2483 and #2493 manually apply the Premultiplied Add optimization to the OpenPBR, Standard Surface, and glTF PBR NodeGraph definitions, respectively. The mix and add operations are implemented by separate nodes in the node graph.

This manual optimization approach yielded significant performance improvements for real-time rendering and motivated further exploration of performance optimizations. However, it was later restricted to real-time shading languages only by specializing the node graphs for them to avoid impacting path tracing targets.

Limitations:

• Manual and Static: Each case requires separate and manual optimization.
• Target-Specific: Requires specializing node graphs per target.
• Library Node Graphs Only: Does not assist users in optimizing custom node graphs.
• Premature Optimization: Optimizing at the node graph level is considered a premature optimization by the community.

Automated Implementation (ShaderGraph Level)

MaterialX PR #2499 (currently under review) implements the Premultiplied Add transformation programmatically during shader generation.

Advantages over the manual approach:

• Automatic: No case-by-case manual editing required.
• GenOptions: Can be controlled by GenOptions to enable/disable per target.
• ShaderGraph: Works at the ShaderGraph level, benefiting all possible input sources (document, Visitor Pattern, etc.).
• ShaderGraph-level optimizations: Precedent for ShaderGraph-level optimizations.

Relationship to Lobe Pruning

Lobe Pruning is expected to provide additional performance gains over Premultiplied Add due to:

• Reduced register pressure.
• Eliminating unused uniform and texture bindings.
• Reduced shader code complexity, leading to reduced individual shader compilation times.

Performance measurements for the two optimizations support these expectations. However, Lobe Pruning requires weight parameters to be compile-time constants of 0 or 1, which is not always feasible. Additionally, applying Lobe Pruning increases the number of shader permutations to compile, potentially an undesirable trade-off for some applications.

Therefore, the two optimizations should be complimentary and controlled by separate codegen options. They should coexist in ShaderGraph::optimize() and share the code for detecting the optimization opportunities.

Topology Caching

The Topology Caching algorithm optimizes MaterialX codegen and shader compilation performance by determining the equivalence of MaterialX materials with respect to codegen. The underlying performance problem was first documented in OpenUSD Issue #2330 (March 2023). It was observed that Storm was generating separate shaders for functionally equivalent MaterialX networks, leading to unnecessary codegen and compilation overhead. This performance issue is applicable not just to Storm but to any renderer using MaterialX codegen.

Maya USD PR #3445 (merged in November 2023) is the first known open-source implementation of the Topology Caching optimization. It analyzes materials via MaterialX APIs and caches the generated shaders in Maya's own shader cache.

Later, OpenUSD PR #3073 (merged June 2024) introduced a similar optimization to Storm. In contrast to Maya USD, the algorithm analyzes Hydra material networks and relies on Hydra's existing instance registry mechanism for caching. Topology Caching improves cache hit rates for that data structure by using topology hashes as cache keys.

Core Algorithm

This optimization anonymizes shader graphs to enable shader reuse across different materials with equivalent topologies. In particular, the algorithm:

• Determines for each node if it's topological, i.e., if changes to its inputs affect the code generated for its implementation.
• Normalizes the emitted default uniform values, which are otherwise emitted with the current values of the respective MaterialX inputs.
• Anonymizes the node names, which otherwise affect the emitted code.

Similar to Lobe Pruning, the current integrations of Topology Caching are implemented at the node graph level, which is problematic from two perspectives:

1. The topological property of individual nodes is determined by their concrete implementations at the shader graph level. Because of this, magic strings were necessary in the node graph-level implementations. It was discussed in OpenUSD PR #3073 that shader generators should ideally expose this information via a new API.
2. With the Visitor Pattern introduction, these node graph-level optimizations will eventually become obsolete.

Therefore, just like with Lobe Pruning, Topology Caching should eventually be ported to the shader graph level.

It's also important to note that Topology Caching has more integration points with the specific host application than Lobe Pruning. First, as we've seen above, the shader cache is typically implemented by the host application, outside of MaterialX, and Topology Caching needs to integrate with it.

At the same time, Topology Caching has implications for material editing workflows. When the material is edited in the host application, it needs to determine whether the change affects the generated source code or if it only results in a uniform value or texture binding change. As an example of this logic, Maya USD's implementation generates a watch list mapping material attributes to their topological classification for efficient invalidation tracking. This is another integration point with the host application.

Relationship with Lobe Pruning

Lobe Pruning is integrated with Topology Caching in both existing implementations, with Topology Caching predating Lobe Pruning. The Maya USD integration is tighter, with both optimizations applied in the same graph traversal for efficiency. However, the two can be decoupled, controlled by separate settings, and ported separately.

In terms of performance effects:

• Topology Caching: Reduces codegen and compilation time by reducing the number of generated shaders for the given number of materials.
• Lobe Pruning: Reduces runtime GPU cost by simplifying the shaders. The codegen and compilation impact is nuanced: it creates more shader permutations (increasing the number of work items), but each individual shader is simplified (making each work item cheaper). Permutations can be compiled in parallel, and cache hits eliminate recompilation, so having a good cache implementation becomes even more important.

In the interest of separation of concerns and making MaterialX contributions more atomic, the scope of proposal is limited to Lobe Pruning.

Risks / Considerations

Optimizations based on the Lobe Pruning algorithm have already been deployed in multiple production systems, which serve as a proof of concept. Since the proposed changes are only supposed to implement a performance optimization and not modify the rendering behavior, existing MaterialX and USD test workflows can be used to guard against correctness regressions. Finally, the optimization should remain optional, controlled with a runtime switch, for the sake of performance and correctness comparisons and to provide a fallback in the case of regressions.

Performance verification

The results of this optimization should be thoroughly verified with the following mechanisms:

• Instrumentation in MaterialX: Likely requiring a new tracing mechanism similar to that of OpenUSD
• Shader code size: Target language source line count, SPIR-V binary size
• Compilation time: Measured with the proposed MaterialX instrumentation
• Offline analysis with GPU vendor tools for the following metrics:
  • Register pressure
  • Resource usage: Uniform and texture sampler counts
• Runtime performance: FPS measurements in representative scenes

For more information on MaterialX and its capabilities, please visit the Academy Software Foundation website.