[Intel-gfx] [RFC 1/4] time: export getnstime_raw_and_real for DRM
Imre Deak
imre.deak at intel.com
Mon Oct 8 13:35:34 CEST 2012
On Sat, 2012-10-06 at 03:41 +0200, Mario Kleiner wrote:
> [...]
>
> But then Psychtoolbox checks each timestamp it gets from somewhere
> "outside" (OML_sync_control / INTEL_swap_events / ALSA audio timestamps,
> network receive timestamps, evdev, x11, ...) if it is in gettimeofday()
> aka CLOCK_REALTIME aka wall time or in CLOCK_MONOTONIC time and just
> remaps to whatever its reference clock is.
>
> There's no way around this than to have no fixed expectations, but to
> remap stuff on the fly, because different parts of the Linux universe
> have decided on different time bases, or even switched somewhere from
> one kernel version to the next in the last years, e.g., ALSA, which at
> some time switched from wall clock to CLOCK_MONOTONIC. Sometimes
> clock_gettime() wasn't available at all in older setups, so there only
> was gettimeofday(). Or toolkits like GStreamer use different timebases
> dependent on OS and sometimes even on plugins.
>
> I would expect that other timing sensitive apps have to have ways to
> handle this in similar ways.
I think the question is, can we be sure? I don't think there is any
guarantee that random application X will not be confused by an
unconditional switch to monotonic timestamps.
> Wrt. to the drm vblank/pageflip timestamps, the userspace extensions
> which expose these (INTEL_swap_events, OML_sync_control) don't allow
> apps to select which timebase to use, they define monotonic time as what
> is returned, so i don't know how a userspace app could actually ask the
> DRM for one or the other format? So i guess just switching to
> CLOCK_MONOTONIC shouldn't be that bad.
An application could just use the kernel DRM interface directly. I admit
this is not very likely but this is what should determine the rules by
which we change the ABI.
> Kristian, i assume Wayland will also return presentation timestamps in
> the format and microsecond precision of the DRM, right?
>
> On 05.10.12 18:22, intel-gfx-request at lists.freedesktop.org wrote:
> > Message: 7 Date: Fri, 5 Oct 2012 12:14:29 -0400 From: Kristian H?gsberg
>
> ...
> > I just had a quick look at driver/input/evdev.c, since evdev devices
> > did a similar change recently to allow evdev timestamp from the
> > monotonic clock. They're using a different time API:
> >
> > time_mono = ktime_get();
> > time_real = ktime_sub(time_mono, ktime_get_monotonic_offset());
> >
> > and
> >
> > event->time = ktime_to_timeval(client->clkid == CLOCK_MONOTONIC ?
> > mono : real);
> >
> > I'm not really up-to-date on kernel time APIs, but I wonder if that
> > may be better? At least, I suspect we wouldn't need changes outside
> > drm if we use this API.
> >
> > Kristian
>
> Userspace apps only have access to what gettimeofday() and
> clock_gettime() for CLOCK_REALTIME (== gettimeofday() afaik) and
> CLOCK_MONOTONIC return, so whatever is returned should be in
> CLOCK_MONOTONIC format, otherwise there will be lots of tears and dead
> kittens. I think what evdev does makes a lot of sense, but i'm also not
> up-to-date about the various layers of timing apis.
Yes, this should be the case, regardless of which kernel interface we
decide to use.
--Imre
More information about the Intel-gfx
mailing list