On Mon, Sep 11, 2017 at 10:52:27AM +0200, Maarten Lankhorst wrote: > 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? Like I said that should be doable with just a simple timestamp check to fix up the bogus 0. -- Ville Syrjälä Intel OTC _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
