[Mesa-dev] Perfetto CPU/GPU tracing

Tamminen, Eero T eero.t.tamminen at intel.com
Mon Feb 15 11:13:44 UTC 2021


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
- where the bottlenecks are on GPU side
- where the bottlenecks are on CPU side
- what are the sync points

- 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

More information about the mesa-dev mailing list