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=-1.0 required=3.0 tests=MAILING_LIST_MULTI,SPF_PASS, URIBL_BLOCKED autolearn=ham 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 C6BB9C43387 for ; Fri, 21 Dec 2018 15:51:38 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8EB862190A for ; Fri, 21 Dec 2018 15:51:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731347AbeLUPvh (ORCPT ); Fri, 21 Dec 2018 10:51:37 -0500 Received: from mail.netline.ch ([148.251.143.178]:34717 "EHLO netline-mail3.netline.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725845AbeLUPvg (ORCPT ); Fri, 21 Dec 2018 10:51:36 -0500 Received: from localhost (localhost [127.0.0.1]) by netline-mail3.netline.ch (Postfix) with ESMTP id 0AE062A6056; Fri, 21 Dec 2018 16:51:33 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at netline-mail3.netline.ch Received: from netline-mail3.netline.ch ([127.0.0.1]) by localhost (netline-mail3.netline.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Nk4p0R1c7qGD; Fri, 21 Dec 2018 16:51:32 +0100 (CET) Received: from thor (39.1.199.178.dynamic.wline.res.cust.swisscom.ch [178.199.1.39]) by netline-mail3.netline.ch (Postfix) with ESMTPSA id 4EE022A6055; Fri, 21 Dec 2018 16:51:32 +0100 (CET) Received: from localhost ([::1]) by thor with esmtp (Exim 4.91) (envelope-from ) id 1gaN5H-0003u6-U1; Fri, 21 Dec 2018 16:51:31 +0100 Subject: Re: [PATCH] drm: add capability DRM_CAP_ASYNC_UPDATE To: Alex Deucher , dnicoara@chromium.org, =?UTF-8?Q?St=c3=a9phane_Marchesin?= , Sean Paul , Alexandros Frantzis , David Airlie , Linux Kernel Mailing List , dri-devel , Tomasz Figa , Gustavo Padovan , Helen Koike , kernel@collabora.com, "Kazlauskas, Nicholas" References: <0a0a35bf-69e4-8dcd-46fc-7053081480d5@collabora.com> <9be83a7f-aa5f-8d8f-0486-db68e12c5feb@daenzer.net> <20181221132637.GR21184@phenom.ffwll.local> From: =?UTF-8?Q?Michel_D=c3=a4nzer?= Openpgp: preference=signencrypt Autocrypt: addr=michel@daenzer.net; prefer-encrypt=mutual; keydata= mQGiBDsehS8RBACbsIQEX31aYSIuEKxEnEX82ezMR8z3LG8ktv1KjyNErUX9Pt7AUC7W3W0b LUhu8Le8S2va6hi7GfSAifl0ih3k6Bv1Itzgnd+7ZmSrvCN8yGJaHNQfAevAuEboIb+MaVHo 9EMJj4ikOcRZCmQWw7evu/D9uQdtkCnRY9iJiAGxbwCguBHtpoGMxDOINCr5UU6qt+m4O+UD /355ohBBzzyh49lTj0kTFKr0Ozd20G2FbcqHgfFL1dc1MPyigej2gLga2osu2QY0ObvAGkOu WBi3LTY8Zs8uqFGDC4ZAwMPoFy3yzu3ne6T7d/68rJil0QcdQjzzHi6ekqHuhst4a+/+D23h Za8MJBEcdOhRhsaDVGAJSFEQB1qLBACOs0xN+XblejO35gsDSVVk8s+FUUw3TSWJBfZa3Imp V2U2tBO4qck+wqbHNfdnU/crrsHahjzBjvk8Up7VoY8oT+z03sal2vXEonS279xN2B92Tttr AgwosujguFO/7tvzymWC76rDEwue8TsADE11ErjwaBTs8ZXfnN/uAANgPLQjTWljaGVsIERh ZW56ZXIgPG1pY2hlbEBkYWVuemVyLm5ldD6IXgQTEQIAHgUCQFXxJgIbAwYLCQgHAwIDFQID AxYCAQIeAQIXgAAKCRBaga+OatuyAIrPAJ9ykonXI3oQcX83N2qzCEStLNW47gCeLWm/QiPY jqtGUnnSbyuTQfIySkK5AQ0EOx6FRRAEAJZkcvklPwJCgNiw37p0GShKmFGGqf/a3xZZEpjI qNxzshFRFneZze4f5LhzbX1/vIm5+ZXsEWympJfZzyCmYPw86QcFxyZflkAxHx9LeD+89Elx bw6wT0CcLvSv8ROfU1m8YhGbV6g2zWyLD0/naQGVb8e4FhVKGNY2EEbHgFBrAAMGA/0VktFO CxFBdzLQ17RCTwCJ3xpyP4qsLJH0yCoA26rH2zE2RzByhrTFTYZzbFEid3ddGiHOBEL+bO+2 GNtfiYKmbTkj1tMZJ8L6huKONaVrASFzLvZa2dlc2zja9ZSksKmge5BOTKWgbyepEc5qxSju YsYrX5xfLgTZC5abhhztpYhGBBgRAgAGBQI7HoVFAAoJEFqBr45q27IAlscAn2Ufk2d6/3p4 Cuyz/NX7KpL2dQ8WAJ9UD5JEakhfofed8PSqOM7jOO3LCA== Message-ID: <79ff8776-8308-ded5-450d-69a7c89c8e5b@daenzer.net> Date: Fri, 21 Dec 2018 16:51:31 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 In-Reply-To: <20181221132637.GR21184@phenom.ffwll.local> Content-Type: text/plain; charset=utf-8 Content-Language: en-CA Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2018-12-21 2:26 p.m., Daniel Vetter wrote: > On Fri, Dec 21, 2018 at 10:47:27AM +0100, Michel Dänzer wrote: >> On 2018-12-20 6:16 p.m., Michel Dänzer wrote: >>> On 2018-12-20 6:09 p.m., Daniel Vetter wrote: >>>> On Thu, Dec 20, 2018 at 6:03 PM Alex Deucher wrote: >>>>> On Thu, Dec 20, 2018 at 11:54 AM Daniel Vetter wrote: >>>> >>>>>> Not sure about the gamma thing since we had opposite bugs on i915 >>>>>> about gamma not being vsynced and tearing terribly. Cursor is special >>>>>> since it tends to be too small to notice tearing. >>>>> >>>>> Our cursor hw (and possibly gamma as well Nicholas? Harry?) is double >>>>> buffered, so we can update it any time for the most part and the >>>>> changes won't take affect until the next vupdate period. >>>> >>>> Hm, I guess we could make the gamma update optionally async, and let >>>> drivers deal. The issue is that the current async helper stuff won't >>>> cope with gamma updates (it's aimed at plane updates only, not at crtc >>>> property updates). Or we get userspace to do proper atomic updates. Or >>>> we do some faking in the kernel, e.g. waiting with the gamma update >>>> until the next atomic update happens. But that kinda breaks >>>> ->atomic_check. >>> >>> Would it be possible to merge gamma changes into a pending commit, if >>> there is one, and create a new commit otherwise? >>> >>> Otherwise the atomic API just moves this same problem to be solved by >>> userspace. >> >> Actually, I'm not sure this is even solvable in a Xorg driver. When it >> gets called to update the gamma LUT: >> >> 1. If there's a pending atomic commit, it cannot amend that, can it? > > Yup, but on the kernel side we kinda have the same problem. It's probably easier to solve in the kernel though; any solution allowing userspace to amend commits would likely need similar changes in the kernel anyway. >> 2. It has no way of knowing when the next atomic commit would be >> submitted e.g. for a page flip, so it kind of has to create its own >> commit for the gamma update. > > Block handler is what I had in mind for the fallback commit, if no other > commit happened meanwhile (which would need to include it). The BlockHandler runs more or less immediately after the gamma update, after any other X11 requests submitted later by the same client and flushed to the X server together. So this would still result in a commit with only the gamma update most of the time. There might be a small chance of combining with a flip with something like Night Light which is done by the compositor itself (but still only if the compositor defers the gamma update until just before it call SwapBuffers), basically 0 chance with something separate like RedShift. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer