[PATCH i915 v8 0/2] PRIME Synchronization

[Alex Goins]

Any more feedback on this?

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
> 
>