[Intel-gfx] [PATCH 01/19] drm/i915/perf: Fix OA filtering logic for GuC mode

[Dixit, Ashutosh]

On Thu, 15 Sep 2022 15:49:27 -0700, Umesh Nerlige Ramappa wrote:
>
> On Wed, Sep 14, 2022 at 04:13:41PM -0700, Umesh Nerlige Ramappa wrote:
> > On Wed, Sep 14, 2022 at 03:26:15PM -0700, Umesh Nerlige Ramappa wrote:
> >> On Tue, Sep 06, 2022 at 09:39:33PM +0300, Lionel Landwerlin wrote:
> >>> On 06/09/2022 20:39, Umesh Nerlige Ramappa wrote:
> >>>> On Tue, Sep 06, 2022 at 05:33:00PM +0300, Lionel Landwerlin wrote:
> >>>>> On 23/08/2022 23:41, Umesh Nerlige Ramappa wrote:
> >>>>>> With GuC mode of submission, GuC is in control of defining the
> >>>>>> context id field
> >>>>>> that is part of the OA reports. To filter reports, UMD and KMD must
> >>>>>> know what sw
> >>>>>> context id was chosen by GuC. There is not interface between KMD and
> >>>>>> GuC to
> >>>>>> determine this, so read the upper-dword of EXECLIST_STATUS to
> >>>>>> filter/squash OA
> >>>>>> reports for the specific context.
> >>>>>>
> >>>>>> Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa at intel.com>
> >>>>>
> >>>>>
> >>>>> I assume you checked with GuC that this doesn't change as the context
> >>>>> is running?
> >>>>
> >>>> Correct.
> >>>>
> >>>>>
> >>>>> With i915/execlist submission mode, we had to ask i915 to pin the
> >>>>> sw_id/ctx_id.
> >>>>>
> >>>>
> >>>> From GuC perspective, the context id can change once KMD de-registers
> >>>> the context and that will not happen while the context is in use.
> >>>>
> >>>> Thanks,
> >>>> Umesh
> >>>
> >>>
> >>> Thanks Umesh,
> >>>
> >>>
> >>> Maybe I should have been more precise in my question :
> >>>
> >>>
> >>> Can the ID change while the i915-perf stream is opened?
> >>>
> >>> Because the ID not changing while the context is running makes sense.
> >>>
> >>> But since the number of available IDs is limited to 2k or something on
> >>> Gfx12, it's possible the GuC has to reuse IDs if too many apps want to
> >>> run during the period of time while i915-perf is active and filtering.
> >>>
> >>
> >> available guc ids are 64k with 4k reserved for multi-lrc, so GuC may
> >> have to reuse ids once 60k ids are used up.
> >
> > Spoke to the GuC team again and if there are a lot of contexts (> 60K)
> > running, there is a possibility of the context id being recycled. In that
> > case, the capture would be broken. I would track this as a separate JIRA
> > and follow up on a solution.
> >
> > From OA use case perspective, are we interested in monitoring just one
> > hardware context? If we make sure this context is not stolen, are we
> > good?
> >
>
> + John
>
> Based on John's inputs - if a context is pinned, then KMD does not steal
> it's id. It would just look for something else or wait for a context to be
> available (pin count 0 I believe).
>
> Since we pin the context for the duration of the OA use case, we should be
> good here.

Since this appears to be true I am thinking of okay'ing this patch rather
than define a new interface with GuC for this. Let me know if there are any
objections about this.

Thanks.
--
Ashutosh

> >>> -Lionel
> >>>
> >>>
> >>>>
> >>>>>
> >>>>> If that's not the case then filtering is broken.
> >>>>>
> >>>>>
> >>>>> -Lionel
> >>>>>
> >>>>>