[Mesa-dev] Perfetto CPU/GPU tracing

[John Bates]

I can vouch for the usefulness of the combined trace timeline showing CPU
core usage, filtered application events and GPU usage. Android systrace
shows this data -- I've used it from both an app developer perspective to
fix countless performance bugs and from a whole-system perspective to tune
issues such as motopho latency for VR. The latter is only possible when the
CPU timeline is combined with vendor-specific GPU data showing binning,
resolves/unresolves and context preemptions.

With virtualization, we have a new level of complexity and corresponding
performance bugs to track down. One example is unexpected shader compiles,
but there are other slowpaths in mesa that are important to be able to see
without difficulty. There is work being done to support perfetto trace data
from both host and guest VM -- mesa is in both.

Perfetto/systrace makes this performance analysis work easier in many cases
-- run an app, record trace, reproduce a glitch, and then view the trace to
find out what happened.

On Mon, Feb 15, 2021 at 9:27 AM Rob Clark <robdclark at gmail.com> wrote:

> On Mon, Feb 15, 2021 at 3:13 AM Tamminen, Eero T
> <eero.t.tamminen at intel.com> wrote:
> >
> > Hi,
> >
> > On Fri, 2021-02-12 at 18:20 -0800, Rob Clark wrote:
> > > On Fri, Feb 12, 2021 at 5:56 PM Lionel Landwerlin
> > > <lionel.g.landwerlin at intel.com> wrote:
> > ...
> > > > In our implementation that precision (in particular when a drawcall
> > > > ends) comes at a stalling cost unfortunately.
> > >
> > > yeah, stalling on our end too for per-draw counter snapshots.. but if
> > > you are looking for which shaders to optimize that doesn't matter
> > > *that* much.. they'll be some overhead, but it's not really going to
> > > change which draws/shaders are expensive.. just mean that you lose out
> > > on pipelining of the state changes
> >
> > I don't think it makes sense to try doing this all in one step.
> >
> > Unless one has resources of Google + commitment for maintaining it, I
> > think doing those steps with separate, dedicated tools can be better fit
> > for Open Source than trying to maintain a monster that tries to do
> > everything of analyzing:
> > - whether performance issue is on GPU side, CPU side, or code being too
> > synchronous
> > - where the bottlenecks are on GPU side
> > - where the bottlenecks are on CPU side
> > - what are the sync points
>
> I mean, google has a team working on perfetto, so we kinda are getting
> the tool here for free, all we need to do here is instrumentation for
> the mesa part of the system..
>
> Currently, if you look at
> https://chromeos.dev/en/games/optimizing-games-profiling the
> recommendation basically amounts to "optimize on android with
> snapdragon profiler/etc".. which is really not a great look for mesa.
> (And doesn't do anything for intel at all.)  Mesa is a great project,
> but profiling tooling, especially something for people other than mesa
> developers, is a glaring weakness.  Perfetto looks like a great
> opportunity to fix that, not only for ourselves but also game
> developers and others.
>
> BR,
> -R
>
> > IMHO:
> > - Overall picture should not have too many details, because otherwise
> > one can start chasing irrelevancies [1]
> > - Rest of analysis works better when one concentrate on one performance
> > aspect (shown by the overall picture) at the time.  So that activity
> > could have tool dedicated for that purpose
> >
> >
> >         - Eero
> >
> > [1] Unless one has HW assisted tool that really can tell *everything*
> > like ARM ETM and Intel PT with *really good* post-processing &
> > visualization tooling.  I don't think are usable outside of large
> > companies though because of HW requirements and using them taking a lot
> > of time / expertise (1 sec trace is gigs of data).
> >
> > PS. For checking on shader compiles, I've used two steps:
> > * script to trace frame updates & shader compiles (with ftrace uprobe on
> > appropriate function entry points) + monitor CPU usage & GPU usage (for
> > GPU, freq or power usage is enough)
> >   -> shows whether FPS & GPU utilization dip with compiles.  Frame
> > updates & compiles are rare enough that ftrace overhead doesn't matter
> >
> > * enable Mesa shader debugging, because in next step one wants to know
> > what shaders they are and how they're compiled
> >
> > _______________________________________________
> > mesa-dev mailing list
> > mesa-dev at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20210215/17fa0f70/attachment.htm>