On Fri, 5 Dec 2014, Mario Kleiner wrote:
Wrt. 2/5: It's a bit ambiguous how to read that bit of the spec, and i agree
that one could read it in a way that the current mesa dri3 behaviour is not
(completely) violating the spec. When we implemented the DRI2 version, we
understood it in the way i want to restore with 2/5. The first reason is
because the DRI2 / patch 2/5 interpretation makes the OML_sync_control
extension very useful and robust for swap timing, whereas the alternative
reading makes the extension borderline useless / its use somewhat fragile due
to the race described in the commit. The second reason is backwards
compatibility: It would be awesome not to break timing sensitive apps written
against DRI2, especially given that users of those apps will certainly not
understand why a simple distribution upgrade or graphics stack update pushed
by the distro can suddenly cause such regressions.
Another thing about 2/5 is that we don't want that querying the current
msc perturbs the next target_msc when calling present_pixmap when
swap_interval is not 0.
let's say we have.
-> msc x
last presentation succeeds
-> msc x+1
we query current msc
we make new presentation, target msc y.
Without patch 2/5, the calculus of y will be done on the basis that last
presentation was done at x+1 instead of x.
Axel Davy
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
