From: Alex Goins <agoins@nvidia.com>
To: dri-devel@lists.freedesktop.org
Subject: [PATCH i915 v2 0/2] PRIME Synchronization
Date: Fri, 30 Oct 2015 18:03:49 -0700 [thread overview]
Message-ID: <cover.1446246896.git.agoins@nvidia.com> (raw)
Hello all,
For a while now, I've been working to fix tearing with PRIME. This is my second
version of the solution, revised according to Daniel Vetter's and Daniel Stone's
suggestions.
Rather than using fence callbacks to explicitly trigger flipping, fences are now
used to block flipping/atomic commits up to a timeout of 96 ms, based on Daniel
Stone's non-upstreamed patch to the Exynos DRM driver. I have two patches, one
that implements fencing for i915's legacy mmio_flip path, and one for atomic
commits 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-v2)
Thanks,
Alex @ NVIDIA Linux Driver Team
Alex Goins (2):
i915: wait for fences in mmio_flip()
i915: wait for fences in atomic commit
drivers/gpu/drm/i915/intel_display.c | 37 ++++++++++++++++++++++++++++++++++++
1 file changed, 37 insertions(+)
--
1.9.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
next reply other threads:[~2015-10-31 1:03 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-31 1:03 Alex Goins [this message]
2015-10-31 1:03 ` [PATCH i915 v2 1/2] i915: wait for fences in mmio_flip() Alex Goins
2015-11-02 11:21 ` Chris Wilson
2015-11-09 21:42 ` Alexander Goins
2015-11-16 15:15 ` Daniel Vetter
2015-11-16 18:32 ` Alexander Goins
2015-10-31 1:03 ` [PATCH i915 v2 2/2] i915: wait for fences in atomic commit Alex Goins
2015-11-02 15:06 ` Maarten Lankhorst
2015-11-09 21:42 ` Alexander Goins
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cover.1446246896.git.agoins@nvidia.com \
--to=agoins@nvidia.com \
--cc=dri-devel@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.