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 96612C07545 for ; Tue, 24 Oct 2023 15:54:48 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 42CA210E0B9; Tue, 24 Oct 2023 15:54:48 +0000 (UTC) Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.7]) by gabe.freedesktop.org (Postfix) with ESMTPS id 5CAFC10E0B9 for ; Tue, 24 Oct 2023 15:54:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1698162887; x=1729698887; h=date:message-id:from:to:cc:subject:in-reply-to: references:mime-version; bh=FddJk+trpFfox413HorEv3owCQcxt547otcZnpX7pNc=; b=Y0rO2qD7Dv9zhjtj7baZlAILfH8swt0WH9cmdUz894M7Ui5P1Tf1+G1x +Iuu9B8400DJgJ9B74Exfy3XtcKBHGwhPdDTz8b//wxlnVd0IKuojeXQN hlnbqtVYBK7yJfGFk7E/SQwZaxGIw3MdOIdc2Pi1QaIIa3cNVr77/r0f4 Kv+H6T2pKYx2x84iUu3r7RTUvkvT9Cy8ph4Tr0npShx30Cyj/6u19ibXp DVDhD4aMUbLwOjipBjLXKRIF1aonmClZFVMabXt1ds3B1l021DO9W0dIN ejwmyvmETYqICCRMPxirKodBlHPWB4YjIVR3aZRu2UBqajpxL7WkbJizC w==; X-IronPort-AV: E=McAfee;i="6600,9927,10873"; a="8649470" X-IronPort-AV: E=Sophos;i="6.03,248,1694761200"; d="scan'208";a="8649470" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmvoesa101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Oct 2023 08:54:46 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10873"; a="824353792" X-IronPort-AV: E=Sophos;i="6.03,248,1694761200"; d="scan'208";a="824353792" Received: from adixit-mobl.amr.corp.intel.com (HELO adixit-arch.intel.com) ([10.212.221.214]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Oct 2023 08:54:46 -0700 Date: Tue, 24 Oct 2023 08:54:24 -0700 Message-ID: <87pm149ftb.wl-ashutosh.dixit@intel.com> From: "Dixit, Ashutosh" To: Umesh Nerlige Ramappa In-Reply-To: <87r0lkach7.wl-ashutosh.dixit@intel.com> References: <20230919161049.2307855-20-ashutosh.dixit@intel.com> <340b766e-23ae-4a7a-9633-a2d7d1b97752@intel.com> <87r0lkach7.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] [19/21] drm/xe/uapi: Drop OA_IOCTL_VERSION 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: francois.dugast@intel.com, intel-xe@lists.freedesktop.org, Rodrigo Vivi Errors-To: intel-xe-bounces@lists.freedesktop.org Sender: "Intel-xe" On Mon, 23 Oct 2023 21:08:52 -0700, Dixit, Ashutosh wrote: > > On Mon, 23 Oct 2023 16:02:53 -0700, Umesh Nerlige Ramappa wrote: > > > > Hi Umesh/Lionel, > > > On Fri, Oct 20, 2023 at 10:36:37AM +0300, Lionel Landwerlin wrote: > > > On 19/09/2023 19:10, Ashutosh Dixit wrote: > > >> OA version was previously used to track which OA properties were introduced > > >> at which version. However OA version is an outlier in that a similar > > >> version is not used anywhere else in the kernel. > > >> > > >> For XE, we will track addition of new properties by means of > > >> xe_user_extension. Userland can either maintain a mapping of OA properties > > >> against the kernel version, or rely on return codes (e.g. ENOTSUPP) to > > >> "discover" OA properties. > > > > > > > > > As a userspace driver this terrible. > > > > > > You're making us write more code because we have to discover every single > > > piece of implementation tweaks ever made to the kernel driver. > > > > > > Yes OA version was an outlier in that it was better than the rest of > > > kernel API. > > > > > > By reading a single value we could make decisions about how to > > > communicate with the kernel driver. > > > > > > > > > Having xe_user_extension here is not helping, we still have to fuzz our > > > way around the kernel to figure out what feature level is available. > > > > Hi Lionel, Ashutosh, > > > > I don't want to change interfaces to make it more difficult for the > > UMDs. Do you think capabilities could help achieve what you want? We could > > have a bitmask of feature availability and the bitmask could be part of the > > xe oa query. > > > > If that's seen as an unnecessary uApi impact, then I am ok with version > > being returned in the oa info query. > > > > My primary concerns with the version in i915 were > > > > (1) version bumps would need documentation even when version bump did not > > have explicit uApi change. I couldn't find a good place in i915_drm.h to > > put such documentation. I think capabilities would be self documenting and > > it would be explicitly added to the uApi header. > > (2) sometimes before upstreaming a feature, we maintained an internal > > version for the feature that was using a different range of versions. This > > would cause some grief when rebasing since the versions need to be > > increasing in the order of commits. If we had a bitmask, we can manage it > > better since there is no need to have an increasing value. > > > > Suggestions welcome. > > My 2 cents on this is that we should have uniform interfaces across Xe, > rather than have special treatment for OA. Or is OA special? Why? Because > we haven't absracted HW well? Why do OA interfaces have to change > frequently that we are talking about an OA version or OA capabilities when > other interfaces/subsystems don't seem to need these? > > To me it seems capabilities should not be in the uapi since capabilities > can be constructed entirely in userspace by "probing" for available user > extensions (so capabilities seem redundant/duplicated). KMD can make it > easier for UMD's by returning unique return codes when particular > extensions are not present. That said, we could probably go with capabilities if needed. An extension N would be represented by a capability BIT(N). What we don't want to do is add the same extension twice in xe_drm.h, once as an extension and a second time as a capability. > > I am copying other people who are defining the uapi in Xe for comments, > hopefully we'll hear something. As I said the best way would be to do > things uniformly across various subsystems so UMD's can also build and use > common user xspace API's. > > Francois/Matt/Rodrigo: could you please chime in here about how UMD's are > supposed to handle extensions when uapi changes happen. > > Thanks. > -- > Ashutosh