On Mon, 19 Sep 2022 20:22:40 -0700, Dixit, Ashutosh wrote: > > 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@xxxxxxxxx> > > >>>>> > > >>>>> > > >>>>> 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. With the above comments/assumptions this is: Reviewed-by: Ashutosh Dixit <ashutosh.dixit@xxxxxxxxx>
