RFC: Change OML_sync_control UST to CLOCK_MONOTONIC

Jerome Glisse j.glisse at gmail.com
Thu Jun 14 11:21:31 PDT 2012


On Thu, Jun 14, 2012 at 2:17 PM, Jerome Glisse <j.glisse at gmail.com> wrote:
> On Thu, Jun 14, 2012 at 1:19 PM, Joakim Plate <elupus at ecce.se> wrote:
>>
>>> >
>>> > From what I can tell, it should be using: ktime_to_ns(ktime_get()) / 1000.
>> Only
>>> > issue is that changing it will break any app relying on it being REALTIME
>> clock.
>>> >
>>>
>>> App that rely on it being anything special are badly broken and i
>>> don't think there is any such app. The specification strongly stress
>>> that app should make no assumption about it.
>>>
>>
>> While that may be true... Since there is no other API for getting this UST
>> clock, it's somewhat limited in use. Even if i know vsync happened at time X, if
>> don't know what time it is "now" how can i make use of it?
>>
>> Spec says: "The Unadjusted System Time (or UST)
>>    is a 64-bit monotonically increasing counter that is available
>>    throughout the system."
>>
>> If across the system, the only API to get to this value is through GLX api, it's
>> rather hard to make use of.
>>
>> For example syncing audio to vsync. One need to sync audio output written to
>> audio renderer now, with this clock.
>>
>> Also regarding relying on current behavior... Even if this change is made now,
>> there will be a lot of system with the old behaviour. So knowning if the change
>> has been made in a system is crucial for supporting both / not enabling when
>> feature is unreliable.
>>
>> /Joakim
>>
>
> This extension is not for predicting when is the next vblank and it's
> wrong to try to use it for that. My understanding is that you should
> use this extension for instance to show N video frame per second,
> based on the number of frame you play per second you can synchronize
> sounds output.
>
> Cheers,
> Jerome

Note that if you really think that you need something like
GLX_OML_sync_control but with UST being some sensible value from the
system that you can query by other mean we could easily add a new mesa
extension GLX_MESA_sync_control that properly defines ust and keep
everything else the same. Then we can fix the kernel and expose this
extension only on fixed kernel. Of course this would probably only be
available on open source driver but with a bit of lobying nvidia & amd
might pick the extension in their closed source driver.

Cheers,
Jerome


More information about the dri-devel mailing list