On Tue, Sep 22, 2015 at 03:36:44PM +0300, Ville Syrjälä wrote: > On Tue, Sep 22, 2015 at 11:10:50AM +0200, Daniel Vetter wrote: > > On Mon, Sep 14, 2015 at 10:43:52PM +0300, ville.syrjala@xxxxxxxxxxxxxxx wrote: > > > From: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> > > > > > > The vblank timestamp ringbuffer only has two entries, so if the > > > vblank->count is incremented by an even number readers may end up seeing > > > the new vblank timestamp alongside the old vblank counter value. > > > > > > Fix the problem by storing the vblank counter in a ringbuffer as well, > > > and always increment the ringbuffer "slot" by one when storing a new > > > timestamp+counter pair. > > > > > > Signed-off-by: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> > > > > Imo if we bother with this we might as well just switch over to using > > full-blown seqlocks. They internally use a two-stage update which means > > race-free even with just one copy of the data we protect. Also more > > standardized to boot. > > Any volunteers for that? I don't have time to start redoing this right > now. I guess we can keep it as a low-hanging thing for now, didn't seem to have annoyed anyone yet. It should be fairly simple since all the vblank counter access goes through the 2 functions I created a while back while polishing the barriers a bit. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
