RFC: how to integrate Tracy (and other custom tracing) for tracing marl

[benvanik]

Tracy is an absolutely fantastic tracing tool that we've recently fallen in love with. To be able to fully understand how marl is behaving with the rest of our application we need to integrate it with marl's trace.h.

Ideally instead of embedding Tracy events directly into marl we could make trace.h able to be extended by the integrator of marl itself. In header-only libraries this is generally done by allowing overrides (such as with the Vulkan Memory Allocator: https://github.com/google/iree/blob/master/iree/hal/vulkan/internal_vk_mem_alloc.cc#L28-L66), however overriding MARL_SCOPED_EVENT/etc is difficult without making direct changes as the macros are required during marl compilation.

The approach dear imgui takes is compatible in that it allows either include-path based overriding or completely custom path overriding by way of defines:
https://github.com/ocornut/imgui/blob/master/imgui.h#L40-L46

This would allow an integrator, for example, to have their own trace.h or trace-impl.h that defines the MARL_* tracing macros that will be used when building marl, overriding the current chrome tracing-based implementation.

Thoughts? Would you be open to a PR adding an optional MARL_USER_TRACE_H check?

[ben-clayton]

Hi Ben,

We can consider the existing trace logic entirely replaceable. The chrome trace format's greatest strengths are that you don't need to install a viewer (as most have chrome installed already) and that the file format is implementable in a few hundred lines of code. That said, the viewer seems to implode after a few hundred-thousand events, making it near impossible to use for modest trace lengths. This limitation has meant I haven't actually enabled the trace logic in some time, and has probably bit rotted.

Tracy looks great, and I have no objections to integrating with it - so long as it is an optional extra (I'd like to keep the marl core zero-dependency).

There's also perfetto which is getting a lot of love right now. Last time I looked, integration looked more complex than I had time for.

So yes, I think it would be great to support multiple trace backends, and I don't overly care to keep the existing chrome trace output.

I wonder if there's a way to abstract the trace backend and runtime enable / disable tracing without adding an unacceptable amount of overhead.

Cheers,
Ben

[AWoloszyn]

For Tracy specifically. It probably makes sense to wait for fiber support (which is apparently in the works).
(see: wolfpld/tracy#106)