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 CDA94EB64D9 for ; Fri, 7 Jul 2023 06:18:26 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 89E5A10E50B; Fri, 7 Jul 2023 06:18:26 +0000 (UTC) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by gabe.freedesktop.org (Postfix) with ESMTPS id 50A4B10E50B for ; Fri, 7 Jul 2023 06:18:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1688710705; x=1720246705; h=date:message-id:from:to:cc:subject:in-reply-to: references:mime-version; bh=kp5iimXpTKOoaZJJ480Jiz+d1rH5/DvzV8+yXOuf1K4=; b=TxcwwfiJ9nEs9d3qgSaKPzs6zI3PDuGZKEm5O8pxI2OCQNi0RHvS/St0 WuJqGkR19adbm+G2sb6ZDdL2F1WzN7VzzyfEUHEOCIQa0I72hhP6iK16X TKLwDdjwsoAVc2yAveSsH4eKA9SPRT7kXKH07ktPEBfjq7TehQC5zKWBO idIeufUjnittkvk6IWEvmdyfm8jKj+NQ3P+UCA5/gSqanGRz/acdwDacW hjwvd1+WCx9ZJjl4y1eEk9zJN7SYoLjg0KvyOY4ppuTLPjTzFhuJ0yu47 VlyzzEf2E2v5UhVV/gyE6Ho7YfWbfnJ0Te0mOFBNg9utoOdGKhwqGElr2 Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10763"; a="394581782" X-IronPort-AV: E=Sophos;i="6.01,187,1684825200"; d="scan'208";a="394581782" Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Jul 2023 23:18:24 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10763"; a="789835930" X-IronPort-AV: E=Sophos;i="6.01,187,1684825200"; d="scan'208";a="789835930" Received: from adixit-mobl.amr.corp.intel.com (HELO adixit-arch.intel.com) ([10.209.92.59]) by fmsmga004-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Jul 2023 23:18:23 -0700 Date: Thu, 06 Jul 2023 23:08:04 -0700 Message-ID: <878rbsckzf.wl-ashutosh.dixit@intel.com> From: "Dixit, Ashutosh" To: "Iddamsetty, Aravind" In-Reply-To: <04ae6811-9bc1-c66d-6cb8-640bfd8a9c7b@intel.com> References: <20230627122113.1472532-1-aravind.iddamsetty@intel.com> <20230627122113.1472532-3-aravind.iddamsetty@intel.com> <87mt09daqu.wl-ashutosh.dixit@intel.com> <87a5w8cvmr.wl-ashutosh.dixit@intel.com> <04ae6811-9bc1-c66d-6cb8-640bfd8a9c7b@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.2 (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-xe] [PATCH v2 2/2] drm/xe/pmu: Enable PMU interface X-BeenThere: intel-xe@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel Xe graphics driver List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Bommu Krishnaiah , intel-xe@lists.freedesktop.org, Tvrtko Ursulin Errors-To: intel-xe-bounces@lists.freedesktop.org Sender: "Intel-xe" On Thu, 06 Jul 2023 20:53:47 -0700, Iddamsetty, Aravind wrote: > Hi Aravind, I will look at the timing stuff later but one further question about the requirement: > > Also, could you please explain where the requirement to expose these OAG > > group busy/free registers via the PMU is coming from? Since these are OA > > registers presumably they can be collected using the OA subsystem. > > L0 sysman needs this > https://spec.oneapi.io/level-zero/latest/sysman/api.html#zes-engine-properties-t > and xpumanager uses this > https://github.com/intel/xpumanager/blob/master/core/src/device/gpu/gpu_device.cpp So fine these are UMD requirements, but why do these quantities (everything in this patch) have to exposed via PMU? I could just create sysfs or an ioctl to provide these to userland, right? I had this same question about i915 PMU which was never answered. i915 PMU IMO does truly strange things like sample freq's every 5 ms and provides software averages which I thought userspace can easily do. I don't think it's the timestamps, maybe there is some convention related to the cpu pmu (which I am not familiar with). Let's see, maybe Tvrtko can also answer why these things were exposed via i915 PMU. Thanks. -- Ashutosh > > > > The i915 PMU I believe deduces busyness by sampling the RING_CTL register > > using a timer. So these registers look better since you can get these > > busyness values directly. On the other hand you can only get busyness for > > an engine group and things like compute seem to be missing? > > The per engine busyness is a different thing we still need that and it > has different implementation with GuC enabled, I believe Umesh is > looking into that. > > compute group will still be accounted in XE_OAG_RENDER_BUSY_FREE and > also under XE_OAG_RC0_ANY_ENGINE_BUSY_FREE. > > > > Also, would you know about plans to expose other kinds of busyness-es? I > > think we may be exposing per-VF and also per-client busyness via PMU. Not > > sure what else GuC can expose. Knowing all this we can better understand > > how these particular busyness values will be used. > > ya, that shall be coming next probably from Umesh but per client > busyness is through fdinfo.