Re: [PATCH 01/13] drm/msm: Remove obsolete perf infrastructure

[Rob Clark]

On Tue, Apr 21, 2026 at 8:39 AM Dmitry Baryshkov
<dmitry.baryshkov@xxxxxxxxxxxxxxxx> wrote:
>
> On Tue, Apr 21, 2026 at 06:07:20AM -0700, Rob Clark wrote:
> > On Mon, Apr 20, 2026 at 4:49 PM Dmitry Baryshkov
> > <dmitry.baryshkov@xxxxxxxxxxxxxxxx> wrote:
> > >
> > > On Mon, Apr 20, 2026 at 03:25:23PM -0700, Rob Clark wrote:
> > > > Outside of a3xx, this was never really used.  And it low-key gets in the
> > > > way of the new perfcntr support (or at least it is confusing to have two
> > > > things called "perf").  So lets remove it.
> > > >
> > > > This drops the "perf" debugfs file.  But these days, nvtop is a better
> > > > option.  (Plus perfetto for newer gens.)
> > >
> > > Would it be possible to resurrect "perf" later? It was really useful.
> >
> > Nothing is impossible.. but I was having trouble naming things with
> > both old and new perf stuff in parallel.
>
> That why I wrote about resurrecting it later, once the new stuff is in.
>
> BTW: do you plan to get perf counters for a3xx-a5xx back? I remember
> that there was some issue with a2xx ABI.

So current state on userspace side is that only a3xx/a4xx are missing
perfcntr support..  although it looks like we know the countable
enums, so probably not hard[*]

In all cases, the existing userspace-only support will continue to
work.  The main reasons I omitted a2xx/a5xx on the kernel side are:

a) Not really sure how to do the Makefile bits.. since they wouldn't
be using a6xx.xml.  In meson I can use a table (2d-array):
    https://gitlab.freedesktop.org/robclark/mesa/-/blob/fd/generate-perfcntrs/src/freedreno/registers/adreno/meson.build?ref_type=heads#L20
b) No good setup to test
c) They don't have IFPC

They could ofc be added later.  The main urgency is a8xx, since I
don't want to add mesa perfcntr support without PERFCNTR_CONFIG (so
that we don't have an older-userspace, new-kernel permutation on
a8xx+).

I don't remember about a2xx ABI issue.. but a2xx perfcntr stuff was
added after I was already busy with later gens.

BR,
-R

[*] there are some counter groups that had some slightly different
config programming, like separate clear/enable regs.. which I haven't
dealt with yet.  For a6xx+ this only matters for some counter groups
(VBIF/GBIF, maybe GMU?) that userspace doesn't care as much about.
Idk if that was true for the earlier gens.  Eventually I'll add a6xx+
support for these counters, but there are a few other things to deal
with first.

> > Is it really adding value
> > over nvtop?
>
> --
> With best wishes
> Dmitry