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 924EBC4332F for ; Tue, 31 Oct 2023 02:08:44 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 4C78B10E3D4; Tue, 31 Oct 2023 02:08:44 +0000 (UTC) Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.136]) by gabe.freedesktop.org (Postfix) with ESMTPS id 92B9910E3D4 for ; Tue, 31 Oct 2023 02:08:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1698718122; x=1730254122; h=date:message-id:from:to:cc:subject:in-reply-to: references:mime-version; bh=zqeQuVvXEn1k/Fd60U7e3wXJ9MwoAAUGG4hhsId5EzA=; b=I/dC3lPLJVLVo0Sd0BydeIT1gGcy80BlLKiceVCYEemHHMedTNpJB4yh 8SR460SNOXFMimRIyxiAbr2tmXnGv87FK3+3xjnBj4nxLsB/Tc0wThuc+ j0vXYI+VfUSZHel9WHZdhA+2EpywJpKT7AD/+hq3AicEEb51dvj3/5MPX gtzVPNK9VZaETWY3lo7Ok8LtkFNua6W/E+bPGxwfD4wXYbescUFgf4A7E wEkCFn9RVR1op0MFzFYEiFLNpJ+ZPGKs7yWvTLXEAuwhyxDbhMMt4njjt MGAU/SC6Qn6QCOfBFL1zkxZw7bQ/TMV05ip8Ek6jAUphTy3BqBHzicoQP Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10879"; a="367542456" X-IronPort-AV: E=Sophos;i="6.03,264,1694761200"; d="scan'208";a="367542456" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Oct 2023 19:08:39 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10879"; a="851101232" X-IronPort-AV: E=Sophos;i="6.03,264,1694761200"; d="scan'208";a="851101232" Received: from adixit-mobl.amr.corp.intel.com (HELO adixit-arch.intel.com) ([10.212.153.173]) by fmsmga003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Oct 2023 19:08:39 -0700 Date: Mon, 30 Oct 2023 19:08:37 -0700 Message-ID: <87ttq7a6hm.wl-ashutosh.dixit@intel.com> From: "Dixit, Ashutosh" To: Lionel Landwerlin In-Reply-To: References: <20230919161049.2307855-19-ashutosh.dixit@intel.com> <9d82cbe1-1dc3-4c44-9acb-58af4740c362@intel.com> <87o7gjdd43.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/29.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-xe] [18/21] drm/xe/uapi: More OA uapi fixes/additions 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: intel-xe@lists.freedesktop.org Errors-To: intel-xe-bounces@lists.freedesktop.org Sender: "Intel-xe" On Mon, 30 Oct 2023 03:06:23 -0700, Lionel Landwerlin wrote: > Hi Lionel, > On 27/10/2023 23:28, Dixit, Ashutosh wrote: > > On Fri, 20 Oct 2023 00:28:01 -0700, Lionel Landwerlin wrote: > >>> struct drm_xe_oa_open_param { > >>> + /** @extensions: Pointer to the first extension struct, if any */ > >>> + __u64 extensions; > >>> + > >>> + /** > >>> + * @config_syncobj: (Output) handle to configuration syncobj > >>> + * > >>> + * Handle to a syncobj which the kernel will signal after stream > >>> + * configuration or re-configuration is complete (after return from > >>> + * the ioctl). This handle can be provided as a dependency to the > >>> + * next XE exec ioctl. > >>> + */ > >>> + __u32 config_syncobj; > >> So you're adding this, but there is no implementation for it? > > Not yet, but there will be. Actually the plan is to do this: > > > > struct drm_xe_oa_open_param { > > /** @extensions: Pointer to the first extension struct, if any */ > > __u64 extensions; > > > > /** @num_syncs: Amount of struct drm_xe_sync in array. */ > > __u32 num_syncs; > > > > /** @syncs: Pointer to struct drm_xe_sync array. */ > > __u64 syncs; > > > > Which is exactly the same as what we see in drm_xe_vm_bind or > > drm_xe_exec. So the plan is to make perf_open behave exactly like an > > xe_exec which can be pipelined with other operations. > > I don't think this is going to work because it means we have to close and > reopen the stream every time we want to change the configuration. > > It would need to be a separate ioctl on the perf file descriptor to be > usable. I didn't mention it, but the plan is the provide the same sync mechanism also on the perf fd stream reconfiguration ioctl. > Otherwise we can't really pipeline anything since we have to drain the > buffer until we can close it and reopen a new file descriptor. This I don't understand, since the disable-reconfigure-enable sequence on the perf fd also resets OA buffer head/tail pointers (lose contents of the OA buffer). So not sure why we don't need to "drain the buffer" in this case. Of course, secretly I am hoping if it's possible to eliminate these disable-reconfigure-enable ioctl's on the perf fd and just do stream_close followed by reconfigure + stream_open. I don't quite understand why this is not possible. Thanks. -- Ashutosh