From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 91EF4C54EE9 for ; Tue, 20 Sep 2022 01:24:12 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 8A1B110E20F; Tue, 20 Sep 2022 01:24:11 +0000 (UTC) Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by gabe.freedesktop.org (Postfix) with ESMTPS id 6C90410E20F for ; Tue, 20 Sep 2022 01:24:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1663637049; x=1695173049; h=date:message-id:from:to:cc:subject:in-reply-to: references:mime-version; bh=Br35030WUp3Ce0gHPQ4sHt9eGRTC36qy/J/ya7LRDAc=; b=Bx2gpdP+PJVTOH1AEwGQqVF2d4g66yj47MT9LwDZOEQyoixde+MBg57F ZDw1WOsL0iaAthof2Nc4YwCoWkyP2Y3QOo5uvLGLEcf8TzKIJJsRzpbEC AU7rqkH1n3lK3H52+YdLtAZ1BYyeWjnSh80Cq7Kj02EquRf/DT2sRjeU0 PZnCvrewSpxItIzVPLUlkfBCG/EVMsQ+3kmIIgcwNZk3R3CvReakDoUio ehEKzYxCR5UTV5oO7h0PHE75ICEligGx0S79Lxl63AmGGe5hCiBcm/7Iu AdmqRSomeWCmU75b2ashBGhxzFeJ5OhAuDB6LgOE8gIO92zXhvYGT5gYr g==; X-IronPort-AV: E=McAfee;i="6500,9779,10475"; a="279945550" X-IronPort-AV: E=Sophos;i="5.93,329,1654585200"; d="scan'208";a="279945550" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Sep 2022 18:24:08 -0700 X-IronPort-AV: E=Sophos;i="5.93,329,1654585200"; d="scan'208";a="744326737" Received: from adixit-mobl.amr.corp.intel.com (HELO adixit-arch.intel.com) ([10.251.10.194]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Sep 2022 18:24:08 -0700 Date: Mon, 19 Sep 2022 18:24:03 -0700 Message-ID: <87y1uedej0.wl-ashutosh.dixit@intel.com> From: "Dixit, Ashutosh" To: Umesh Nerlige Ramappa In-Reply-To: References: <20220823204155.8178-1-umesh.nerlige.ramappa@intel.com> <20220823204155.8178-17-umesh.nerlige.ramappa@intel.com> <875yhn526p.wl-ashutosh.dixit@intel.com> <87zgezum74.wl-ashutosh.dixit@intel.com> <87wna3uja4.wl-ashutosh.dixit@intel.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/28.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Subject: Re: [Intel-gfx] [PATCH 16/19] drm/i915/perf: Apply Wa_18013179988 X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: intel-gfx@lists.freedesktop.org Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" On Mon, 19 Sep 2022 14:21:07 -0700, Umesh Nerlige Ramappa wrote: > > On Fri, Sep 16, 2022 at 02:00:19PM -0700, Dixit, Ashutosh wrote: > > 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, > > We cannot tweak this in the OA report header since that will be out of sync > with the counters in the report. The other issue here is that the bug also > applies to MI_REPORT_PERF_COUNT, and KMD cannot do anything to fix that. I > would think this interface is the clean way to do this. In that case this is: Reviewed-by: Ashutosh Dixit May still need a uapi change ack but that's separate. > > Thanks, > Umesh > > >> > >> 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