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 429BEC07545 for ; Tue, 24 Oct 2023 04:09:16 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 0D47C10E064; Tue, 24 Oct 2023 04:09:16 +0000 (UTC) Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.65]) by gabe.freedesktop.org (Postfix) with ESMTPS id 8763B10E064 for ; Tue, 24 Oct 2023 04:09:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1698120554; x=1729656554; h=date:message-id:from:to:cc:subject:in-reply-to: references:mime-version; bh=GascRzPyhij1Z/DS3pex3CZ/5GWjTY2JTNrNIvmKCXk=; b=iCNcsZA4DJ/z+w9BpLFXEFK/9D0GSpp2rnI90QIUSCiiVg3PG9e0BxvP njsr9VGiWVFFp3EFVE3+qEvkJBRrLyNr2p4HyiNMu3s3LiWN/3MyGYCwF iRh3Zb1RrcxCsKf0LgykORZXysPLVpYMqxZayQmXlVmq0svLQyFGP5sOX s5FgqX56NgtR5ql/Sa1XjZ73nuHHxBDY1x/YkDvqqVdFV5a5I8gQROfCN H6TxGk+pXorOqPK+4DCx6n3gZ5D0Btf+99gBDva6uXhDHnFMXaMO0yNyf a7R8KHEPbGdPGBPOKXW3ABVj8yhx71fnEy/1uBcy3JXdU59r/NNr3j2km Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10872"; a="390859042" X-IronPort-AV: E=Sophos;i="6.03,246,1694761200"; d="scan'208";a="390859042" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Oct 2023 21:09:14 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10872"; a="881988773" X-IronPort-AV: E=Sophos;i="6.03,246,1694761200"; d="scan'208";a="881988773" Received: from adixit-mobl.amr.corp.intel.com (HELO adixit-arch.intel.com) ([10.209.48.228]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Oct 2023 21:09:13 -0700 Date: Mon, 23 Oct 2023 21:08:52 -0700 Message-ID: <87r0lkach7.wl-ashutosh.dixit@intel.com> From: "Dixit, Ashutosh" To: Umesh Nerlige Ramappa In-Reply-To: References: <20230919161049.2307855-20-ashutosh.dixit@intel.com> <340b766e-23ae-4a7a-9633-a2d7d1b97752@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 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. 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