public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Matt Roper <matthew.d.roper@intel.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 0/4] More nuclear pageflip
Date: Sat, 31 Jan 2015 12:22:15 -0800	[thread overview]
Message-ID: <20150131202215.GB30483@mattrope.com> (raw)
In-Reply-To: <20150131093531.GL14009@phenom.ffwll.local>

On Sat, Jan 31, 2015 at 10:35:32AM +0100, Daniel Vetter wrote:
> On Fri, Jan 30, 2015 at 04:22:35PM -0800, Matt Roper wrote:
> > The first two patches here were already posted earlier this week; they allow
> > our legacy plane updates to make use of the main atomic helpers rather than the
> > transitional atomic helpers.  This shouldn't have any functional change, but it
> > will cause us to exercise the full atomic pipeline rather than just the plane
> > subset of it.
> > 
> > The third patch is the interesting one; it allows us to handle nuclear pageflip
> > requests in a non-blocking manner and deliver a uevent upon completion.  This
> > is important functionality for compositors since it allows them to request that
> > the kernel perform a flip, then continue on doing other work while they wait
> > for the flip to actually happen.
> > 
> > The final patch here switches our legacy pageflip ioctl to use the atomic
> > helper (thus exercising the new asynchronous support added in patch #3).
> > Removing the i915-specific pageflip handling should allow us to drop a bunch of
> > our display code; I've been somewhat conservative in my code removal for now
> > (just enough to get rid of the 'function unused' compiler warnings); we can do
> > further cleanup of code that relates to the legacy pageflip pipeline in a
> > future patchset.
> 
> Our current mmio flip doesn't work on gen4 and earlier because the flip
> completion event generation only works with MI_ flips. So I think we need
> to (at least for now) keep the legacy flip code around and wired up for
> those platforms.
> 
> But we need to redo the flip completion anyway (and probably just key off
> the next vblank interrupt) since if you'd do an atomic flip with just
> sprites the event stuff wont work on any platform. Once we have that we
> can then also roll out the legacy-pageflip-on-atomic for older platforms.
> -Daniel

Hmm, my code at the moment sends the completion event to userspace and
marks the CRTC as no longer having a flip pending after
drm_atomic_helper_wait_for_vblanks(dev, state) call, which probably
works when we're actually updating the framebuffer, but I guess that
will send the uevent too early in cases where the fb doesn't change
(since we already made a point of optimizing out that unnecessary vblank
wait).

So maybe I should just get the "schedule stuff for future vblank"
mechanism done that I already had on my plate for the watermark stuff,
and then use that to send the uevent once the next vblank following the
commit happens.

It occurs to me that I probably need to take a look at all the i915
hangcheck/recovery stuff too; I haven't paid much attention to how that
works, but I'm guessing it probably needs to be updated a bit now as
well.


Matt

> 
> > 
> > Matt Roper (4):
> >   drm/i915: Keep plane->state updated on pageflip
> >   drm/i915: Switch planes from transitional helpers to full atomic
> >     helpers
> >   drm/i915: Enable asynchronous nuclear flips
> >   drm/i915: Use atomic helper for pageflips
> > 
> >  drivers/gpu/drm/i915/i915_drv.h      |   9 +-
> >  drivers/gpu/drm/i915/i915_params.c   |   5 -
> >  drivers/gpu/drm/i915/intel_atomic.c  | 162 ++++++--
> >  drivers/gpu/drm/i915/intel_display.c | 716 +----------------------------------
> >  drivers/gpu/drm/i915/intel_drv.h     |   8 +
> >  drivers/gpu/drm/i915/intel_lrc.c     |   3 +-
> >  6 files changed, 155 insertions(+), 748 deletions(-)
> > 
> > -- 
> > 1.8.5.1
> > 
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

      reply	other threads:[~2015-01-31 20:22 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-31  0:22 [PATCH 0/4] More nuclear pageflip Matt Roper
2015-01-31  0:22 ` [PATCH 1/4] drm/i915: Keep plane->state updated on pageflip Matt Roper
2015-01-31  9:36   ` Daniel Vetter
2015-01-31  0:22 ` [PATCH 2/4] drm/i915: Switch planes from transitional helpers to full atomic helpers Matt Roper
2015-01-31  0:22 ` [PATCH 3/4] drm/i915: Enable asynchronous nuclear flips Matt Roper
2015-01-31  9:30   ` Daniel Vetter
2015-01-31 20:07     ` Matt Roper
2015-02-02  9:36       ` Daniel Vetter
2015-01-31  0:22 ` [PATCH 4/4] drm/i915: Use atomic helper for pageflips Matt Roper
2015-01-31  9:35 ` [PATCH 0/4] More nuclear pageflip Daniel Vetter
2015-01-31 20:22   ` Matt Roper [this message]

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=20150131202215.GB30483@mattrope.com \
    --to=matthew.d.roper@intel.com \
    --cc=daniel@ffwll.ch \
    --cc=intel-gfx@lists.freedesktop.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