Add Perfetto tracing and a test output directory option #2742

ppenenko · 2026-01-08T21:46:44Z

Summary

This PR adds a new MaterialXTrace module with optional Perfetto tracing infrastructure, plus a configurable test output directory, laying the groundwork for performance analysis and optimization work.

Background and motivation

MaterialX doesn't currently offer a tracing/instrumentation infrastructure sufficient for the following goals:

Profiling shader generation and optimization passes
Measuring the impact of proposed optimizations (like those in Shader Generator ND_mix_bsdf optimization #2499), and in particular per-material measurements
Correlating MaterialX performance with USD pipeline traces
Generating detailed flame graphs for performance analysis

In comparison, OpenUSD supports tracing in the Chrome Tracing format—the original format used by Chrome DevTools, viewable via chrome://tracing. It's JSON-based, and OpenUSD implements serialization without external dependencies.

Perfetto is the successor to Chrome Tracing which relies on a more optimal binary Protobuf-based serialization format. https://ui.perfetto.dev/ is capable of opening both Perfetto captures and legacy JSON Chrome Tracing captures. It has better performance than chrome://tracing, can open larger captures and supports more advanced analysis workflows, e.g. SQL queries.

I've chosen Perfetto for the implementation in this PR mostly because of the format's superior performance. For context, using new scene index workflows with Hydra Storm, it's possible to generate multi-gigabyte Chrome Tracing captures that are too big to load in either profiler UI. The implementation relies on the Perfetto SDK.

At the same time, the design remains open for a potential integration of MaterialX tracing with USD tracing, by abstracting out the tracing implementation behind an interface. Such an integration would make it possible to analyze MaterialX shader gen performance in Hydra Storm holistically, in the same profiler UI session or script.

The Lobe Pruning optimization effort (#2680) is the immediate application for this infrastructure.

Features

1. Perfetto Tracing (`MATERIALX_BUILD_TRACING`)

Dedicated MaterialXTrace module – keeps tracing infrastructure separate from MaterialXCore
Zero overhead when disabled – entire module excluded from build when MATERIALX_BUILD_TRACING=OFF
Abstract sink interface (Tracing::Sink) – designed for future USD TraceCollector integration
Enum-based categories (Tracing::Category) for type safety and efficient dispatch:
- Render – rendering operations
- ShaderGen – shader generation
- Optimize – optimization passes
- Material – material identity markers
Template-based scope guard (Tracing::Scope<Category>) – zero stack overhead for category storage
RAII helpers (MX_TRACE_FUNCTION, MX_TRACE_SCOPE) and Dispatcher::ShutdownGuard
Instrumentation in shader generation tests (GenShaderUtil.cpp) and render tests (RenderGlsl.cpp) demonstrating per-material trace markers
Perfetto SDK fetched via CMake FetchContent (v43.0)
CI integration – extended builds (nightly/manual) enable tracing and upload .perfetto-trace artifacts

2. Test Output Directory (`outputDirectory` in `_options.mtlx`)

Redirects all test artifacts (logs, images, shaders, traces) to a user-specified directory
Prevents artifacts from different test runs overwriting each other
Prints effective output path at end of test run for easy IDE navigation

3. Runtime Tracing Toggle (`enableTracing` in `_options.mtlx`)

Enable/disable tracing without rebuilding (requires MATERIALX_BUILD_TRACING=ON at build time)
Default is false to avoid overhead when not profiling

Usage

Enable Tracing (Build Time)

cmake -DMATERIALX_BUILD_TRACING=ON ...

Enable Tracing (Runtime)

In resources/Materials/TestSuite/_options.mtlx:

<input name="enableTracing" type="boolean" value="true" />

Configure Output Directory

<input name="outputDirectory" type="string" value="/path/to/test/output" />

Analyze Traces

Open .perfetto-trace files at https://ui.perfetto.dev

For CI builds, download trace artifacts from the GitHub Actions run page (extended builds only).

- Add MATERIALX_BUILD_TRACING CMake option (OFF by default) - Add abstract MxTraceBackend interface for pluggable tracing backends - Add MxTraceCollector singleton (similar to USD's TraceCollector) - Add MxTraceScope RAII helper and MX_TRACE_* macros - Add MxPerfettoBackend implementation using Perfetto SDK - Initialize/shutdown Perfetto in MaterialXTest Main.cpp - Add trace instrumentation to RenderGlsl test The abstract interface allows USD/Hydra to inject their own tracing backend when calling MaterialX, enabling unified trace visualization. Usage: cmake -DMATERIALX_BUILD_TRACING=ON ... # Run tests, then open materialx_test_trace.perfetto-trace at ui.perfetto.dev

- Add NOMINMAX and WIN32_LEAN_AND_MEAN to prevent min/max macro conflicts - Add /bigobj flag for perfetto.cc (too many sections for MSVC default) - Use BUILD_INTERFACE generator expression for include path - Fix MxTracePerfetto.cpp: add missing <fstream> include and simplify Perfetto API usage (use fixed category with dynamic event names)

- Replace macro category definitions with constexpr namespace constants (MxTraceCategory::Render, ::ShaderGen, ::Optimize, ::Material) - Keep legacy macros for backward compatibility - Fix MX_TRACE_SCOPE macro to properly expand __LINE__ via helper macros - Add MX_TRACE_CAT_MATERIAL category for material/shader identity markers - Add material name trace scope in RenderGlsl for per-material tracking - Add timestamp to trace output filename (format: YYYYMMDD_HHMMSS) - Use MX_TRACE_FUNCTION macro for automatic function name extraction

The Catch2 Test Adapter for Visual Studio runs MaterialXTest.exe with --list-test-names-only to discover tests. Perfetto initialization was outputting to stderr, causing the adapter to fail with exit code 89. Now we detect --list-* arguments and skip tracing initialization, allowing VS Test Explorer to properly discover and debug tests.

Add optional outputDirectory setting to _options.mtlx that redirects all test artifacts (logs, shaders, images, traces) to a user-specified directory. This allows different test runs to be isolated without overwriting each other. Changes: - _options.mtlx: Add outputDirectory input (empty = default behavior) - TestSuiteOptions: Add outputDirectory member and resolveOutputPath() helpers - GenShaderUtil.cpp: Use outputDirectory for shader generation logs and dumps - RenderUtil.cpp: Use outputDirectory for render logs, images, and traces - Main.cpp: Remove tracing code (moved to RenderUtil.cpp) Tracing improvements: - Move Perfetto init/shutdown to ShaderRenderTester::validate() - Each render test now produces its own trace file (e.g., genglsl_render_trace.perfetto-trace) - Trace filenames now follow the same pattern as log files - Removed timestamps from trace filenames for consistency Usage: <input name="outputDirectory" type="string" value="C:/test_results/my_run" />

When outputDirectory is set, print the path at the end of test stdout. This makes it clickable in terminals like Cursor/VS Code for quick access.

- Suppress MSVC warnings from Perfetto SDK templates (C4127, C4146, C4369) - Replace MX_TRACE_CAT_* macros with 'namespace cat = mx::MxTraceCategory' for cleaner code and better IDE support - Update RenderGlsl.cpp to use the new category alias pattern

Rename files and classes to better align with MaterialX naming conventions and improve API clarity: Files: - MxTrace.h/cpp -> Tracing.h/cpp - MxTracePerfetto.h/cpp -> PerfettoSink.h/cpp Classes (now in MaterialX::Tracing namespace): - MxTraceBackend -> Tracing::Sink - MxTraceCollector -> Tracing::Dispatcher - MxTraceScope -> Tracing::Scope - MxTraceCategory -> Tracing::Category - MxPerfettoBackend -> Tracing::PerfettoSink Rationale: - 'Sink' is common terminology in logging/tracing for data destinations - 'Dispatcher' better describes the routing behavior (vs 'Collector') - Nested Tracing:: namespace groups related types cleanly - File names match primary class names (PerfettoSink.h) - Macros keep MX_ prefix for collision safety Usage example: namespace trace = mx::Tracing; auto sink = trace::PerfettoSink::create(); trace::Dispatcher::getInstance().setSink(sink); MX_TRACE_SCOPE(trace::Category::Render, "MyEvent");

- Explain amalgamated source compilation is Google's official recommended approach per https://perfetto.dev/docs/instrumentation/tracing-sdk - Document ws2_32 dependency (Windows Sockets 2 for Perfetto IPC)

Dispatcher: - Takes ownership of sink via unique_ptr (setSink) - Explicit shutdownSink() destroys sink and writes output - Asserts on double-set to catch programming errors PerfettoSink: - Constructor takes output path, starts session immediately - Destructor writes trace file (true RAII) - Uses std::call_once for thread-safe global Perfetto init - Removed pimpl - simpler since only setup code includes this header Scope: - Removed _enabled caching - Dispatcher checks internally - One less bool on the stack per trace scope Usage: - Added TracingGuard scope guard in RenderUtil.cpp for exception safety - Added const to immutable members (_outputPath, _category) The design now follows proper RAII patterns with clear ownership.

Move the scope guard pattern into the Dispatcher class for reusability. Callers can now use mx::Tracing::Dispatcher::ShutdownGuard instead of defining their own local struct.

- New 'enableTracing' boolean option (default: false) - Parsed in TestSuiteOptions::readOptions() - RenderUtil.cpp conditionally initializes PerfettoSink based on this option - Uses std::optional<ShutdownGuard> for conditional scope guard - Allows profiling to be enabled/disabled without rebuilding

- Replace namespace Category with constexpr strings -> enum class Category - Template-based Scope<Category> avoids storing category on stack - PerfettoSink uses switch statement (compiler optimizes to jump table) - Removed categoryMatches() string comparison overhead - Type-safe: can only pass valid Category enum values The enum-based design is simpler, more efficient, and equally compatible with a future USD TraceCollector sink (which uses integer category IDs, not strings).

source/MaterialXCore/PerfettoSink.cpp

jstone-lucasfilm · 2026-01-13T21:44:16Z

@ppenenko I have a few additional questions, as I'd like to better understand the advantages of the approach that you're proposing.

Historically, we've used sampling profilers for performance analysis of the MaterialX project, and here's an example profile of the MaterialX Viewer using the built-in sampling profiler in Visual Studio:

Can you give a sense of the advantages provided by the instrumented profiling in your PR, in order to better understand the benefits that might be associated with this additional infrastructure in MaterialX?

And when profiling the results of shader generation in hardware shading languages (e.g. GLSL, MSL, Slang), I would naturally think of GPU profilers such as RenderDoc as the natural approach for recording and comparing performance data.

Is your proposed approach in this PR intended as a replacement for this form of traditional GPU profiling, or is it purely focused on CPU profiling? If it supports GPU profiling, what are its benefits over RenderDoc?

ashwinbhat · 2026-01-14T18:00:11Z

The current catch2 based benchmark test in MaterialX is very simple and having a more robust tracing system that integrates well in libraries/applications that MaterialX is used in will be valuable. For example when MaterialX is integrated into USD we can enable USDTrace and MaterialX tracing to get captures with more detailed view.

@jstone-lucasfilm would this PR be more acceptable if we create a new MaterialXTrace module that brings in Perfetto. So this would be similar to USD tracing but more simpler. Here is some additional info about USD Trace https://github.com/PixarAnimationStudios/OpenUSD/tree/dev/pxr/base/trace

jstone-lucasfilm · 2026-01-14T18:22:00Z

@ashwinbhat For adding an instrumented trace concept to MaterialX, I agree a MaterialXTrace module would be better than adding new source code to MaterialXCore, and I'm open to this approach.

I'd still like to learn more, though, about the advantages offered by instrumented profilers such as Perfetto over the existing sampled profilers we've used previously in MaterialX performance evaluation, which don't require additional code to be inserted into applications at all. So far, I haven't encountered cases where the precision of sampled profilers was insufficient to fully understand the impact of a proposed optimization or codebase change, and I'd love to learn more about the cases that other teams have run into where sampling profilers were not up to the task.

Also, I'd like to better understand the relationship of Perfetto to GPU profiling, which is just as important (or perhaps more important) in evaluating the impact of a ShaderGen change on the real-time rendering performance of MaterialX content.

ppenenko · 2026-01-14T18:50:40Z

@jstone-lucasfilm I agree that sampling profilers are of course useful tools in their own right, but instrumentation adds a different useful perspective. Some advantages:

Most importantly, we can instrument with arbitrary strings that matter to us, e.g. material and shader names, not just C++ symbols.
Cross-platform, while sampling profilers are typically not. Same trace format recorded on any platform.
Sampling profilers can miss, under-represent or over-represent events due to temporal aliasing.

ppenenko · 2026-01-14T18:53:06Z

Some benefits of Perfetto specifically:

Captures can be analyzed in a web browser any platform, without the need to install any specialized tools. Thus, easy to share with anyone.
Rich analysis functionality with SQL and a Python API.
Potential for IPC backends.
Overall, feature-rich and battle-tested by Chrome.

ppenenko · 2026-01-14T19:09:47Z

Good point about CPU vs. GPU traces @jstone-lucasfilm . AFAIK Perfetto doesn't offer facilities for GPU profiling out of the box, but the application itself can perform GPU perf queries and report the results via Perfetto. In fact, this is what I'm working on in another branch. At the same time, CPU and GPU events can be analyzed in the same UI in Perfetto, which is convenient. Besides, MaterialX has no CPU-side tracing system anyway, so integrating Perfetto will help many more CPU performance experiments in the future.

Of course, Renderdoc would offer a much more detailed picture of a GPU frame, but it's designed for profiling at a lower level. Its captures would contain GPU resources, which would have a much higher overhead (capture file size) than the per-material measurements I'm adding with Perfetto. So, I would suggest identifying the materials that are slow to render or benefit from a certain optimization by analyzing the existing render test across 180+ materials with Perfetto (I can already confirm that that is working well) and then, if necessary, profiling specific materials in Renderdoc, Nsight etc.

By the way, if we wanted to see material and shader names in Renderdoc captures, we'd have to instrument our code either way. So the instrumentation macros I'm proposing could have a Renderdoc implementation in the future.

ppenenko · 2026-01-14T21:02:17Z

Great idea about MaterialXTrace @ashwinbhat - it does feel better encapsulated. It would be a very small library though. Anyway, I'll refactor this aspect.

jstone-lucasfilm · 2026-01-14T21:41:44Z

@ppenenko @ashwinbhat Pivoting for a moment, let's focus on the "steelman" arguments for why a MaterialXTrace module providing instrumented build support might be a really good idea.

Would MaterialXTrace allow us to integrate an instrumented run of MaterialXTest into the GitHub CI for MaterialX, with the instrumented build support providing consistent profile results from run to run, independent of the actual time each run of MaterialXTest took on the GitHub CI virtual machine?

That would be a really compelling argument, if true, and it's something that a sampling profiler couldn't hope to provide, as the distribution of time samples are profoundly dependent on the performance of the virtual machines on which our GitHub CI workflows are run.

ppenenko · 2026-01-14T22:03:17Z

@jstone-lucasfilm Perfetto tracing is completely orthogonal to how a VM's configuration and load affect timings - it just records wall-clock times, so unfortunately it wouldn't improve on that. When testing on the same machine and avoiding heavy parallel loads (e.g. running Maya in parallel), the timings should be reliable. E.g. I can measure the expected speedups of @ld-kerley 's #2499 reliably.

But of course, we could record traces in CI/CD. At the very least, these would give us a kind of a rich log, with meaningful events stacked and grouped by thread. We can be sure, for example, that this or that shader graph optimization pass has been applied to the given material. And optimization passes #2499 should show similar relative improvements across different configurations.

A related use case would be if a user experiences performance issues with MaterialX - they can easily record a capture and share it with the maintainers. And, as I mentioned, it could one day be a USD trace including MaterialX events.

jstone-lucasfilm · 2026-01-14T23:19:59Z

It does sound interesting to integrate MaterialXTrace into our GitHub CI in the future, even if it doesn't produce perfectly consistent results between runs.

It seems slightly surprising that you would want to use Perfetto to measure GPU timing improvements from shader generation optimizations, e.g. the hardware shader optimizations found in #2499.

Am I wrong to think that this category of optimization would normally be evaluated with either RenderDoc or a real-time, smoothed frame timer like the one we use in MaterialXView?

ppenenko · 2026-01-15T15:32:42Z

@jstone-lucasfilm could we please separate the concerns in this code review a bit?

First of all, can we all agree that a tracing mechanism would be an essential addition to MaterialX? I stated the motivations above, and the most immediate and straightforward one is to to measure how long a particular operation took for a particular MaterialX entity - material, node, shader - which is not identified uniquely by a C++ symbol, and therefore can't be captured by a sampling profiler. Let's set GPU timings aside for a moment, because there are a few types of CPU events that we care about in the context of shader graph optimizations: shader codegen timings and shader compilation timings. So even if we disagree on GPU profiling, I would argue that such a mechanism is a must-have. Chrome and USD corroborate this argument.

If we do agree on the above, let's discuss if Perfetto is the right implementation choice. I would argue that it is, due to its exceptional maturity and widespread adoption.

As for GPU instrumentation - my main argument is that if we have a tracing mechanism anyway, for all the other reasons, recording GPU timings there is simple and convenient. Taking the frame duration with OpenGL queries is about a dozen lines of C++, and then the result can be recorded via Perfetto.

As for Renderdoc - it's not well-suited for recording the durations of hundreds of frames because:

Its number one use case is debugging and profiling a single frame.
It records complete graphics API (e.g. OpenGL) call traces and GPU resources, for every frame - something we don't need for our kind of test and something that would amount to huge amounts of data across hundreds of frames.
Its main use case if frame debugging, not frame profiling. For profiling, GPU hardware-specific tools (Nsight etc.) are more useful but they're even less cross-platform.
GPU frame debuggers/profilers in general are known for compatibility issues across platforms, graphics APIs and application usage patterns.
For measuring the duration of a frame or a draw call, Renderdoc would use the same graphics API calls that we can use - it doesn't have special hooks into the driver, unlike HW vendor tools. So our measurements can be as precise.

Now, regarding MaterialXView.

It can only measure one material at a time.
For some reason, the reported frame duration is truncated to integer milliseconds. E.g. 1.9f would be truncated to 1.
It doesn't measure GPU durations. It also doesn't seem to do glFinish or glFlush, so even CPU frame durations are questionable. The only CPU/GPU synchronization it seems to have is spamming the video driver with frames until it starts blocking.
It does do averaging, but we don't have to do it at run time. With a recorded trace, we can examine multiple events per material after the fact, either in a GUI or with Python. Perfetto UI can do all sorts of statistic analyses, and a Python script can bring the data into Pandas and Matplotlib. Having the complete data offline makes it possible to analyze distributions as well - e.g. when the first frame per material is much longer due to shader compilation.
Running an interactive app and jotting down a single milliseconds value is less reproducible and shareable than running a test suite which records timings in nanosecond precision. The file that can be shared with others, the test suite can be run by others.

Perfetto SDK generates warnings that fail builds when MATERIALX_WARNINGS_AS_ERRORS is ON. Add -Wno-error for perfetto.cc on GCC/Clang.

- Suppress warnings-as-errors for Perfetto SDK on Unix (GCC/Clang generate warnings that fail builds with MATERIALX_WARNINGS_AS_ERRORS) - Skip pthread linking on iOS (threads are built-in to iOS SDK)

COMPILE_OPTIONS is a target property. For set_source_files_properties, use COMPILE_FLAGS instead. This fixes /bigobj on Windows and -Wno-error on Unix.

- Define PERFETTO_COMPONENT_EXPORT for shared libs (required by Perfetto) - Add -fvisibility=default for perfetto.cc on Unix (fixes GCC 10 monolithic build)

- Add createPerfettoSink() factory to Tracing.h (exported) - PerfettoSink class in PerfettoSink.h not exported (internal header) - Consumers include only Tracing.h and use factory function - Perfetto types never cross DLL boundaries - only abstract Sink does - Remove unnecessary PERFETTO_COMPONENT_EXPORT from CMakeLists.txt

- Define MATERIALX_PERFETTO_COMPILE_DEFINITIONS and MATERIALX_PERFETTO_COMPILE_FLAGS as CACHE INTERNAL variables in root CMakeLists.txt - Apply flags in both root (for monolithic builds) and MaterialXTrace (for non-monolithic) - set_source_files_properties is directory-scoped, so must be called in both places - Fixes -Werror=shadow on GCC (kDevNull shadowing) - Fixes min/max macro conflicts on Windows (NOMINMAX)

set_source_files_properties is directory-scoped, so: - Root CMakeLists.txt: defines MATERIALX_PERFETTO_* variables - source/CMakeLists.txt: applies flags for monolithic builds - MaterialXTrace/CMakeLists.txt: applies flags for non-monolithic builds

perfetto.cc is ~160k lines and generates gcov output that gcovr cannot parse. Exclude it from coverage since it's third-party code anyway.

…C warnings - Add --exclude .*perfetto.* to gcovr (coverage) - perfetto.cc is ~160k lines and generates gcov output that gcovr cannot parse - Add --suppress=*:*perfetto* to cppcheck (static analysis) - cppcheck doesn't define OS macros needed by Perfetto SDK's platform detection - Use /W0 to disable all warnings for Perfetto SDK on MSVC (third-party code triggers C4146, C4369, C4996, C4459, C4065, C4244, C4267, C4293)

/W0 alone doesn't override project-level /WX. Need /WX- explicitly to prevent STL header warnings (from tuple, etc.) being promoted to errors when compiling perfetto.cc.

Use recursive glob build/**/*.perfetto-trace since traces are written to current working directory (build/) not build/bin/

- Set up Perfetto sink in ShaderGeneratorTester::validate() when enableTracing=true - Add MX_TRACE_SCOPE around generateCode() calls with element names - Generates <target>_gen_trace.perfetto-trace files (e.g. genglsl_gen_trace.perfetto-trace) - These tests run on all CI platforms, providing trace artifacts for download

.github/workflows/main.yml

source/MaterialXTrace/Tracing.h

ppenenko · 2026-01-16T21:48:02Z

Refactoring done - MaterialXTrace is a separate module. GLSL render tests aren't enabled in CI/CD, so I added instrumentation in codegen tests. An extended build with trace artifacts can be found at https://github.com/autodesk-forks/MaterialX/actions/runs/21080475833/job/60632726674 A Windows step is still running, taking a while to install the MDL SDK, but otherwise it looks good.

ppenenko · 2026-01-16T22:33:30Z

FYI @jstone-lucasfilm https://github.com/autodesk-forks/MaterialX/actions/runs/21080475833/ is green except for JavaScript which always fails on forks, and the traces are downloadable as artifacts.

When outputDirectory is specified and shaderInterfaces=REDUCED, the render tests were failing to create the parent material directory before attempting to create the /reduced subdirectory, causing shader dumps to fail. The fix ensures createDirectory() is called on the parent outputPath first, then on outputPath/reduced if in REDUCED mode. Both calls are now within the same ScopedTimer scope for consistent profiling. Fixed in all four render test implementations: - RenderGlsl.cpp - RenderOsl.cpp - RenderMsl.mm - RenderSlang.cpp

jstone-lucasfilm

Following up on our last MaterialX TSC meeting, it's clear that we should move forward with this new work, so I've started writing up more detailed recommendations for improving it.

source/MaterialXTest/MaterialXGenShader/GenShaderUtil.h

source/MaterialXTest/MaterialXRenderGlsl/RenderGlsl.cpp

CMakeLists.txt

.github/workflows/main.yml

Address review: remove `using Cat` alias and spell out the full mx::Tracing::Category names for clarity while the Tracing library is still new.

Address review: use a Perfetto-specific flag name to leave a clear path for future extensions to Tracy and other profiling backends.

Address review: instead of enabling tracing in all extended builds, add a matrix.extended_build_perfetto flag and set it on one non-Windows build to produce a single clear tracing artifact.

Only attempt to upload trace artifacts from the build that actually has Perfetto enabled, avoiding no-op upload steps in other builds.

.github/workflows/main.yml

jstone-lucasfilm

This looks great to me, @ppenenko, and thanks for the contribution to MaterialX! Once we start seeing the new tracing artifacts in nightly builds, we can augment this with additional improvements.

ppenenko added 8 commits January 8, 2026 16:27

Exclude MxTrace.cpp when tracing disabled (zero overhead)

c147aaf

Print output directory at end of test run for easy access

940cafb

When outputDirectory is set, print the path at the end of test stdout. This makes it clickable in terminals like Cursor/VS Code for quick access.

ppenenko force-pushed the ppenenko/perfetto_and_output_dir branch from 36ae774 to fb056e3 Compare January 8, 2026 21:52

ppenenko added 8 commits January 9, 2026 17:18

Add clarifying comments for Perfetto SDK integration

1cb1b4e

- Explain amalgamated source compilation is Google's official recommended approach per https://perfetto.dev/docs/instrumentation/tracing-sdk - Document ws2_32 dependency (Windows Sockets 2 for Perfetto IPC)

Add Dispatcher::ShutdownGuard nested struct

6e1c923

Move the scope guard pattern into the Dispatcher class for reusability. Callers can now use mx::Tracing::Dispatcher::ShutdownGuard instead of defining their own local struct.

Add category dispatch to PerfettoSink::counter()

dc10eb6

Remove unused resolveOutputPathWithSubdir method

4633341

ppenenko marked this pull request as ready for review January 12, 2026 20:44

jstone-lucasfilm reviewed Jan 12, 2026

View reviewed changes

source/MaterialXCore/PerfettoSink.cpp Outdated Show resolved Hide resolved

ppenenko added 9 commits January 16, 2026 09:42

Suppress warnings-as-errors for Perfetto SDK on Unix

baa407d

Perfetto SDK generates warnings that fail builds when MATERIALX_WARNINGS_AS_ERRORS is ON. Add -Wno-error for perfetto.cc on GCC/Clang.

Fix tracing build on GCC/Clang and iOS

49e3ae2

- Suppress warnings-as-errors for Perfetto SDK on Unix (GCC/Clang generate warnings that fail builds with MATERIALX_WARNINGS_AS_ERRORS) - Skip pthread linking on iOS (threads are built-in to iOS SDK)

Fix CMake: use COMPILE_FLAGS instead of COMPILE_OPTIONS for source files

2bd7203

COMPILE_OPTIONS is a target property. For set_source_files_properties, use COMPILE_FLAGS instead. This fixes /bigobj on Windows and -Wno-error on Unix.

Fix Perfetto symbol visibility for shared library builds

4dba1fd

- Define PERFETTO_COMPONENT_EXPORT for shared libs (required by Perfetto) - Add -fvisibility=default for perfetto.cc on Unix (fixes GCC 10 monolithic build)

Exclude Perfetto SDK from coverage analysis

fce8654

perfetto.cc is ~160k lines and generates gcov output that gcovr cannot parse. Exclude it from coverage since it's third-party code anyway.

ppenenko force-pushed the ppenenko/perfetto_and_output_dir branch from e20b517 to 9db6ef1 Compare January 16, 2026 19:30

ppenenko added 3 commits January 16, 2026 14:42

Add /WX- to disable warnings-as-errors for Perfetto SDK on MSVC

41fe787

/W0 alone doesn't override project-level /WX. Need /WX- explicitly to prevent STL header warnings (from tuple, etc.) being promoted to errors when compiling perfetto.cc.

Fix Perfetto trace artifact upload path

7367222

Use recursive glob build/**/*.perfetto-trace since traces are written to current working directory (build/) not build/bin/

ppenenko commented Jan 16, 2026

View reviewed changes

.github/workflows/main.yml Show resolved Hide resolved

ppenenko commented Jan 16, 2026

View reviewed changes

source/MaterialXTrace/Tracing.h Show resolved Hide resolved

ppenenko and others added 3 commits January 22, 2026 16:14

Merge branch 'main' into ppenenko/perfetto_and_output_dir

6a46204

Merge branch 'main' into ppenenko/perfetto_and_output_dir

31a6921

jstone-lucasfilm reviewed Feb 12, 2026

View reviewed changes

source/MaterialXTest/MaterialXGenShader/GenShaderUtil.h Show resolved Hide resolved

source/MaterialXTest/MaterialXRenderGlsl/RenderGlsl.cpp Outdated Show resolved Hide resolved

CMakeLists.txt Outdated Show resolved Hide resolved

.github/workflows/main.yml Outdated Show resolved Hide resolved

ppenenko added 4 commits February 12, 2026 16:10

Use fully qualified mx::Tracing::Category in RenderGlsl.cpp

8af946e

Address review: remove `using Cat` alias and spell out the full mx::Tracing::Category names for clarity while the Tracing library is still new.

Rename MATERIALX_BUILD_TRACING to MATERIALX_BUILD_PERFETTO_TRACING

742a011

Address review: use a Perfetto-specific flag name to leave a clear path for future extensions to Tracy and other profiling backends.

Enable Perfetto tracing in a single CI build (Linux GCC 14)

e2ad867

Address review: instead of enabling tracing in all extended builds, add a matrix.extended_build_perfetto flag and set it on one non-Windows build to produce a single clear tracing artifact.

Gate Perfetto trace upload on matrix.extended_build_perfetto

e098349

Only attempt to upload trace artifacts from the build that actually has Perfetto enabled, avoiding no-op upload steps in other builds.

ppenenko commented Feb 12, 2026

View reviewed changes

.github/workflows/main.yml Show resolved Hide resolved

Merge branch 'main' into ppenenko/perfetto_and_output_dir

2876b06

jstone-lucasfilm approved these changes Feb 12, 2026

View reviewed changes

jstone-lucasfilm merged commit 0a1b924 into AcademySoftwareFoundation:main Feb 12, 2026
33 checks passed

ppenenko deleted the ppenenko/perfetto_and_output_dir branch February 12, 2026 22:16

Add Perfetto tracing and a test output directory option #2742

Add Perfetto tracing and a test output directory option #2742

Uh oh!

Conversation

ppenenko commented Jan 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Background and motivation

Features

1. Perfetto Tracing (MATERIALX_BUILD_TRACING)

2. Test Output Directory (outputDirectory in _options.mtlx)

3. Runtime Tracing Toggle (enableTracing in _options.mtlx)

Usage

Enable Tracing (Build Time)

Enable Tracing (Runtime)

Configure Output Directory

Analyze Traces

Related

Uh oh!

Uh oh!

jstone-lucasfilm commented Jan 13, 2026

Uh oh!

ashwinbhat commented Jan 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jstone-lucasfilm commented Jan 14, 2026

Uh oh!

ppenenko commented Jan 14, 2026

Uh oh!

ppenenko commented Jan 14, 2026

Uh oh!

ppenenko commented Jan 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ppenenko commented Jan 14, 2026

Uh oh!

jstone-lucasfilm commented Jan 14, 2026

Uh oh!

ppenenko commented Jan 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jstone-lucasfilm commented Jan 14, 2026

Uh oh!

ppenenko commented Jan 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

ppenenko commented Jan 16, 2026

Uh oh!

ppenenko commented Jan 16, 2026

Uh oh!

jstone-lucasfilm left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

jstone-lucasfilm left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

ppenenko commented Jan 8, 2026 •

edited

Loading

1. Perfetto Tracing (`MATERIALX_BUILD_TRACING`)

2. Test Output Directory (`outputDirectory` in `_options.mtlx`)

3. Runtime Tracing Toggle (`enableTracing` in `_options.mtlx`)

ashwinbhat commented Jan 14, 2026 •

edited

Loading

ppenenko commented Jan 14, 2026 •

edited

Loading

ppenenko commented Jan 14, 2026 •

edited

Loading

ppenenko commented Jan 15, 2026 •

edited

Loading