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
Subject: Re: [RFC v2 0/7] drm: asynchronous atomic plane update
Date: Thu, 27 Apr 2017 15:36:50 -0300	[thread overview]
Message-ID: <20170427183650.GA2568@joana> (raw)
In-Reply-To: <20170427161034.GR30290@intel.com>

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

> On Thu, Apr 27, 2017 at 12:15:12PM -0300, Gustavo Padovan wrote:
> > From: Gustavo Padovan <gustavo.padovan@collabora.com>
> > 
> > Hi,
> > 
> > Second take of Asynchronous Plane Updates over Atomic. Here I looked
> > to msm, vc4 and i915 to identify a common pattern to create atomic helpers
> > for async updates. So in patch 1 drm_atomic_async_check() and
> > drm_atomic_helper_async_commit() are introduced along with driver's plane hooks:
> > ->atomic_async_check() and ->atomic_async_commit().
> > 
> > For now we only support async update for one plane at a time. Also the async
> > update can't modify the CRTC so no modesets are allowed.
> > 
> > Then the other patches add support for it in the drivers. I did virtio mostly
> > for testing. i915 have been converted and I've been using it without any
> > problem. IGT tests seems to be fine, but there are somewhat random failures
> > with or without the async update changes. msm and vc4 are only compile-tested.
> > So I think this needs more testing
> > 
> > I started IGT changes to test the Atomic IOCTL with the new flag:
> > 
> > https://git.collabora.com/cgit/user/padovan/intel-gpu-tools.git/
> > 
> > v2:
> > 
> > Apart from all comments on v1 one extra change I made was to remove the
> > constraint of only updating the plane if the queued state didn't touch
> > that plane. I believe it was a too cautious of a change, furthermore this
> > constraint was affecting throughput negatively on i915.
> 
> So you're now allowing reordering the updates? As in update A is
> scheduled before update B, but update B happens before update A.
> That is not a good idea.

That is what already happens with legacy cursor updates. They jump ahead
the scheduled update and apply the cursor update. What we propose here
is to do this over atomic when DRM_MODE_ATOMIC_ASYNC_UPDATE flag is set.
Async PageFlips should use the same infrastructure in the future.

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

  reply	other threads:[~2017-04-27 18:36 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
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 [this message]
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=20170427183650.GA2568@joana \
    --to=gustavo@padovan.org \
    --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.