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.
Thanks,
Umesh
Thanks,
Umesh
Thanks,
Umesh
-Lionel
If that's not the case then filtering is broken.
-Lionel
