From: Daniel Vetter <daniel@ffwll.ch>
To: Jesse Barnes <jesse.barnes@intel.com>
Cc: "intel-gfx@lists.freedesktop.org" <intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH igt] igt/gem_softpin: Remove false dependencies on esoteric features
Date: Tue, 26 Jan 2016 11:06:16 +0100 [thread overview]
Message-ID: <20160126100616.GY11240@phenom.ffwll.local> (raw)
In-Reply-To: <56A67FDB.60705@intel.com>
On Mon, Jan 25, 2016 at 12:04:43PM -0800, Jesse Barnes wrote:
> On 01/21/2016 12:08 AM, Daniel Vetter wrote:
> > On Wed, Jan 20, 2016 at 06:49:49PM +0000, Belgaumkar, Vinay wrote:
> >> Hi Chris,
> >> These tests were developed for testing buffered SVM(using userptr
> >> and soft pinning API). I think Dan wanted me to rename the tests to
> >> gem_softpin, since they were being checked in as tests which
> >> validated the softpin kernel patches. Can we rename the existing
> >> tests to gem_buffered_svm or something similar, and then push any
> >> targeted softpin only tests as gem_softpin? We were hoping to use
> >> these userptr+softpin tests as GFT tests for SVM(Android) as well,
> >> since buffered SVM is POR for BXT Android.
> >
> > I agree with Chris, there's no need to unecessarily mix together features.
> > When the api is designed in an orthogonal way, so should be the testing.
> > i915.ko is already a mindboggling complex beast, no need to make our lives
> > harder by making the tests use features that aren't strictly needed.
> >
> > In the end applications and UMDs will of course use all these features
> > together, but that's why we do integration testing on top of just running
> > igt.
> >
> > Can you please review Chris' patch?
>
> So what's the actual request here? Chris rewrote Vinay's test, but does
> it cover all the same stuff Vinay did? If not, it would be nice to
> include those, maybe in a separate file, since Vinay did work with lots
> of people to make sure the coverage was complete for the SVM use
> cases... I definitely like the sound of the new stuff Chris added
> though; no-reloc in particular is an important use case for upcoming
> APIs.
Afaict Chris' patch doesn't reduce the coverage of the existing/merged
testcase in any way at all, but makes it a bit simpler to ensure we test
features more orthogonally. I didn't check in detail, but the combination
tests should still be there (and would be something reviewers can/should
check).
I was only replying to (what seemed to me) Vinay's outright dismissal of
Chris' patch, since I think Chris' idea to make feature testing as
orthogonal as possible is sound. Details would be up to the review, like I
said.
Another topic related to this is whether igt should do integration testing
of the entire stack (i.e. combining all the features exactly as the UMD
would use them). In my opinion it's better to do such integration testing
with the actual UMD and UMD-specific testsuites, and leave testing of
corner-cases and low-level functionality to igt. That of course doesn't
exclude igt tests that exercise corner-cases when different features
interact.
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2016-01-26 10:06 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-14 11:02 [PATCH igt] igt/gem_softpin: Remove false dependencies on esoteric features Chris Wilson
2016-01-15 9:41 ` Tvrtko Ursulin
2016-01-20 18:49 ` Belgaumkar, Vinay
2016-01-21 8:08 ` Daniel Vetter
2016-01-25 20:04 ` Jesse Barnes
2016-01-26 10:06 ` Daniel Vetter [this message]
2016-01-26 10:19 ` Chris Wilson
2016-01-27 5:13 ` Belgaumkar, Vinay
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=20160126100616.GY11240@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jesse.barnes@intel.com \
/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