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 > > _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
