Em Qua, 2016-12-07 às 13:58 +0000, Chris Wilson escreveu: > More changes to GEM are on the cards, so before touching it again, > let's > try and nail down how the internals are meant to work. The advantage > of mock testing is that we can write a universal test independent of > the > hw (e.g. testing physical object creation) and we can inspect > internal > state which should be able to spot subtle bugs easier than mashing > the > uabi. The downside to mock testing is that it doubles the upfront > cost > of every patch submission (if you change internal state, you're > likely > going to upset a test) and adds maintainance burden tracking change > to > external API (on the other hand it catches those silent changes that > would lead to broken code). > > In addition to mock tests, I thought it would be useful to start > writing > a few run-once tests against real hardware. These are not as > interesting > as probing uabi (I don't envisage having kms_flip inside the kernel), > but we might like to exercise runtime suspend once upon startup, for > example. Again, we have access to internal state that may prove > impossible to capture even in debugfs. > > Is this a totally insane and impractical proposal? In case my opinion matters to anyone, I really like the idea of kernel- side tests. There's a limit to what we can do from user space, and the Kernel even has self-tests for other modules, so we have a precedent here. Also, in the past I did have some ideas for kernel-side test code that I never implemented since we didn't have this infrastructure (I forgot what were my ideas). I'd love to be able to contribute to this when I have appropriate ideas. Can we somehow make passing these tests a requirement for the CI system too? Now, I haven't looked at the specific tests you proposed, so I'm not in the position to judge sanity in those specific tests. I'm also assuming that DRM_I915_SELFTESTS=n will keep performance the same as before. > -Chris > > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@xxxxxxxxxxxxxxxxxxxxx > https://lists.freedesktop.org/mailman/listinfo/intel-gfx _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
