<div dir="ltr"><div>(responding from correct address this time)</div><div><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Feb 12, 2021 at 12:03 PM Mark Janes <<a href="mailto:mark.a.janes@intel.com">mark.a.janes@intel.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I've recently been using GPUVis to look at trace events.  On Intel<br>
platforms, GPUVis incorporates ftrace events from the i915 driver,<br>
performance metrics from igt-gpu-tools, and userspace ftrace markers<br>
that I locally hack up in Mesa.<br></blockquote><div><br></div><div>GPUVis is great. I would love to see that data combined with userspace events without any need for local hacks. Perfetto provides on-demand trace events with lower overhead compared to ftrace, so for example it is acceptable to have production trace instrumentation that can be captured without dev builds. To do that with ftrace it may require a way to enable and disable the ftrace file writes to avoid the overhead when tracing is not in use. This is what Android does with systrace/atrace, for example, it uses Binder to notify processes about trace sessions. Perfetto does that in a more portable way.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
It is very easy to compile the GPUVis UI.  Userspace instrumentation<br>
requires a single C/C++ header.  You don't have to access an external<br>
web service to analyze trace data (a big no-no for devs working on<br>
preproduction hardware).<br>
<br>
Is it possible to build and run the Perfetto UI locally?</blockquote><div><br></div><div>Yes, <a href="https://github.com/google/perfetto/blob/5ff758df67da94d17734c2e70eb6738c4902953e/ui/README.md" target="_blank">local UI builds are possible</a>. Also confirmed with the <a href="https://discord.gg/35ShE3A" target="_blank">perfetto team</a> that trace data is not uploaded unless you use the 'share' feature.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">  Can it display<br>
arbitrary trace events that are written to<br>
/sys/kernel/tracing/trace_marker ? </blockquote><div><br></div><div>Yes, I believe it does support that via <a href="https://perfetto.dev/docs/quickstart/linux-tracing" target="_blank">linux.ftrace data source</a>. We use that for example to overlay CPU sched data to show what process is on each core throughout the timeline. There are <a href="https://github.com/google/perfetto/tree/5ff758df67da94d17734c2e70eb6738c4902953e/protos/perfetto/trace/ftrace" target="_blank">many ftrace event types</a> in the perfetto protos.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Can it be extended to show i915 and<br>
i915-perf-recorder events?<br></blockquote><div><br></div><div>It can be extended to consume custom data sources. One way this is done is via a bridge daemon, such as traced_probes which is responsible for capturing data from ftrace and /proc during a trace session and sending it to traced. traced is the main perfetto tracing daemon that notifies all trace data sources to start/stop tracing and communicates with user tracing requests via the 'perfetto' command.</div><div class="gmail-yj6qo gmail-ajU" style="outline:none;padding:10px 0px;width:22px;margin:2px 0px 0px"><br class="gmail-Apple-interchange-newline"></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
John Bates <<a href="mailto:jbates@chromium.org" target="_blank">jbates@chromium.org</a>> writes:<br>
<br>
> I recently opened issue 4262<br>
> <<a href="https://gitlab.freedesktop.org/mesa/mesa/-/issues/4262" rel="noreferrer" target="_blank">https://gitlab.freedesktop.org/mesa/mesa/-/issues/4262</a>> to begin the<br>
> discussion on integrating perfetto into mesa.<br>
><br>
> *Background*<br>
><br>
> System-wide tracing is an invaluable tool for developers to find and fix<br>
> performance problems. The perfetto project enables a combined view of trace<br>
> data from kernel ftrace, GPU driver and various manually-instrumented<br>
> tracepoints throughout the application and system. This helps developers<br>
> quickly answer questions like:<br>
><br>
>    - How long are frames taking?<br>
>    - What caused a particular frame drop?<br>
>    - Is it CPU bound or GPU bound?<br>
>    - Did a CPU core frequency drop cause something to go slower than usual?<br>
>    - Is something else running that is stealing CPU or GPU time? Could I<br>
>    fix that with better thread/context priorities?<br>
>    - Are all CPU cores being used effectively? Do I need sched_setaffinity<br>
>    to keep my thread on a big or little core?<br>
>    - What’s the latency between CPU frame submit and GPU start?<br>
><br>
> *What Does Mesa + Perfetto Provide?*<br>
><br>
> Mesa is in a unique position to produce GPU trace data for several GPU<br>
> vendors without requiring the developer to build and install additional<br>
> tools like gfx-pps <<a href="https://gitlab.freedesktop.org/Fahien/gfx-pps" rel="noreferrer" target="_blank">https://gitlab.freedesktop.org/Fahien/gfx-pps</a>>.<br>
><br>
> The key is making it easy for developers to use. Ideally, perfetto is<br>
> eventually available by default in mesa so that if your system has perfetto<br>
> traced running, you just need to run perfetto (perhaps along with setting<br>
> an environment variable) with the mesa categories to see:<br>
><br>
>    - GPU processing timeline events.<br>
>    - GPU counters.<br>
>    - CPU events for potentially slow functions in mesa like shader compiles.<br>
><br>
> Example of what this data might look like (with fake GPU events):<br>
> [image: percetto-gpu-example.png]<br>
><br>
> *Runtime Characteristics*<br>
><br>
>    - ~500KB additional binary size. Even with using only the basic features<br>
>    of perfetto, it will increase the binary size of mesa by about 500KB.<br>
>    - Background thread. Perfetto uses a background thread for communication<br>
>    with the system tracing daemon (traced) to advertise trace data and get<br>
>    notification of trace start/stop.<br>
>    - Runtime overhead when disabled is designed to be optimal with one<br>
>    predicted branch, typically a few CPU cycles<br>
>    <<a href="https://perfetto.dev/docs/instrumentation/track-events#performance" rel="noreferrer" target="_blank">https://perfetto.dev/docs/instrumentation/track-events#performance</a>> per<br>
>    event. While enabled, the overhead can be around 1 us per event.<br>
><br>
> *Integration Challenges*<br>
><br>
>    - The perfetto SDK is C++ and designed around macros, lambdas, inline<br>
>    templates, etc. There are ongoing discussions on providing an official<br>
>    perfetto C API, but it is not yet clear when this will land on the perfetto<br>
>    roadmap.<br>
>    - The perfetto SDK is an amalgamated .h and .cc that adds up to 100K<br>
>    lines of code.<br>
>    - Anything that includes perfetto.h takes a long time to compile.<br>
>    - The current Perfetto SDK design is incompatible with being a shared<br>
>    library behind a C API.<br>
><br>
> *Percetto*<br>
><br>
> The percetto library <<a href="https://github.com/olvaffe/percetto" rel="noreferrer" target="_blank">https://github.com/olvaffe/percetto</a>> was recently<br>
> implemented to provide an interim C API for perfetto. It provides efficient<br>
> support for scoped trace events, multiple categories, counters, custom<br>
> timestamps, and debug data annotations. Percetto also provides some<br>
> features that are important to mesa, but not available yet with perfetto<br>
> SDK:<br>
><br>
>    - Trace events from multiple perfetto instances in separate shared<br>
>    libraries (like mesa and virglrenderer) show correctly in a single process<br>
>    and thread view.<br>
>    - Counter tracks and macro API.<br>
><br>
> Percetto is missing API for perfetto's GPU DataSource and counter support,<br>
> but that feature could be implemented next if it is important for mesa.<br>
> With the existing percetto API mesa could present GPU trace data as named<br>
> 'slice' events and int64_t counters with custom timestamps as shown in the<br>
> image above (based on this sample<br>
> <<a href="https://github.com/olvaffe/percetto/blob/main/examples/timestamps.c" rel="noreferrer" target="_blank">https://github.com/olvaffe/percetto/blob/main/examples/timestamps.c</a>>).<br>
><br>
> *Mesa Integration Alternatives*<br>
><br>
> Note: we have some pressing needs for performance analysis in Chrome OS, so<br>
> I'm intentionally leaving out the alternative of waiting for an official<br>
> perfetto C API. Of course, once that C API is available it would become an<br>
> option to migrate to it from any of the alternatives below.<br>
><br>
> Ordered by difficulty with easiest first:<br>
><br>
>    1. Statically link with percetto as an optional external dependency<br>
> (virglrenderer<br>
>    now has this approach<br>
>    <<a href="https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/480" rel="noreferrer" target="_blank">https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/480</a>><br>
>    ).<br>
>    - Pros: API already supports most common tracing needs. Tested and used<br>
>       by an increasing number of CrOS components.<br>
>       - Cons: External dependency for optional mesa build option.<br>
>    2. Embed Perfetto SDK + a Percetto fork/copy.<br>
>       - Pros: API already supports most common tracing needs. No added<br>
>       external dependency for mesa.<br>
>       - Cons: Percetto code divergence, bug fixes need to land in two trees.<br>
>    3. Embed Perfetto SDK + custom C wrapper.<br>
>       - Pros: Tailored API for mesa's needs.<br>
>       - Cons: Nontrivial development efforts and maintenance.<br>
>    4. Generate C stubs for the Perfetto protobuf and reimplement the<br>
>    Perfetto SDK in C.<br>
>       - Pros: Tailored API for mesa's needs. Possible smaller binary impact<br>
>       from simpler implementation.<br>
>       - Cons: Significant development efforts and maintenance.<br>
><br>
> Regardless of the integration direction, I expect we would disable perfetto<br>
> in the default build for now to minimize disruption.<br>
><br>
> I like #1, because there are some nontrivial subtleties to the C wrapper<br>
> that provide both API conveniences and runtime performance that would need<br>
> to be reimplemented or maintained with the other options. I will also<br>
> volunteer to do #1 or #2, but I'm not sure I have time for #3 or #4 :D.<br>
><br>
> Any other thoughts on how best to integrate perfetto into mesa?<br>
><br>
> -jb<br>
> _______________________________________________<br>
> mesa-dev mailing list<br>
> <a href="mailto:mesa-dev@lists.freedesktop.org" target="_blank">mesa-dev@lists.freedesktop.org</a><br>
> <a href="https://lists.freedesktop.org/mailman/listinfo/mesa-dev" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/mesa-dev</a><br>
</blockquote></div></div>