From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH i-g-t 1/6] tests/kms_flip: Print timestamps in a consistent form
Date: Wed, 22 Jun 2016 16:26:01 +0300 [thread overview]
Message-ID: <20160622132601.GD4329@intel.com> (raw)
In-Reply-To: <20160622131151.GC22318@nuc-i3427.alporthouse.com>
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@linux.intel.com wrote:
> > > > From: Ville Syrjälä <ville.syrjala@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
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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2016-06-22 13:26 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-21 17:25 [PATCH i-g-t 1/6] tests/kms_flip: Print timestamps in a consistent form ville.syrjala
2016-06-21 17:25 ` [PATCH i-g-t 2/6] tests/kms_flip: Constify some function arguments ville.syrjala
2016-06-21 17:25 ` [PATCH i-g-t 3/6] tests/kms_flip: Use USEC_PER_SEC ville.syrjala
2016-06-21 17:25 ` [PATCH i-g-t 4/6] tests/kms_flip: Account for diff.tv_secs in jitter check ville.syrjala
2016-06-21 17:25 ` [PATCH i-g-t 5/6] tests/kms_flip: Print the expected diff between two events ville.syrjala
2016-06-21 17:25 ` [PATCH i-g-t 6/6] tests/kms_flip: Check that the last vs. current seq/ts are consistent ville.syrjala
2016-06-22 12:34 ` [PATCH i-g-t 1/6] tests/kms_flip: Print timestamps in a consistent form Chris Wilson
2016-06-22 13:01 ` Ville Syrjälä
2016-06-22 13:11 ` Chris Wilson
2016-06-22 13:26 ` Ville Syrjälä [this message]
2016-06-22 20:33 ` Chris Wilson
2016-06-23 12:13 ` Ville Syrjälä
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160622132601.GD4329@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=chris@chris-wilson.co.uk \
--cc=intel-gfx@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox