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

Reply via email to