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 2CCC6C4829A for ; Tue, 13 Feb 2024 17:04:46 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id C3D0F10E893; Tue, 13 Feb 2024 17:04:45 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.b="beHDDHHP"; dkim-atps=neutral Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.14]) by gabe.freedesktop.org (Postfix) with ESMTPS id 38F7B10E893 for ; Tue, 13 Feb 2024 17:04:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1707843884; x=1739379884; h=date:message-id:from:to:cc:subject:in-reply-to: references:mime-version; bh=pJQG/WNrnQSkSFX2TIidWwYoBSmw1i5GzkwUqNVTRa8=; b=beHDDHHPwO2fDJSOc9WzqRDq92FPPjuTFjZX465aFmH/d6bRGFcfQQuy qgcf0RtxKpVBGza3iDflsrumpZ1PeaquCkyJL78LWiLvg2vYCUUcWQg+H KeyezhtHZ1snwxhw5O2xKTg3KNSoQeiUR3nLFWbbTYd8+ExirTJJQWAG+ +sti7S7bzhJW7h/tTGhkShl59Pc2MigaeTvMAGFhpWH6MfXgY1kaZalxz 2VK1enE8KyDB42zN3hlPtr76QtHwMQKd1gmbwPogquVhORlfnhavzSgEM zlAalOCXeAGKQ8TJWS8GOWw9Jvfy8s6uYen4+LkB3KJs1bWkJVBgdcA5g A==; X-IronPort-AV: E=McAfee;i="6600,9927,10982"; a="5681261" X-IronPort-AV: E=Sophos;i="6.06,157,1705392000"; d="scan'208";a="5681261" Received: from orviesa003.jf.intel.com ([10.64.159.143]) by orvoesa106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Feb 2024 09:04:44 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.06,157,1705392000"; d="scan'208";a="7585006" Received: from orsosgc001.jf.intel.com (HELO unerlige-ril.intel.com) ([10.165.21.138]) by ORVIESA003-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Feb 2024 09:04:44 -0800 Date: Tue, 13 Feb 2024 09:04:43 -0800 Message-ID: <85sf1wuwgk.wl-ashutosh.dixit@intel.com> From: "Dixit, Ashutosh" To: Lionel Landwerlin Cc: intel-xe@lists.freedesktop.org, Umesh Nerlige Ramappa Subject: Re: [PATCH 07/16] drm/xe/oa: OA stream initialization (OAG) In-Reply-To: <8bb5c0c9-e1e0-4687-a2ac-a5555cfbbdc8@intel.com> References: <20240208054916.3788133-1-ashutosh.dixit@intel.com> <20240208054916.3788133-8-ashutosh.dixit@intel.com> <85zfwaunc1.wl-ashutosh.dixit@intel.com> <8bb5c0c9-e1e0-4687-a2ac-a5555cfbbdc8@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-redhat-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 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: , Errors-To: intel-xe-bounces@lists.freedesktop.org Sender: "Intel-xe" On Fri, 09 Feb 2024 00:14:13 -0800, Lionel Landwerlin wrote: > Hi Lionel, > On 09/02/2024 09:08, Dixit, Ashutosh wrote: > > On Thu, 08 Feb 2024 22:23:30 -0800, Lionel Landwerlin wrote: > > Hi Lionel, > > > >>> +static int xe_oa_emit_oa_config(struct xe_oa_stream *stream) > >>> +{ > >>> +#define NOA_PROGRAM_ADDITIONAL_DELAY_US 500 > >>> + struct xe_oa_config_bo *oa_bo; > >>> + int err, us = NOA_PROGRAM_ADDITIONAL_DELAY_US; > >>> + > >>> + oa_bo = xe_oa_alloc_config_buffer(stream); > >>> + if (IS_ERR(oa_bo)) { > >>> + err = PTR_ERR(oa_bo); > >>> + goto exit; > >>> + } > >>> + > >>> + err = xe_oa_submit_bb(stream, oa_bo->bb); > >>> + > >>> + /* Additional empirical delay needed for NOA programming after registers are written */ > >>> + usleep_range(us, 2 * us); > >> Looks like the entire oa_config emission is synchronous. > > Yes that is indeed the case in this patchset. > > > >> That's a difference from i915 where we could just pipeline all the config > >> changes with perf queries in between. > >> > >> If there was a mechanism to return a syncobj in this ioctl, we could do the > >> wait from userspace and/or pipeline more submissions. > > That is the plan. To expose syncobj's in OA properties and make also make > > the oa_config emission asynchronous. But have not been able to get to it > > yet (IGT's are mostly getting ready, but now we may also need to add > > support for GPUVis before we can merge these patches, if we can't get a > > temporary waiver). > > > > So the direction right now is to get the current patchset merged before > > adding more features (like the syncobj). > > Any idea when that will happen? I am assuming you are asking about the merge so: adding GPUVis support seems to be a bit of a chore, so it will take a few (like 4+) weeks I am thinking. However I am hearing someone might add support in Mesa for Xe OA. If we are able to use Mesa as an upstream consumer of the OA uapi, it might go a bit faster. So discussions are on about this. > I suppose you'll have to define a new ioctl for this? Let me explain the overall idea first. Similar to 'xe-exec' we need these two fields: /** @num_syncs: Amount of struct drm_xe_sync in array. */ __u32 num_syncs; /** @syncs: Pointer to struct drm_xe_sync array. */ __u64 syncs; With these we can implement "fence wait" and "fence signal", similar to what happens with xe_exec (and which allows xe_exec to be pipelined). That is stream (re)configuration can wait for a fence, and will signal a fence after stream configuration is complete (including any additional delays after writing the registers, if an additional delay is needed). Now we need to do this in two places: 1. When the stream is opened. In this case 'num_syncs' and 'syncs' can be passed in via stream properties. 2. During stream reconfiguration, that is during CONFIG ioctl on the stream fd (called in Xe as DRM_XE_PERF_IOCTL_CONFIG). So this ioctl will need to accept a struct which has { 'id', 'num_syncs' and 'syncs' } as its members. That reminds me, I need to make this change for the CONFIG stream fd ioctl now, or at least introduce reserved fields to make this happen in the future without breaking the uapi. Does all this make sense? Thanks. -- Ashutosh > > (Also, separately I'm trying to figure out if a delay similar to the NOA > > programming delay is really needed when we have PES registers, the case for > > Xe2+. Looks like it might not be, but still needs to be confirmed). > > > > Thanks. > > -- > > Ashutosh > >