2017-05-09 Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx>: > On Thu, Apr 27, 2017 at 12:15:12PM -0300, Gustavo Padovan wrote: > > From: Gustavo Padovan <gustavo.padovan@xxxxxxxxxxxxx> > > > > 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
