Op 08-09-17 om 21:55 schreef Chris Wilson: > Quoting Daniel Vetter (2017-09-08 20:45:11) >> On Fri, Sep 08, 2017 at 05:55:24PM +0300, Ville Syrjälä wrote: >>> Another thought that just occurred to me: Maybe we could use these >>> timestamps as a workaround for the DDI "scanline reads as 0 at the >>> wrong time" problem. What we could do is check of the scanline counter >>> reads as 0, and if it does we could switch over to checking the >>> timestamps instead. Not sure if we should just do the full timestamp >>> based scanline read like you do here, or we could just check that if the >>> timestamps look like they're close to vblank_start we just return >>> vblank_start-1. This could then remove the obnoxious retry loop from the >>> scanline counter read. >> Another concern I have on this is timeframe jitter. If the vblank >> timestamp stuff isnt' perfectly accurately spaced, or we have a mismatch >> in clocks, then we might think there's still plenty of time before vblank >> while we're already racing. > You are sort of getting to the point where you just use the ART cpu > clock, using an ewma seeded with the vrefresh and fed with the vblank > intervals as an estimator for how long you have left to the next vblank. Agreed, this seems to be the case.. In which case can't we use that for all of DDI to get a better than scanline resolution for last vblank time by replacing the get_vblank_timestamp hook? _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
