Re: [RFC v2 0/7] drm: asynchronous atomic plane update

From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Gustavo Padovan <gustavo@padovan.org>,
	dri-devel@lists.freedesktop.org,
	Gustavo Padovan <gustavo.padovan@collabora.com>
Subject: Re: [RFC v2 0/7] drm: asynchronous atomic plane update
Date: Fri, 12 May 2017 12:04:37 +0300	[thread overview]
Message-ID: <20170512090437.GL12629@intel.com> (raw)
In-Reply-To: <20170511192956.GA2269@joana>

On Thu, May 11, 2017 at 04:29:56PM -0300, Gustavo Padovan wrote:
> 2017-05-09 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/
> > 
> > BTW I also realized recently that this is probably not going to work
> > w.r.t. per-crtc out fences. I know we agrees earlier that the
> > "return -1" trick would work, but now that I think about it again,
> > I don't think it actually will work when combined with non-blocking
> > commits since we can't decide whether to return -1 or a fence
> > until the commit has actually been performed.
> 
> What we agreed wasn't that the 1st request was going to return the

I presume you meant "was"

> out-fence and the subsequent requests modifying that request would
> return -1. How does that change with non-blocking?

With non-blocking the commit happens after the ioctl has returned to
userspace, so it's too late to return the -1.

I suppose one option would be to avoid in fences altogether. So we'd
do the synchronization in userspace, and then do a blocking commit
without in fences to get the out fence. But that would open the
thing up to more scheduling latencies and whatnot since userspace
would have to be involved more.

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel