On 06/11/2012 03:02 AM, Michel Dänzer wrote:
On Son, 2012-06-10 at 11:56 +0000, Joakim Plate wrote:
Hi,
I'm currently trying to make use of OML_sync_control extension to schedule
presentation of video frames in xbmc.
I've run into somewhat of a snag. It seem the spec doesn't specify what
time the UST clock really is, nor can i find any mention of it elsewhere
in docs.
Code wise it seem to be using do_gettimeofday(), which seems like a rather
poor choice given that it can jump forward and back in time due to
settimeofday calls.
We normally make use of clock_gettime(CLOCK_MONOTONIC) to timestamp display
of video frames, so to avoid major changes I'd need a way to convert to
gettimeofday (seem same as CLOCK_REALTIME).
Currently i'm trying:
struct timespec mon, rel;
clock_gettime(CLOCK_MONOTONIC,&mon);
clock_gettime(CLOCK_REALTIME ,&rel);
ticks += (rel.tv_sec - mon.tv_sec) * 1000000000;
ticks += (rel.tv_nsec - mon.tv_nsec);
To convert between the two, but that is quite a hack both in the
possibility of clock changes and scheduling errors.
Is there a better way, or perhaps the DRI code should use CLOCK_MONOTONIC
in the first place?
From the GLX_OML_sync_control spec:
The Unadjusted System Time (or UST) is a 64-bit monotonically
increasing counter [...]
So, without having thought a lot about potential ramifications, I'm
inclined to say that CLOCK_MONOTONIC should indeed be used.
Maybe. Isn't CLOCK_MONOTONIC per-process? UST is supposed to be
relatively consistent across the system. Some relevant was elided above:
"The Unadjusted System Time (or UST) is a 64-bit monotonically
increasing counter that is available throughout the system. UST
is not a resource that is controlled by OpenGL, so it is not
defined further as part of this extension."
do_gettimeofday is definitely the wrong choice, but it was the best
thing that I knew to use back in 2002(ish) when I wrote that code. I'm
just not sure CLOCK_MONOTONIC is quite right either.
What's behind door #3? :)
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
