All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: "Michel Dänzer" <michel@daenzer.net>
Cc: "Daniel Vetter" <daniel@ffwll.ch>,
	"Alex Deucher" <alexdeucher@gmail.com>,
	dnicoara@chromium.org, "Stéphane 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
Date: Fri, 21 Dec 2018 14:26:37 +0100	[thread overview]
Message-ID: <20181221132637.GR21184@phenom.ffwll.local> (raw)
In-Reply-To: <9be83a7f-aa5f-8d8f-0486-db68e12c5feb@daenzer.net>

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

  reply	other threads:[~2018-12-21 13:26 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-23 21:53 [PATCH] drm: add capability DRM_CAP_ASYNC_UPDATE Helen Koike
2018-11-27 13:34 ` Ville Syrjälä
2018-12-05 16:12   ` Helen Koike
2018-12-05 16:12     ` Helen Koike
2018-12-13  4:02     ` Tomasz Figa
2018-12-14  1:35       ` Helen Koike
2018-12-20  9:07         ` Tomasz Figa
2018-12-20  9:07           ` Tomasz Figa
2018-12-20 10:47           ` Daniel Vetter
2018-12-20 16:40             ` Alex Deucher
2018-12-20 16:54               ` Daniel Vetter
2018-12-20 17:03                 ` Alex Deucher
2018-12-20 17:03                   ` Alex Deucher
2018-12-20 17:09                   ` Daniel Vetter
2018-12-20 17:16                     ` Michel Dänzer
2018-12-20 17:24                       ` Daniel Vetter
2018-12-20 17:24                         ` Daniel Vetter
2018-12-21  9:47                       ` Michel Dänzer
2018-12-21 13:26                         ` Daniel Vetter [this message]
2018-12-21 15:51                           ` Michel Dänzer
2018-12-20 17:38                     ` Kazlauskas, Nicholas
2018-12-20 17:38                       ` Kazlauskas, Nicholas
2018-12-20 18:34                       ` Daniel Vetter
2018-12-20 18:34                         ` Daniel Vetter
2018-12-21  9:55                       ` Michel Dänzer
2018-12-21  9:55                         ` Michel Dänzer
2018-12-21  3:51             ` Tomasz Figa
2018-12-21  3:51               ` Tomasz Figa
2018-12-21 13:42               ` Daniel Vetter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181221132637.GR21184@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=airlied@linux.ie \
    --cc=alexandros.frantzis@collabora.com \
    --cc=alexdeucher@gmail.com \
    --cc=dnicoara@chromium.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gustavo.padovan@collabora.com \
    --cc=helen.koike@collabora.com \
    --cc=kernel@collabora.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcheu@google.com \
    --cc=michel@daenzer.net \
    --cc=nicholas.kazlauskas@amd.com \
    --cc=seanpaul@google.com \
    --cc=tfiga@chromium.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.