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@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
