All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gustavo Padovan <gustavo@padovan.org>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: Gustavo Padovan <gustavo.padovan@collabora.com>,
	dri-devel@lists.freedesktop.org,
	Daniel Vetter <daniel.vetter@intel.com>
Subject: Re: [RFC v2 1/7] drm/atomic: initial support for asynchronous plane update
Date: Thu, 27 Apr 2017 16:35:37 -0300	[thread overview]
Message-ID: <20170427193537.GB2568@joana> (raw)
In-Reply-To: <20170427153710.GO30290@intel.com>

Hi Ville,

2017-04-27 Ville Syrjälä <ville.syrjala@linux.intel.com>:

> On Thu, Apr 27, 2017 at 12:15:13PM -0300, Gustavo Padovan wrote:
> > From: Gustavo Padovan <gustavo.padovan@collabora.com>
> > 
> > In some cases, like cursor updates, it is interesting to update the
> > plane in an asynchronous fashion to avoid big delays. The current queued
> > update could be still waiting for a fence to signal and thus block any
> > subsequent update until its scan out. In cases like this if we update the
> > cursor synchronously through the atomic API it will cause significant
> > delays that would even be noticed by the final user.
> > 
> > This patch creates a fast path to jump ahead the current queued state and
> > do single planes updates without going through all atomic step in
> > drm_atomic_helper_commit().
> > 
> > We take this path for legacy cursor updates. Users can also set the
> > DRM_MODE_ATOMIC_ASYNC_UPDATE flag on atomic updates.
> > 
> > For now only single plane updates are supported, but we plan to support
> > multiple planes updates and async PageFlips through this interface as well
> > in the near future.
> > 
> > v2:
> > 	- allow updates even if there is a queued update for the same
> > 	plane.
> >         - fixes on the documentation (Emil Velikov)
> >         - unconditionally call ->atomic_async_update (Emil Velikov)
> >         - check for ->atomic_async_update earlier (Daniel Vetter)
> >         - make ->atomic_async_check() the last step (Daniel Vetter)
> >         - add ASYNC_UPDATE flag (Eric Anholt)
> >         - update state in core after ->atomic_async_update (Eric Anholt)
> > 	- update docs (Eric Anholt)
> > 
> > Cc: Daniel Vetter <daniel.vetter@intel.com>
> > Cc: Rob Clark <robdclark@gmail.com>
> > Cc: Eric Anholt <eric@anholt.net>
> > Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.com>
> > ---
> >  drivers/gpu/drm/drm_atomic.c             | 50 ++++++++++++++++++++++++++++++++
> >  drivers/gpu/drm/drm_atomic_helper.c      | 48 ++++++++++++++++++++++++++++++
> >  include/drm/drm_atomic.h                 |  2 ++
> >  include/drm/drm_atomic_helper.h          |  2 ++
> >  include/drm/drm_modeset_helper_vtables.h | 45 ++++++++++++++++++++++++++++
> >  include/uapi/drm/drm_mode.h              |  4 ++-
> >  6 files changed, 150 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index 30229ab..7b60cf8 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -77,6 +77,7 @@ drm_atomic_state_init(struct drm_device *dev, struct drm_atomic_state *state)
> >  	 * setting this appropriately?
> >  	 */
> >  	state->allow_modeset = true;
> > +	state->async_update = true;
> >  
> >  	state->crtcs = kcalloc(dev->mode_config.num_crtc,
> >  			       sizeof(*state->crtcs), GFP_KERNEL);
> > @@ -631,6 +632,51 @@ static int drm_atomic_crtc_check(struct drm_crtc *crtc,
> >  	return 0;
> >  }
> >  
> > +static bool drm_atomic_async_check(struct drm_atomic_state *state)
> > +{
> > +	struct drm_crtc *crtc;
> > +	struct drm_crtc_state *crtc_state;
> > +	struct drm_plane *__plane, *plane = NULL;
> > +	struct drm_plane_state *__plane_state, *plane_state = NULL;
> > +	const struct drm_plane_helper_funcs *funcs;
> > +	int i, n_planes = 0;
> > +
> > +	for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
> > +		if (drm_atomic_crtc_needs_modeset(crtc_state))
> > +			return false;
> > +	}
> > +
> > +	for_each_new_plane_in_state(state, __plane, __plane_state, i) {
> > +		n_planes++;
> > +		plane = __plane;
> > +		plane_state = __plane_state;
> > +	}
> > +
> > +	/* FIXME: we support single plane updates for now */
> > +	if (!plane || n_planes != 1)
> > +		return false;
> > +
> > +	funcs = plane->helper_private;
> > +	if (!funcs->atomic_async_update)
> > +		return false;
> > +
> > +	if (plane_state->fence)
> > +		return false;
> > +
> > +	if (!plane->state->crtc || (plane->state->crtc != plane_state->crtc))
> > +		return false;
> > +
> > +	/* No configuring new scaling in the async path. */
> 
> Those checks aren't really about scaling. Well, they are also about
> scaling, but they're mainly about changing size.

I just copied the comment from the previous code in the drivers...
I can fix it.

> 
> What I don't really understand is why we're enforcing these restrictions
> in the core but leaving other restrictions up to the driver. I don't see
> size changes as anything really special compared to many of the other
> restrictions that would now be up to each driver.

Because I extracted what was common between msm, vc4 and i915 on their
legacy cursor update calls. I didn't want to enforce anything else in
core for now.

> 
> If you're really after some lowest common denominator as far as
> exposed capabilities are concerned then I think the core should do
> more checking. OTOH if you're not interested limiting what each
> driver exposes then I don't see why the core checks anything at all.

I think a common denominator is what we want but we only have 3 drivers
using it at the moment. We can look for more checks that shoud be done
is core. Any suggestions?

> 
> > +	if (plane->state->crtc_w != plane_state->crtc_w ||
> > +	    plane->state->crtc_h != plane_state->crtc_h ||
> > +	    plane->state->src_w != plane_state->src_w ||
> > +	    plane->state->src_h != plane_state->src_h) {
> > +		return false;
> > +	}
> > +
> > +	return !funcs->atomic_async_check(plane, plane_state);
> > +}
> > +
> >  static void drm_atomic_crtc_print_state(struct drm_printer *p,
> >  		const struct drm_crtc_state *state)
> >  {
> <snip> 
> >  /**
> > diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> > index 8c67fc0..7c067ca 100644
> > --- a/include/uapi/drm/drm_mode.h
> > +++ b/include/uapi/drm/drm_mode.h
> > @@ -646,13 +646,15 @@ struct drm_mode_destroy_dumb {
> >  #define DRM_MODE_ATOMIC_TEST_ONLY 0x0100
> >  #define DRM_MODE_ATOMIC_NONBLOCK  0x0200
> >  #define DRM_MODE_ATOMIC_ALLOW_MODESET 0x0400
> > +#define DRM_MODE_ATOMIC_ASYNC_UPDATE 0x0800
> 
> What exactly is that flag supposed to mean?

I don't think I provided a good explanation for it, sorry. This flag
tells core to jump ahead the queued update if the conditions in 
drm_atomic_async_check() are met. Useful for cursors and async PageFlips
over the atomic ioctl.

Gustavo
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2017-04-27 19:35 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-27 15:15 [RFC v2 0/7] drm: asynchronous atomic plane update Gustavo Padovan
2017-04-27 15:15 ` [RFC v2 1/7] drm/atomic: initial support for asynchronous " Gustavo Padovan
2017-04-27 15:37   ` Ville Syrjälä
2017-04-27 19:35     ` Gustavo Padovan [this message]
2017-04-28  8:57       ` Ville Syrjälä
2017-04-28 14:04         ` Gustavo Padovan
2017-04-27 15:15 ` [RFC v2 2/7] drm/virtio: support async cursor updates Gustavo Padovan
2017-04-27 15:15 ` [RFC v2 3/7] drm/i915: update cursors asynchronously through atomic Gustavo Padovan
2017-04-27 15:41   ` Ville Syrjälä
2017-04-27 19:39     ` Gustavo Padovan
2017-04-28  8:58       ` Ville Syrjälä
2017-04-27 15:15 ` [RFC v2 4/7] drm/i915: remove intel_cursor_plane_funcs Gustavo Padovan
2017-04-27 15:15 ` [RFC v2 5/7] drm/msm: update cursors asynchronously through atomic Gustavo Padovan
2017-04-27 15:15 ` [RFC v2 6/7] drm/msm: remove mdp5_cursor_plane_funcs Gustavo Padovan
2017-04-27 15:15 ` [RFC v2 7/7] drm/vc4: update cursors asynchronously through atomic Gustavo Padovan
2017-04-27 16:10 ` [RFC v2 0/7] drm: asynchronous atomic plane update Ville Syrjälä
2017-04-27 18:36   ` Gustavo Padovan
2017-04-28  8:53     ` Ville Syrjälä
2017-04-28 14:28       ` Gustavo Padovan
2017-05-09 14:02 ` Ville Syrjälä
2017-05-11 19:29   ` Gustavo Padovan
2017-05-12  9:04     ` Ville Syrjälä

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=20170427193537.GB2568@joana \
    --to=gustavo@padovan.org \
    --cc=daniel.vetter@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gustavo.padovan@collabora.com \
    --cc=ville.syrjala@linux.intel.com \
    /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.