public inbox for linux-kernel@vger.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: 21+ 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-13  4:02     ` Tomasz Figa
2018-12-14  1:35       ` Helen Koike
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:09                   ` Daniel Vetter
2018-12-20 17:16                     ` Michel Dänzer
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 18:34                       ` Daniel Vetter
2018-12-21  9:55                       ` Michel Dänzer
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox