Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
benvanik opened this issue May 19, 2020 · 2 comments
Open

Comments

@benvanik
Copy link

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
Copy link
Contributor

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
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants