[PATCH 07/10] compositor-drm: Allow instant start of repaint loop. (v2)
Pekka Paalanen
ppaalanen at gmail.com
Fri Jul 3 06:29:40 PDT 2015
On Sun, 21 Jun 2015 21:25:14 +0200
Mario Kleiner <mario.kleiner.de at gmail.com> wrote:
> drm_output_start_repaint_loop() incurred a delay of
> one refresh cycle by using a no-op page-flip to get
> an accurate vblank timestamp as reference. This causes
> unwanted lag whenever Weston exited its repaint loop, e.g.,
> whenever an application wants to repaint with less than
> full video refresh rate but still minimum lag.
>
> Try to use the drmWaitVblank ioctl to get a proper
> timestamp instantaneously without lag. If that does
> not work, fall back to the old method of idle page-flip.
>
> This optimization will work on any drm/kms driver
> which supports high precision vblank timestamping.
> As of Linux 4.0 these would be intel, radeon and
> nouveau on all their supported gpu's.
>
> On kms drivers without instant high precision timestamping
> support, the kernel is supposed to return a timestamp
> of zero when calling drmWaitVblank() to query the current
> vblank count and time iff vblank irqs are currently
> disabled, because the only way to get a valid timestamp
> on such kms drivers is to enable vblank interrupts and
> then wait a bit for the next vblank irq to take a new valid
> timestamp. The caller is supposed to poll until at next
> vblank irq it gets a valid non-zero timestamp if it needs
> a timestamp.
>
> This zero-timestamp signalling works up to Linux 3.17, but
> got broken due to a regression in Linux 3.18 and later. On
> Linux 3.18+ with kms drivers that don't have high precision
> timestamping, the kernel erroneously returns a stale timestamp
> from an earlier vblank, ie. the vblank count and timestamp are
> mismatched. A patch is under way to fix this, but to deal with
> broken kernels, we also check non-zero timestamps if they are
> more than one refresh duration in the past, as this indicates
> a stale/invalid timestamp, so we need to take the page-flip
> fallback for restarting the repaint loop.
>
> v2: Implement review suggestions by Pekka Paalanen, especially
> extend the commit message to describe when and why the
> instant restart won't work due to missing Linux kernel
> functionality or a Linux kernel regression.
>
> Signed-off-by: Mario Kleiner <mario.kleiner.de at gmail.com>
> ---
> src/compositor-drm.c | 41 ++++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 40 insertions(+), 1 deletion(-)
>
> diff --git a/src/compositor-drm.c b/src/compositor-drm.c
> index aa6d010..5035611 100644
> --- a/src/compositor-drm.c
> +++ b/src/compositor-drm.c
> @@ -229,6 +229,9 @@ static const char default_seat[] = "seat0";
> static void
> drm_output_set_cursor(struct drm_output *output);
>
> +static void
> +drm_output_update_msc(struct drm_output *output, unsigned int seq);
> +
> static int
> drm_sprite_crtc_supported(struct drm_output *output, uint32_t supported)
> {
> @@ -708,6 +711,12 @@ err_pageflip:
> return -1;
> }
>
> +static int64_t
> +timespec_to_nsec(const struct timespec *a)
> +{
> + return (int64_t)a->tv_sec * 1000000000000LL + a->tv_nsec;
This makes picoseconds, not nanoseconds?
> +}
> +
> static void
> drm_output_start_repaint_loop(struct weston_output *output_base)
> {
> @@ -715,7 +724,13 @@ drm_output_start_repaint_loop(struct weston_output *output_base)
> struct drm_compositor *compositor = (struct drm_compositor *)
> output_base->compositor;
> uint32_t fb_id;
> - struct timespec ts;
> + struct timespec ts, tnow;
> + int ret;
> + drmVBlank vbl = {
> + .request.type = DRM_VBLANK_RELATIVE,
> + .request.sequence = 0,
> + .request.signal = 0,
> + };
>
> if (output->destroy_pending)
> return;
> @@ -725,6 +740,30 @@ drm_output_start_repaint_loop(struct weston_output *output_base)
> goto finish_frame;
> }
>
> + /* Try to get current msc and timestamp via instant query */
> + vbl.request.type |= drm_waitvblank_pipe(output);
> + ret = drmWaitVBlank(compositor->drm.fd, &vbl);
> +
> + /* Error return or zero timestamp means failure to get valid timestamp */
> + if ((ret == 0) && (vbl.reply.tval_sec > 0 || vbl.reply.tval_usec > 0)) {
> + ts.tv_sec = vbl.reply.tval_sec;
> + ts.tv_nsec = vbl.reply.tval_usec * 1000;
> +
> + /* Valid timestamp for most recent vblank - not stale? Stale ts could
> + * happen on Linux 3.17+, so make sure it is not older than 1 refresh
> + * duration since now.
> + */
> + weston_compositor_read_presentation_clock(&compositor->base, &tnow);
> + if (timespec_to_nsec(&tnow) - timespec_to_nsec(&ts) <
> + (1000000000000LL / output_base->current_mode->refresh)) {
However here the constant is correct, because refresh is milliHz.
To clarify things based on Daniel's suggestion, I'm going to post a patch
to introduce millihz_to_nsec().
> + drm_output_update_msc(output, vbl.reply.sequence);
> + weston_output_finish_frame(output_base, &ts,
> + PRESENTATION_FEEDBACK_INVALID);
> + return;
> + }
> + }
> +
> + /* Immediate query didn't provide valid timestamp. Use pageflip fallback */
> fb_id = output->current->fb_id;
>
> if (drmModePageFlip(compositor->drm.fd, output->crtc_id, fb_id,
I'm still in the middle of testing this patch. I just wanted to say
that I have a v3 of this patch already written, and if the testing
seems good, I'll post it. There will also be a squashed patch
replacing patch 9, and a patch to introduce shared/timespec-util.h.
I will also verify patch 8.
That will have to wait for next week, though. Happy weekend! .o/
That leaves patch 10 free for review and landing by others.
Thanks,
pq
More information about the wayland-devel
mailing list