Re: [PATCH i915 v8 0/2] PRIME Synchronization

[Daniel Vetter <daniel@ffwll.ch>]

On Tue, Dec 08, 2015 at 08:23:23PM -0800, Alex Goins wrote:
> Any more feedback on this?

Maarten reviewed them and they already landed in drm-intel-next-queued. I
guess he just forgot to send out a quick reply.

Thanks, Daniel

> 
> Thanks,
> Alex
> 
> On Thu, 26 Nov 2015, Alex Goins wrote:
> 
> > Hello all,
> > 
> > For a while now, I've been working to fix tearing with PRIME. This is the
> > same as the eighth version of the DRM component for PRIME synchronization,
> > 
> > In this version, use_mmio_flip() tests against
> > !reservation_object_test_signaled_rcu(test_all=FALSE) instead of directly
> > checking for an exclusive fence with obj->base.dma_buf->resv->fence_excl.
> > 
> > Repeat of overview below:
> > 
> > v1 was a more complicated patch set that added an additional fenced
> > interface to page flipping. To avoid adding additional interfaces on top of
> > a legacy path, v2 scrapped those patches and changed i915 page flipping
> > paths to wait on fences attached to DMA-BUF-backed fbs. Subsequent versions
> > involve incremental changes outlined in the patch descriptions.
> > 
> > I have two patches, one that implements fencing for i915's legacy mmio_flip
> > path, and one for atomic modesetting for futureproofing. Currently the
> > mmio_flip path is the one ultimately used by the X patches, due to the lack
> > of asynchronous atomic modesetting support in i915.
> > 
> > With my synchronization patches to X, it is possible to export two shared
> > buffers per crtc instead of just one. The sink driver uses the legacy
> > drmModePageFlip() to flip between the buffers, as the rest of the driver
> > has yet to be ported to atomics. In the pageflip/vblank event handler, the
> > sink driver requests a present from the source using the new X ABI function
> > pScreen->PresentTrackedFlippingPixmap(). If the call returns successfully,
> > it uses drmModePageFlip() to flip to the updated buffer, otherwise it waits
> > until the next vblank and tries again.
> > 
> > When the source driver presents on a given buffer, it first attaches a
> > fence.  The source driver is responsible for either using software
> > signaling or hardware semaphore-backed fences to ensure the fence is
> > signaled when the present is finished. If the sink's DRM driver implements
> > fencing in the flipping path, it will guarantee that that flip won't occur
> > until the present has finished.
> > 
> > This means that DRM drivers that don't implement fencing in their flipping
> > paths won't be able to guarantee 100% tear-free PRIME with my X patches.
> > However, the good news is that even without fencing, tearing is rare.
> > Generally presenting finishes before the next vblank, so there is no need
> > to wait on the fence. The X patches are a drastic improvement with or
> > without fencing, but the fencing is nonetheless important to guarantee
> > tear-free under all conditions.
> > 
> > To give some greater context, I've uploaded my branches for DRM and the X
> > server to Github. I'll move forward with upstreaming the X changes if and
> > when these DRM patches go in.
> > 
> > DRM Tree:    https://github.com/GoinsWithTheWind/drm-prime-sync
> > X Tree:      https://github.com/GoinsWithTheWind/xserver-prime-sync
> > 
> > (branch agoins-prime-v8)
> > 
> > Thanks, Alex @ NVIDIA Linux Driver Team
> > 
> > Alex Goins (2):
> >   i915: wait for fence in mmio_flip_work_func
> >   i915: wait for fence in prepare_plane_fb
> > 
> >  drivers/gpu/drm/i915/intel_display.c | 26 ++++++++++++++++++++++++++
> >  1 file changed, 26 insertions(+)
> > 
> > -- 
> > 1.9.1
> > 
> > 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel