[Intel-gfx] [PATCH igt] igt/gem_softpin: Remove false dependencies on esoteric features

Daniel Vetter daniel at ffwll.ch
Tue Jan 26 02:06:16 PST 2016


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


More information about the Intel-gfx mailing list