[Intel-gfx] [PATCH i-g-t 1/6] tests/kms_flip: Print timestamps in a consistent form

[Ville Syrjälä]

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 at linux.intel.com wrote:
> > > > > > From: Ville Syrjälä <ville.syrjala at linux.intel.com>
> > > > > 
> > > > > 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