Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Fri, 21 Dec 2018 14:26:37 +0100
From:   Daniel Vetter <daniel@ffwll.ch>
To:     Michel =?iso-8859-1?Q?D=E4nzer?= <michel@daenzer.net>
Cc:     Daniel Vetter <daniel@ffwll.ch>,
        Alex Deucher <alexdeucher@gmail.com>, dnicoara@chromium.org,
        =?iso-8859-1?Q?St=E9phane?= Marchesin <marcheu@google.com>,
        Sean Paul <seanpaul@google.com>,
        Alexandros Frantzis <alexandros.frantzis@collabora.com>,
        David Airlie <airlied@linux.ie>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        dri-devel <dri-devel@lists.freedesktop.org>,
        Tomasz Figa <tfiga@chromium.org>,
        Gustavo Padovan <gustavo.padovan@collabora.com>,
        Helen Koike <helen.koike@collabora.com>, kernel@collabora.com,
        "Kazlauskas, Nicholas" <nicholas.kazlauskas@amd.com>
Subject: Re: [PATCH] drm: add capability DRM_CAP_ASYNC_UPDATE
Message-ID: <20181221132637.GR21184@phenom.ffwll.local>
Mail-Followup-To: Michel =?iso-8859-1?Q?D=E4nzer?= <michel@daenzer.net>,
        Alex Deucher <alexdeucher@gmail.com>, dnicoara@chromium.org,
        =?iso-8859-1?Q?St=E9phane?= Marchesin <marcheu@google.com>,
        Sean Paul <seanpaul@google.com>,
        Alexandros Frantzis <alexandros.frantzis@collabora.com>,
        David Airlie <airlied@linux.ie>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        dri-devel <dri-devel@lists.freedesktop.org>,
        Tomasz Figa <tfiga@chromium.org>,
        Gustavo Padovan <gustavo.padovan@collabora.com>,
        Helen Koike <helen.koike@collabora.com>, kernel@collabora.com,
        "Kazlauskas, Nicholas" <nicholas.kazlauskas@amd.com>
References: <CAAFQd5BczTNdwUNcx42hC=OKkgZTV9JevHetYOjfDCnEz29LpA@mail.gmail.com>
 <0a0a35bf-69e4-8dcd-46fc-7053081480d5@collabora.com>
 <CAAFQd5C15yF4TwOLu4JsFGMSzLp8isV89WOZyRfv9wCcGfFRtg@mail.gmail.com>
 <CAKMK7uG=vdaTo25b3gSaD4T2naA51VeaVL0+5YAJ9HMrBziTWQ@mail.gmail.com>
 <CADnq5_P9nsquCV95CSZC4NCr7YNJ76ZmCruJA=f1N8dLGYm=ow@mail.gmail.com>
 <CAKMK7uHu5XMQzr7ocVEcpDS9H6pQ-BHfHNE51_YK7rLkTQC_9g@mail.gmail.com>
 <CADnq5_P1smiGhYyoZQsEAJG0+jBx6f75HwEFAf2RkaoNp0HEiA@mail.gmail.com>
 <CAKMK7uGSiBv9H_xAj2fuk=XYocefQU4bFk+fPr=iWGsaPxOwhw@mail.gmail.com>
 <fb45217c-d9ad-b208-d55d-51299ead108b@daenzer.net>
 <9be83a7f-aa5f-8d8f-0486-db68e12c5feb@daenzer.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <9be83a7f-aa5f-8d8f-0486-db68e12c5feb@daenzer.net>
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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 <alexdeucher@gmail.com> wrote:
> >>> On Thu, Dec 20, 2018 at 11:54 AM Daniel Vetter <daniel@ffwll.ch> 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.

> 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).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch