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

[Gustavo Padovan]

2017-05-09 Ville Syrjälä <ville.syrjala at linux.intel.com>:

> On Thu, Apr 27, 2017 at 12:15:12PM -0300, Gustavo Padovan wrote:
> > From: Gustavo Padovan <gustavo.padovan at 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
out-fence and the subsequent requests modifying that request would
return -1. How does that change with non-blocking?

Gustavo