Subject: Re: [RFC 4/4] drm: add support for raw monotonic vblank
timestamps
Message-ID: <1349446447.17758.73.camel@thor.local>
Content-Type: text/plain; charset="ISO-8859-1"
On Fre, 2012-10-05 at 16:59 +0300, Imre Deak wrote:
On Fri, 2012-10-05 at 15:55 +0200, Michel D?nzer wrote:
On Fre, 2012-10-05 at 16:37 +0300, Imre Deak wrote:
In practice we never want the timestamps for vblank and page flip events
to be affected by time adjustments, so in addition to the gettimeofday
timestamps we used so far add support for raw monotonic timestamps.
For backward compatibility use flags to select between the old and new
timestamp format.
Note that with this change we will save the timestamp in both formats,
for cases where multiple clients are expecting an event notification in
different time formats.
I wonder if all this trouble is really necessary. I honestly can't
imagine any user of this API requiring non-monotonic timestamps and
breaking with monotonic ones. I think it was simply a mistake that we
didn't make them monotonic in the first place (or maybe it wasn't even
possible when this API was first introduced).
Hi
The OML_sync_control spec requires monotonic timestamps, so yes, it was
either a mistake or it wasn't possible at that time.
If an app developer follows the spec, he would consider the current
behaviour broken -- or should be able to handle monotonic timestamps.
Yea, I'd rather simply switch over to monotonic timestamps too. But that
would break apps that already compare against the wall time for whatever
purpose (for example A/V sync).
Are there actually any such apps in the real world? Do they work when
the wall time jumps?
Psychtoolbox as my example of a very timing sensitive app: Currently
uses wall time as a reference for historical reasons. We tell/expect
users not to do anything in the middle of a work session that could
cause a sudden jump in wall time, but then ntp time adjustments are
usually in very small steps, so not a problem, and big adjustments
should only happen if users do something they'll certainly not do during
a timing-sensitve session, like manually set the system clock,
reboot/suspend/resume the machine etc. In practice, this works well
enough over the typical duration of such sessions (minutes to a few
hours) and is sometimes needed if multiple machines need to be
time-synced over the local network.
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.
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.
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@xxxxxxxxxxxxxxxxxxxxx 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.
-mario
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
