From: Alex Goins <agoins@nvidia.com>
To: dri-devel@lists.freedesktop.org
Subject: [PATCH drm 0/6] PRIME Synchronization
Date: Thu, 22 Oct 2015 13:00:53 -0700 [thread overview]
Message-ID: <cover.1445484053.git.agoins@nvidia.com> (raw)
Hello all,
For a while now, I've been working to fix tearing with PRIME. I have a working
solution that requires changes to DRM, libdrm, and the X server. I've also
implemented sink support in the modesetting driver, and source support in the
NVIDIA proprietary driver.
These DRM patches ultimately provide a new ioctl, DRM_IOCTL_PRIME_PAGE_FLIP,
that sets up a fence on a PRIME member's DMA-BUF reservation object with a
callback to schedule a flip to the associated fb.
With my synchronization patches to X, it is possible to export two shared
buffers per crtc instead of just one. The sink driver uses
DRM_IOCTL_PRIME_PAGE_FLIP to set up fences on each of these buffers. When the
source driver is done presenting on a given buffer, it signals the associated
fence, and the sink flips on the next vblank. In the page flip event handler,
the sink driver uses the ioctl to set up another fence, and explicitly requests
a present on the current back buffer using a new function in the X ABI. Thus,
flips are driven by presents, presents are driven by flips, and the whole thing
conforms to the sink's refresh rate.
Right now, the part that signals the fence is a vendor-specific ioctl, but I'm
open to factoring it out into a core DRM ioctl and DRM driver function helper
like DRM_IOCTL_PRIME_PAGE_FLIP if it would make implementing source support
easier for open source drivers.
Due to the lack of asynchronous atomic modesetting support on i915 (the sink of
most hybrid graphics systems,) I've implemented this on top of the old page_flip
method. Perhaps an atomic modesetting / nuclear pageflip based method would be
better, but it wouldn't be as viable without widespread asynchronous support.
I'm willing to implement an atomic modesetting version if required, but it's
less clear what the best implementation would be: perhaps a fence property that
defers asynchronous commits. There are enough ways to do it that it probably
warrants prior discussion. Nonetheless, this method is necessary at least as a
fallback until i915 supports asynchronous atomic modesetting.
To give some greater context, I've uploaded my branches for DRM, libdrm, and the
X server to Github. I'll move forward with upstreaming the libdrm and X changes
if and when these DRM patches go in.
DRM Tree: https://github.com/GoinsWithTheWind/drm-prime-sync
libdrm Tree: https://github.com/GoinsWithTheWind/libdrm-prime-sync
X Tree: https://github.com/GoinsWithTheWind/xserver-prime-sync
Thanks,
Alex @ NVIDIA Linux Driver Team
agoins (6):
drm: factor out drm_mode_page_flip_ioctl()
drm: generalize drm_prime_lookup
drm: add fence context
drm: add drm_gem_prime_page_flip() helper
drm: add prime_page_flip() driver function
drm: add DRM_IOCTL_PRIME_PAGE_FLIP
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 +
drivers/gpu/drm/armada/armada_drv.c | 1 +
drivers/gpu/drm/drm_crtc.c | 90 ++++++++----
drivers/gpu/drm/drm_internal.h | 2 +
drivers/gpu/drm/drm_ioctl.c | 1 +
drivers/gpu/drm/drm_prime.c | 213 ++++++++++++++++++++++++++--
drivers/gpu/drm/exynos/exynos_drm_drv.c | 1 +
drivers/gpu/drm/i915/i915_drv.c | 1 +
drivers/gpu/drm/imx/imx-drm-core.c | 1 +
drivers/gpu/drm/msm/msm_drv.c | 1 +
drivers/gpu/drm/nouveau/nouveau_drm.c | 1 +
drivers/gpu/drm/omapdrm/omap_drv.c | 1 +
drivers/gpu/drm/qxl/qxl_drv.c | 1 +
drivers/gpu/drm/radeon/radeon_drv.c | 1 +
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 1 +
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 1 +
drivers/gpu/drm/shmobile/shmob_drm_drv.c | 1 +
drivers/gpu/drm/sti/sti_drv.c | 1 +
drivers/gpu/drm/tegra/drm.c | 1 +
drivers/gpu/drm/udl/udl_drv.c | 1 +
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 1 +
include/drm/drmP.h | 8 ++
include/drm/drm_crtc.h | 4 +
include/uapi/drm/drm.h | 10 ++
24 files changed, 303 insertions(+), 42 deletions(-)
--
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-22 20:01 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-22 20:00 Alex Goins [this message]
2015-10-22 20:00 ` [PATCH drm 1/6] drm: factor out drm_mode_page_flip_ioctl() Alex Goins
2015-10-22 20:00 ` [PATCH drm 2/6] drm: generalize drm_prime_lookup Alex Goins
2015-10-22 20:00 ` [PATCH drm 3/6] drm: add fence context Alex Goins
2015-10-22 20:00 ` [PATCH drm 4/6] drm: add drm_gem_prime_page_flip() helper Alex Goins
2015-10-22 20:25 ` Daniel Vetter
2015-10-22 21:31 ` Alexander Goins
2015-10-22 22:11 ` Daniel Vetter
2015-10-23 12:55 ` Daniel Stone
2015-10-22 20:00 ` [PATCH drm 5/6] drm: add prime_page_flip() driver function Alex Goins
2015-10-22 20:00 ` [PATCH drm 6/6] drm: add DRM_IOCTL_PRIME_PAGE_FLIP Alex 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.1445484053.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.