On Thu, Jun 14, 2012 at 2:17 PM, Jerome Glisse <j.glisse@xxxxxxxxx> wrote: > On Thu, Jun 14, 2012 at 1:19 PM, Joakim Plate <elupus@xxxxxxx> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
