[Intel-gfx] [PATCH 16/19] drm/i915/perf: Apply Wa_18013179988

[Dixit, Ashutosh]

On Fri, 16 Sep 2022 13:25:17 -0700, Umesh Nerlige Ramappa wrote:
>
> On Fri, Sep 16, 2022 at 12:57:19PM -0700, Dixit, Ashutosh wrote:
> > On Fri, 16 Sep 2022 11:56:04 -0700, Umesh Nerlige Ramappa wrote:
> >>
> >> On Thu, Sep 15, 2022 at 10:16:30PM -0700, Dixit, Ashutosh wrote:
> >> > On Tue, 23 Aug 2022 13:41:52 -0700, Umesh Nerlige Ramappa wrote:
> >> >>
> >> >
> >> > Hi Umesh,
> >> >
> >> >> OA reports in the OA buffer contain an OA timestamp field that helps
> >> >> user calculate delta between 2 OA reports. The calculation relies on the
> >> >> CS timestamp frequency to convert the timestamp value to nanoseconds.
> >> >> The CS timestamp frequency is a function of the CTC_SHIFT value in
> >> >> RPM_CONFIG0.
> >> >>
> >> >> In DG2, OA unit assumes that the CTC_SHIFT is 3, instead of using the
> >> >> actual value from RPM_CONFIG0. At the user level, this results in an
> >> >> error in calculating delta between 2 OA reports since the OA timestamp
> >> >> is not shifted in the same manner as CS timestamp.
> >> >>
> >> >> To resolve this, return actual OA timestamp frequency to the user in
> >> >> i915_getparam_ioctl.
> >> >
> >> > Rather than exposing actual OA timestamp frequency to userspace (with the
> >> > corresponding uapi change, specially if it's only DG2 and not all future
> >> > products) questions about a couple of other options:
> >> >
> >> > Option 1. Can we set CTC_SHIFT in RPM_CONFIG0 to 3, so change GT freq to be the
> >> >          same as OA freq :-)
> >> >
> >> >   The HSD seems to mention this:
> >> >   Is setting CTC SHIFT to 0b11 on driver init an acceptable W/A?
> >> >   Note: Changing the shift setting on live driver may break apps that are
> >> >   currently running (including desktop manager).
> >> >
> >> > Option 2. Is it possible to correct the timestamps in OA report headers to
> >> >          compensate for the difference between OA and GT frequencies (say when
> >> >          copying OA data to userspace)?
> >> >
> >> >	  Though not sure if this is preferable to having userspace do this.
> >>
> >> It does affect other platforms too. There's no guarantee on what the
> >> CTC_SHIFT value would be for different platforms, so user would have to at
> >> least query that somehow (maybe from i915). It's simpler for user to use
> >> the exported OA frequency since it is also backwards compatible.
> >
> > Is Option 2 above feasible since it would stop propagating the change to
> > various UMD's?
>
> Hmm, there is logic today that squashes context ids when doing oa buffer
> filtering, but it does that on selective reports (i.e. if a gem_context is
> passed).
>
> For this issue: for a 16MB OA buffer with 256 byte reports, that would be
> an additional write of 262144 in the kmd (to smem). For 20us sampled OA
> reports, it would be approx. 195 KB/s. Shouldn't be too much. Only 2
> concerns:
>
> - the mmapped use case may break, but I don't see that being upstreamed.
> We may have divergent solutions for upstream and internal.
> - blocking/polling tests in IGT will be sensitive to this change on some
> platforms and may need to be bolstered.

If this correction/compensation in the kernel works out, even for internal
too we could do the following:

* For non-mmaped case, do the correction in the kernel and expose OA freq
  == GT freq (in the getparam ioctl)
* For mmaped case expose the actual OA freq (!= GT freq)

This will restrict the divergence only to the mmaped case (which we will
probably not be able to upstream).

>
> I will give it a shot and get back,
>
> Thanks,
> Umesh
>
> >
> >> https://patchwork.freedesktop.org/patch/498917/?series=107633&rev=3 is
> >> consumed by GPUvis. That reminds me, I should include the UMD links for the
> >> patches with uapi changes.
> >
> > I was thinking more about UMD's which analayze OA data and who till now are
> > probably assuming OA freq == GT freq and will now have to drop that
> > assumption. So not sure how widespread would be these changes in
> > the (multiple different?) UMD(s).
> >
> > Thanks.
> > --
> > Ashutosh