On Wed, Jun 22, 2016 at 09:33:13PM +0100, Chris Wilson wrote: > On Wed, Jun 22, 2016 at 04:26:01PM +0300, Ville Syrjälä wrote: > > On Wed, Jun 22, 2016 at 02:11:51PM +0100, Chris Wilson wrote: > > > On Wed, Jun 22, 2016 at 04:01:12PM +0300, Ville Syrjälä wrote: > > > > On Wed, Jun 22, 2016 at 01:34:16PM +0100, Chris Wilson wrote: > > > > > On Tue, Jun 21, 2016 at 08:25:27PM +0300, ville.syrjala@xxxxxxxxxxxxxxx wrote: > > > > > > From: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> > > > > > > > > > > Would it be possible for writing timing requirement tests for individual > > > > > updates of planes on the same CRTC? E.g. making sure that legacy cursor > > > > > doesn't block pageflips and vice versa. Also extending that to > > > > > independent updates of primary vs sprite planes? > > > > > > > > I guess all that should be doable. > > > > > > > > I was also thinking we should at least have some kind of basic > > > > performance benchmark for atomic ioctls. Eg. do TEST_ONLY ioctls > > > > with different sets of properties and make sure we don't totally > > > > suck. > > > > > > Would it fit into kms_flip? > > > > Possibly, but I wouldn't. Maybe if we would try to split up the main > > test function into different functions for different tests instead of > > continuing with the flag galore. But still I'd probably prefer a > > separate test so the the entire thing easier to read. > > > > > > > > For starters, I'm going to try and replicate the current cursor bogosity > > > inside ./kms_cursor_legacy. Biggest challenge is defining pass/fail > > > criteria. :| > > > > What do we need? > > - make sure >1 cursor updates can be performed per frame w/o errors/blocking. > > - issue >1 one cursor updates, followed by a flip that should not error/block > > - issue flip, followed by >1 cursor updates that should not error/block > > I've put together an initial sketch to try and load as many cursor > updates before the the pageflip as possible to try and detect if (a) the > cursor updates are then synchronous with each other and (b) if the > pageflip serialises with the cursor updates. That's enough to catch the > current bug (and I think the previous cursor bug). > > > Maybe crc check at the end to make sure it's really the last submitted > > thing that got latched. And maybe we should change the crc frame counter > > to use the sw counter so we could check that update happens on the frame > > we expected? > > In theory, that should be caught by kms_cursor_crc, right? Probably > worth a look to see why we don't have a representative test case in BAT > (or if we do, why it was ineffective). I don't think that one tries multiple updates per frame. It might even do one update every n frames on account of starting/stopping the crc capture around every check, which implies a few extra vblank waits IIRC. -- Ville Syrjälä Intel OTC _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
