On 11/05/2016 23:31, Leo Liu wrote:
On 05/11/2016 05:18 PM, Axel Davy wrote:
On 11/05/2016 23:08, Leo Liu wrote:
scrn->next_msc = ((int64_t)stamp - scrn->last_ust + scrn->ns_frame/2) /
+ scrn->ns_frame + scrn->last_msc;
Could you explain this calculation ?
ns_frame is the time for vsync in ns.
last_ust is time of last frame is finished presentation.
last_msc is msc of last frame is finished presentation.
stamp is player expected time for next frame to present.
and do the round up.
thanks
I think it may get issues if ns_frame is wrong. For example for some
reason (app hidden for some frame, or monitor shut, or whatever), I
think we could get two buffers getting complete event with same ust
(one skipped, and one shown).
It works well very well so far for DRI2.
DRI3/Present are designed to allow more liberty for the server. It is
expected in future version
the window managers will handle some of the events, and it may behave
quite different than currently.
Besides DRI3/Present will likely be plugged into Xwayland (currently it
uses the emulation code, but the extension can be implemented with
wayland calls, I had a patch for that), and there again it is different
behaviour.
Thus I advise against having code that 'works well in practice' but can
fail with something that is allowed in the spec.
Thanks,
Leo
I think the calculation should be made more robust to issues with
ns_frame. Perhaps do some temporal averaging of ns_frame and ignore
outliers ?
Axel
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
