[Mesa-dev] Perfetto CPU/GPU tracing

Rob Clark robdclark at gmail.com
Sat Feb 13 22:47:16 UTC 2021


On Sat, Feb 13, 2021 at 12:52 PM Lionel Landwerlin
<lionel.g.landwerlin at intel.com> wrote:
>
> On 13/02/2021 18:52, Rob Clark wrote:
> > On Sat, Feb 13, 2021 at 12:04 AM Lionel Landwerlin
> > <lionel.g.landwerlin at intel.com> wrote:
> >> On 13/02/2021 04:20, Rob Clark wrote:
> >>> On Fri, Feb 12, 2021 at 5:56 PM Lionel Landwerlin
> >>> <lionel.g.landwerlin at intel.com> wrote:
> >>>> On 13/02/2021 03:38, Rob Clark wrote:
> >>>>> On Fri, Feb 12, 2021 at 5:08 PM Lionel Landwerlin
> >>>>> <lionel.g.landwerlin at intel.com> wrote:
> >>>>>> We're kind of in the same boat for Intel.
> >>>>>>
> >>>>>> Access to GPU perf counters is exclusive to a single process if you want
> >>>>>> to build a timeline of the work (because preemption etc...).
> >>>>> ugg, does that mean extensions like AMD_performance_monitor doesn't
> >>>>> actually work on intel?
> >>>> It work,s but only a single app can use it at a time.
> >>>>
> >>> I see.. on the freedreno side we haven't really gone down the
> >>> preemption route yet, but we have a way to hook in some safe/restore
> >>> cmdstream
> >>
> >> That's why I think, for Intel HW, something like gfx-pps is probably
> >> best to pull out all the data on a timeline for the entire system.
> >>
> >> Then the drivers could just provide timestamp on the timeline to
> >> annotate it.
> >>
> > Looking at gfx-pps, my question is why is this not part of the mesa
> > tree?  That way I could use it for freedreno (either as stand-alone
> > process or part of driver) without duplicating all the perfcntr
> > tables, and information about different variants of a given generation
> > needed to interpret the raw counters into something useful for a
> > human.
> >
> > Pulling gfx-pps into mesa seems like a sensible way forward.
> >
> > BR,
> > -R
>
> Yeah, I guess it depends on how your stack looks.
>
> If the counters cover more than 3d and you have video drivers out of the
> mesa tree, it might make sense to have it somewhere else.

Pulling intel video drivers into mesa and bringing some sanity to that
side of things would make more than a few people happy (but I digress
;-))

Until then, exporting a library from the mesa build might be an
option?  And possibly something like that would work for virgl host
side stuff as well?

> Anyway I didn't want to sound negative, having a daemon like gfx-pps
> thing in mesa to report system wide counters works for me :)

yeah, I think having it in the mesa tree is good for code-reuse (from
my experience, pulling external freedreno related tools into mesa
turned out to be a good thing)

At some point, whether the collection is in-process or not could just
be an implementation detail

BR,
-R

> Then we can look into how to have each intel driver add annotation on
> the timeline.
>
>
> -Lionel
>


More information about the mesa-dev mailing list