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