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 27468ECAAA1 for ; Fri, 16 Sep 2022 19:57:42 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 0462F10E516; Fri, 16 Sep 2022 19:57:42 +0000 (UTC) Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by gabe.freedesktop.org (Postfix) with ESMTPS id 2FB3C10E0E8 for ; Fri, 16 Sep 2022 19:57:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1663358258; x=1694894258; h=date:message-id:from:to:cc:subject:in-reply-to: references:mime-version; bh=UHq2BOjKCqgwH6a/FaT1mDVA6luf92wS7yMM42k1mUQ=; b=WQxOpIsYw/L3PyjEF0iE7LV4AUx/SBFT6UUheQxyg503piq/q2ObUW7e oq07S+bmQ1shAdIiALYvVobs0tyntVndLaLP/PhIORkjjmP7X1S6ry7Y+ 3R32DGNlqFgYxQKPu5WTfBX1YDleXFmyuUVZ3mTRGNpyhPDhvbw1hHmxv Kp26xTixnYMlLXVUQyBSAp2dvfW1W31j8ZfJYXtdKAF7Xxpcb/EH+rhsW RTGc/Cwdp7D17PHpci7GvD/JpiRcs0+ocJ7CSNXh+JQGRRKj+ChtfkIxS 87e1v/zcm5bQAdARuyUkTOLlR+e2WkonEuteizH2waI1whjeqDHCrOGJE A==; X-IronPort-AV: E=McAfee;i="6500,9779,10472"; a="278797056" X-IronPort-AV: E=Sophos;i="5.93,321,1654585200"; d="scan'208";a="278797056" Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Sep 2022 12:57:20 -0700 X-IronPort-AV: E=Sophos;i="5.93,321,1654585200"; d="scan'208";a="760163924" Received: from jdbrooks-mobl1.amr.corp.intel.com (HELO adixit-arch.intel.com) ([10.212.227.117]) by fmsmga001-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Sep 2022 12:57:19 -0700 Date: Fri, 16 Sep 2022 12:57:19 -0700 Message-ID: <87zgezum74.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> 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 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