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? > 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
