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 36D76ECAAA1 for ; Fri, 16 Sep 2022 21:00:24 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 466A010E1D2; Fri, 16 Sep 2022 21:00:23 +0000 (UTC) Received: from mga06.intel.com (mga06b.intel.com [134.134.136.31]) by gabe.freedesktop.org (Postfix) with ESMTPS id EBC0910E1D2 for ; Fri, 16 Sep 2022 21:00:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1663362021; x=1694898021; h=date:message-id:from:to:cc:subject:in-reply-to: references:mime-version; bh=VWpzs7uBCEG8E26upHvuNfFz+ebXr3rCffLR3AnkjxM=; b=BKE2szmtIARnut0Mn2Cx1miv6fZVlAkK8Zotjhsg1lX3A3YUM62b9rt2 48W1cecBjCyTb0rRYN6g9uWCCxGIj0nW+3hgpVt24ot052Q9ulwRDEf43 1ClvRGmSV+7sdmJ8l6ExXDrv3s8hDv4tDpNOfHZ4G7LMSyTGBd8wnXLc9 0shjyJwasX1FRJZf5xLSZDi8jv399R3tVVhHM7NkGEwnSSP+v0HEcwXba 4jxCjsWJnffgoQmkTJHEYed59u3L6hU5noOC6LQU08jlSkHtgN/ND6kKl E0lbqRfzOoDXDq5wJxLMEqH4Q7FlkFwu4HsieChzx57iZbknBvdeHLX2I A==; X-IronPort-AV: E=McAfee;i="6500,9779,10472"; a="360818696" X-IronPort-AV: E=Sophos;i="5.93,321,1654585200"; d="scan'208";a="360818696" Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Sep 2022 14:00:19 -0700 X-IronPort-AV: E=Sophos;i="5.93,321,1654585200"; d="scan'208";a="793223945" Received: from adixit-mobl.amr.corp.intel.com (HELO adixit-arch.intel.com) ([10.212.227.117]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Sep 2022 14:00:19 -0700 Date: Fri, 16 Sep 2022 14:00:19 -0700 Message-ID: <87wna3uja4.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> 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 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