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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

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?

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux