On Tue, Jun 14, 2016 at 08:27:57AM +0200, Maarten Lankhorst wrote: > Op 13-06-16 om 16:45 schreef Daniel Vetter: > > On Thu, Jun 09, 2016 at 01:36:50PM +0200, Maarten Lankhorst wrote: > >> This will make it more likely that intermediary watermarks cause fifo > >> underruns, which is useful when writing watermark specific tests, > >> to make it more likely to trigger FIFO underruns in intermediary watermarks. > > That's surprising ... with the vblank_wait added you're pretty much > > guaranteed to never hit the evasion case. Note that the vblank evasion > > code also just does a vblank wait if it detects a possible collision. > > > > Given that I'd have assumed that this simply slows down atomic flips, > > which is probably not what we want for testing all. Does this really help? > > Any ideas why? > This is a sanity check on the intermediate watermarks. The vblank test will ensure > that the old plane configuration doesn't cause underruns with watermarks, and that > the intermediate watermarks will work correctly with the new plane configuration too. > > I think the latter vblank_wait may be killed, but the former could be really useful, > for example to find correct watervblank values in CHV. Why can't we do the vblank wait in userspace? If we wait 1 vblank (or just for the drm event of the previous commit), and then immediately issue the next one, we will also run with intermediate watermarks for a full frame. At least I still don't see a super-short race window for which we need to have code in the kernel to properly provoke it ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
