[Mesa-dev] Perfetto CPU/GPU tracing

[Rob Clark]

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