[PATCH 00/11] PRIME Synchronization
agoins at nvidia.com
Wed Nov 25 18:39:24 PST 2015
For a while now, I've been working to fix tearing with PRIME.
These patches change the xserver to support setting up PRIME with double
buffering, and implement double buffered PRIME sink support in the
modesetting driver. In addition to these changes, I've been working to
upstream a couple of patches to the i915 DRM driver that mesh with these,
and have implemented double buffered PRIME source support in the NVIDIA
proprietary driver (pending release.)
They require the addition of a few ABI functions in pScreen:
(Enable/Disable)SharedPixmapFlipping - Functions to enable or disable
double buffered PRIME on the sink.
(Start/Stop)FlippingPixmapTracking - The double buffered counterparts
of (Start/Stop)PixmapTracking on the source.
PresentTrackedFlippingPixmap - A function exposed by the source driver
for the X server or sink driver to call to request a present on a given
shared pixmap. This way, presenting can be driven by the sink's
vblank instead of a timer or similar mechanism in the source.
The user may enable or disable PRIME Synchronization / Double Buffering via
an output property:
'xrandr --output <output> --set "PRIME Synchronization" <0 or 1>'
If either the sink or the source do not present the required ABI functions,
it will gracefully fall back to single buffered PRIME.
In its 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. For example, the source driver could
make PresentTrackedFlippingPixmap() fail if there is no damage, meaning a
present would be wasteful.
Some background on the DRM patches:
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.
DRM Tree: https://github.com/GoinsWithTheWind/drm-prime-sync
X Tree: https://github.com/GoinsWithTheWind/xserver-prime-sync
Thanks, Alex @ NVIDIA Linux Driver Team
Alex Goins (11):
randr: Factor out shared pixmap destruction
randr: Factor out shared pixmap creation
xf86: Bump ABI version to 21
xf86: Add PRIME flipping functions to ScreenRec
randr/xf86: Add PRIME Synchronization / Double Buffer
randr: Add ability to turn PRIME sync off
randr: Cleanup rrSetupPixmapSharing()
modesetting: Properly clean up w/ PRIME syncing
modesetting: Implement PRIME syncing as a sink
modesetting: Fix mmap leak in scanout_pixmap_cpu
modesetting: Suspend and resume flipping with DPMS
hw/xfree86/common/xf86Module.h | 2 +-
hw/xfree86/drivers/modesetting/driver.c | 35 +++++
hw/xfree86/drivers/modesetting/drmmode_display.c | 190 ++++++++++++++++++++++-
hw/xfree86/drivers/modesetting/drmmode_display.h | 8 +
hw/xfree86/modes/xf86Crtc.h | 4 +
hw/xfree86/modes/xf86RandR12.c | 4 +-
include/scrnintstr.h | 22 +++
randr/randrstr.h | 2 +
randr/rrcrtc.c | 165 ++++++++++++++++----
randr/rrprovider.c | 45 ++++++
10 files changed, 439 insertions(+), 38 deletions(-)
More information about the xorg-devel