diff options
author | Daniel Vetter <daniel.vetter@ffwll.ch> | 2018-04-05 17:44:46 +0200 |
---|---|---|
committer | Daniel Vetter <daniel.vetter@ffwll.ch> | 2018-04-24 14:01:15 +0200 |
commit | 30d23f220c75cf58584b19929bd8460b4edc9771 (patch) | |
tree | 04fec21fe51c60391f5b60fd838ce31d53ef80e6 /drivers/gpu/drm/drm_atomic.c | |
parent | 244cb3dd22e429e183d06fe0db55ea3ebf1fef19 (diff) |
drm/atomic: better doc for implicit vs explicit fencing
Note that a pile of drivers don't seem to take implicit fencing into
account, or at least don't call drm_atoimc_set_fence_for_plane().
Cc'ing relevant people, or at least some. Some drivers also look like
they don't disable implicit fencing (e.g. amdgpu) because the explicit
fences and implicit fences are handled by entirely independent code
paths.
I also wonder whether we shouldn't just make the recommended helpers
the default ones, since a lot of drivers don't bother to handle the
implicit fences at all it seems. The helpers won't blow up even for
non-GEM drivers or GEM drivers which don't fill out the gem bo
pointers in struct drm_framebuffer.
v2: Comments from Eric.
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Sinclair Yeh <syeh@vmware.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Gustavo Padovan <gustavo@padovan.org>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180405154449.23038-7-daniel.vetter@ffwll.ch
Diffstat (limited to 'drivers/gpu/drm/drm_atomic.c')
-rw-r--r-- | drivers/gpu/drm/drm_atomic.c | 8 |
1 files changed, 8 insertions, 0 deletions
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c index 3d9ae057a6cd..9bdd67781917 100644 --- a/drivers/gpu/drm/drm_atomic.c +++ b/drivers/gpu/drm/drm_atomic.c @@ -1496,6 +1496,14 @@ EXPORT_SYMBOL(drm_atomic_set_fb_for_plane); * Otherwise, if &drm_plane_state.fence is not set this function we just set it * with the received implicit fence. In both cases this function consumes a * reference for @fence. + * + * This way explicit fencing can be used to overrule implicit fencing, which is + * important to make explicit fencing use-cases work: One example is using one + * buffer for 2 screens with different refresh rates. Implicit fencing will + * clamp rendering to the refresh rate of the slower screen, whereas explicit + * fence allows 2 independent render and display loops on a single buffer. If a + * driver allows obeys both implicit and explicit fences for plane updates, then + * it will break all the benefits of explicit fencing. */ void drm_atomic_set_fence_for_plane(struct drm_plane_state *plane_state, |