[PATCH] drm: add capability DRM_CAP_ASYNC_UPDATE

[Daniel Vetter]

On Thu, Dec 20, 2018 at 6:16 PM Michel Dänzer <michel at daenzer.net> wrote:
>
> On 2018-12-20 6:09 p.m., Daniel Vetter wrote:
> > On Thu, Dec 20, 2018 at 6:03 PM Alex Deucher <alexdeucher at gmail.com> wrote:
> >> On Thu, Dec 20, 2018 at 11:54 AM Daniel Vetter <daniel at 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.

I guess possible, depending upon how much you want to type. The problem is:
- stopping the current commit before it gets too far
- without causing stutter in itself (we don't want a stream of cursor
updates to livelock pageflips)
- re-running atomic_check on the new combined commit (which I guess
means you somehow need a clean starting state again and apply both
updates, which currently isn't possible)
- push it out as a commit

Alternatively is some fudging in the backend like we do now have some
support for for async plane updates. We'd need the full trickery with
a dedicated async_update_check though, at least on i915 we need to (in
some cases) make sure the gamma ramp is monotonic and stuff like that.

Or we just give up on commone semantics on this and have legacy gamma
updates bypass atomic in dc somehow (which would be the unstructured
version of the above).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch