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 X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D1B86C2B9F4 for ; Mon, 14 Jun 2021 16:24:17 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9717B613D9 for ; Mon, 14 Jun 2021 16:24:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234054AbhFNQ0T (ORCPT ); Mon, 14 Jun 2021 12:26:19 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53544 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233044AbhFNQ0S (ORCPT ); Mon, 14 Jun 2021 12:26:18 -0400 Received: from perceval.ideasonboard.com (perceval.ideasonboard.com [IPv6:2001:4b98:dc2:55:216:3eff:fef7:d647]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EB477C061574 for ; Mon, 14 Jun 2021 09:24:15 -0700 (PDT) Received: from pendragon.ideasonboard.com (62-78-145-57.bb.dnainternet.fi [62.78.145.57]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id 49A52A59; Mon, 14 Jun 2021 18:24:13 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1623687853; bh=DJSLGOY9tbIQ4kQyUzJsZbfvx55crZSawEGsubblm+0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Y0tVKLt7Mwie1rj3RTnQmypSOg8q2rpS4cgdvoy5aVf0h/VfG/SZZSRO8eIvFSdkY MCL79UzALdoFyVLGZXqBs5dmztIqdEGo8PYtBfrocigt2FrVvfNYRTV5mRU+b1pbf+ LNqEeMBfwl8oTIw13+BO5PlSvmyRysVfNHFUN5mY= Date: Mon, 14 Jun 2021 19:23:53 +0300 From: Laurent Pinchart To: Liviu Dudau Cc: Alyssa Rosenzweig , Haneen Mohammed , Alexandre Belloni , Linux Doc Mailing List , Xinliang Liu , Daniel Vetter , Edmund Dea , Alexandre Torgue , dri-devel , Russell King , Melissa Wen , Tomi Valkeinen , Thierry Reding , Benjamin Gaignard , Anitha Chrisanthus , Daniel Vetter , Steven Price , Sam Ravnborg , Jyri Sarha , Jerome Brunet , Marek Vasut , Joonyoung Shim , Qiang Yu , Krzysztof Kozlowski , Kevin Hilman , Neil Armstrong , Alyssa Rosenzweig , Xinwei Kong , Jonathan Hunter , David Airlie , Ludovic Desroches , Kieran Bingham , VMware Graphics , NXP Linux Team , Ben Skeggs , Chun-Kuang Hu , Maxime Coquelin , Jonas Karlman , Martin Blumenstingl , Chen Feng , Sascha Hauer , Alison Wang , Roland Scheidegger , Andrzej Hajda , Hans de Goede , Maxime Ripard , Rodrigo Vivi , Matthias Brugger , Nicolas Ferre , Chen-Yu Tsai , Sean Paul , Thomas Zimmermann , Paul Cercueil , Jernej Skrabec , Huang Rui , Rodrigo Siqueira , Hyun Kwon , Boris Brezillon , Andrew Jeffery , Yannick Fertr e , Jonathan Corbet , Seung-Woo Kim , Sandy Huang , Robert Foss , Joel Stanley , Tomeu Vizoso , Kyungmin Park , Noralf Tr??nnes , Philippe Cornu , Pengutronix Kernel Team , Alex Deucher , Tian Tao , Oleksandr Andrushchenko , Shawn Guo , Christian K??nig , Gerd Hoffmann Subject: Re: [PATCH v3] Documentation: gpu: Mention the requirements for new properties Message-ID: References: <20210610174731.1209188-1-maxime@cerno.tech> <20210611120309.2b5eb4htupv5ss32@e110455-lin.cambridge.arm.com> <20210611133418.mwjabkd4zzcgekti@e110455-lin.cambridge.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20210611133418.mwjabkd4zzcgekti@e110455-lin.cambridge.arm.com> Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org On Fri, Jun 11, 2021 at 02:34:18PM +0100, Liviu Dudau wrote: > On Fri, Jun 11, 2021 at 08:56:04AM -0400, Alyssa Rosenzweig wrote: > > > What I'm expected to see in the future is new functionality that gets implemented by > > > one hardware vendor and the kernel developers trying to enable that for userspace. It > > > could be that the new property is generic, but there is no way of testing that on > > > more than one implementation yet, so I'd say we are generous calling it "standard > > > property". When the second or third hardware vendor comes along and starts supporting > > > that property with their own set of extra requirements, then we can call it > > > "standard". Then comes the effort cost: would it be easier to start with a vendor > > > property that only the vendor needs to support (and can submit patches into the > > > compositors to do so) and when the standard property gets added moves to that, or > > > should we start with a generic property that gets implemented by the compositors > > > (maybe, but then only one vendor supports it) and then later when we actually > > > standardise the property we will have to carry backwards compatibility code in the > > > kernel to handle the old behaviour for old userspace? My proposal to Maxime was for > > > the former option to be reflected in the documentation, but I would like to hear your > > > thoughts. > > > > Just my 2c - if the mainline kernel isn't willing to commit to a feature > > for upstream userspace to use, why does that feature belong in the > > kernel at all? I don't see much value in exposing hardware for the sake > > of exposing it when, practically, Linux userspace /can't/ use it as-is. > > > > Might these vendor properties be used on downstream Android userspaces? > > That's not generally an upstream goal to support. > > I think the assumption is that we are willing to commit to supporting a feature for > userspace, just that (I personally) lack the confidence that I will be getting the > feature right on the first attempt and using only one vendor hardware. And that > supporting potential mistakes I might've made in the first version is harder if the > feature was deemed "standard". There's also the issue that the first developer to try to upstream a standard property for a new feature often gets ignored as nobody else has experience with that feature, and thus lack personal interest. That's not a pure technical issue, there's a management problem there too. The right solution may ne to figure out a good process to standardize new property without making it so difficult that everybody will give up and only use downstream kernels. I've heard too many times already from vendors that upstream isn't something they can target as the bar to entry is too high, and when I convince them to submit patches to extend APIs, those patches get ignored (I'm not talking about DRM/KMS only here). > I'm talking from my experience with the writeback connector. We almost committed the > feature twice before more people chipped in and asked us for changes, but that was lucky. -- Regards, Laurent Pinchart 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 X-Spam-Level: X-Spam-Status: No, score=-3.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D1BB7C48BE6 for ; Mon, 14 Jun 2021 16:24:17 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id 9153361350 for ; Mon, 14 Jun 2021 16:24:17 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9153361350 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ideasonboard.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id E84D089BFB; Mon, 14 Jun 2021 16:24:16 +0000 (UTC) Received: from perceval.ideasonboard.com (perceval.ideasonboard.com [IPv6:2001:4b98:dc2:55:216:3eff:fef7:d647]) by gabe.freedesktop.org (Postfix) with ESMTPS id A215B89BFB for ; Mon, 14 Jun 2021 16:24:15 +0000 (UTC) Received: from pendragon.ideasonboard.com (62-78-145-57.bb.dnainternet.fi [62.78.145.57]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id 49A52A59; Mon, 14 Jun 2021 18:24:13 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1623687853; bh=DJSLGOY9tbIQ4kQyUzJsZbfvx55crZSawEGsubblm+0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Y0tVKLt7Mwie1rj3RTnQmypSOg8q2rpS4cgdvoy5aVf0h/VfG/SZZSRO8eIvFSdkY MCL79UzALdoFyVLGZXqBs5dmztIqdEGo8PYtBfrocigt2FrVvfNYRTV5mRU+b1pbf+ LNqEeMBfwl8oTIw13+BO5PlSvmyRysVfNHFUN5mY= Date: Mon, 14 Jun 2021 19:23:53 +0300 From: Laurent Pinchart To: Liviu Dudau Subject: Re: [PATCH v3] Documentation: gpu: Mention the requirements for new properties Message-ID: References: <20210610174731.1209188-1-maxime@cerno.tech> <20210611120309.2b5eb4htupv5ss32@e110455-lin.cambridge.arm.com> <20210611133418.mwjabkd4zzcgekti@e110455-lin.cambridge.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20210611133418.mwjabkd4zzcgekti@e110455-lin.cambridge.arm.com> X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Ludovic Desroches , Haneen Mohammed , Alexandre Belloni , Linux Doc Mailing List , Xinliang Liu , Daniel Vetter , Edmund Dea , Alexandre Torgue , dri-devel , Sandy Huang , Melissa Wen , Andrzej Hajda , Thierry Reding , Gerd Hoffmann , Benjamin Gaignard , Anitha Chrisanthus , Daniel Vetter , Jonathan Hunter , Sam Ravnborg , Jerome Brunet , Marek Vasut , Jonathan Corbet , Joonyoung Shim , Krzysztof Kozlowski , Kevin Hilman , Neil Armstrong , Russell King , Steven Price , David Airlie , Xinwei Kong , Noralf Tr??nnes , VMware Graphics , Alyssa Rosenzweig , Hyun Kwon , NXP Linux Team , Chun-Kuang Hu , Thomas Zimmermann , Jonas Karlman , Martin Blumenstingl , Chen Feng , Sascha Hauer , Alison Wang , Roland Scheidegger , Shawn Guo , Ben Skeggs , Maxime Ripard , Rodrigo Vivi , Matthias Brugger , Chen-Yu Tsai , Sean Paul , Pengutronix Kernel Team , Paul Cercueil , Jernej Skrabec , Rodrigo Siqueira , Tomi Valkeinen , Hans de Goede , Andrew Jeffery , Huang Rui , Yannick Fertr e , Boris Brezillon , Seung-Woo Kim , Nicolas Ferre , Robert Foss , Alyssa Rosenzweig , Joel Stanley , Tomeu Vizoso , Kyungmin Park , Kieran Bingham , Qiang Yu , Maxime Coquelin , Alex Deucher , Tian Tao , Oleksandr Andrushchenko , Philippe Cornu , Jyri Sarha , Christian K??nig Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Fri, Jun 11, 2021 at 02:34:18PM +0100, Liviu Dudau wrote: > On Fri, Jun 11, 2021 at 08:56:04AM -0400, Alyssa Rosenzweig wrote: > > > What I'm expected to see in the future is new functionality that gets implemented by > > > one hardware vendor and the kernel developers trying to enable that for userspace. It > > > could be that the new property is generic, but there is no way of testing that on > > > more than one implementation yet, so I'd say we are generous calling it "standard > > > property". When the second or third hardware vendor comes along and starts supporting > > > that property with their own set of extra requirements, then we can call it > > > "standard". Then comes the effort cost: would it be easier to start with a vendor > > > property that only the vendor needs to support (and can submit patches into the > > > compositors to do so) and when the standard property gets added moves to that, or > > > should we start with a generic property that gets implemented by the compositors > > > (maybe, but then only one vendor supports it) and then later when we actually > > > standardise the property we will have to carry backwards compatibility code in the > > > kernel to handle the old behaviour for old userspace? My proposal to Maxime was for > > > the former option to be reflected in the documentation, but I would like to hear your > > > thoughts. > > > > Just my 2c - if the mainline kernel isn't willing to commit to a feature > > for upstream userspace to use, why does that feature belong in the > > kernel at all? I don't see much value in exposing hardware for the sake > > of exposing it when, practically, Linux userspace /can't/ use it as-is. > > > > Might these vendor properties be used on downstream Android userspaces? > > That's not generally an upstream goal to support. > > I think the assumption is that we are willing to commit to supporting a feature for > userspace, just that (I personally) lack the confidence that I will be getting the > feature right on the first attempt and using only one vendor hardware. And that > supporting potential mistakes I might've made in the first version is harder if the > feature was deemed "standard". There's also the issue that the first developer to try to upstream a standard property for a new feature often gets ignored as nobody else has experience with that feature, and thus lack personal interest. That's not a pure technical issue, there's a management problem there too. The right solution may ne to figure out a good process to standardize new property without making it so difficult that everybody will give up and only use downstream kernels. I've heard too many times already from vendors that upstream isn't something they can target as the bar to entry is too high, and when I convince them to submit patches to extend APIs, those patches get ignored (I'm not talking about DRM/KMS only here). > I'm talking from my experience with the writeback connector. We almost committed the > feature twice before more people chipped in and asked us for changes, but that was lucky. -- Regards, Laurent Pinchart