I'm in favor of all Daniel said and my 2 cents here is just to highlight how easy and straightforward is to create an intel-gpu-tools testcase nowadays. If you know very well the feature you are implementing you will spend couple of hours or 1 day maximum. I agree with Daniel that it is difficult to create the test case when you don't know exactly what is going on like when I was spending 2 days on DPMS-on-off test case that Daniel implemented in couple hours. But anyway I felt that I learned something at least by trying it. So I agree with Ian and Chad that this is a learning opportunity. Even better if we maintain somewhere a list of known missing testcases or ideas for other tests. On Wed, Oct 30, 2013 at 6:32 PM, Chad Versace <chad.versace@xxxxxxxxxxxxxxx> wrote: > On 10/30/2013 12:05 PM, Daniel Vetter wrote: >> >> On Wed, Oct 30, 2013 at 7:11 PM, Ian Romanick <idr@xxxxxxxxxxxxxxx> wrote: >>>> >>>> test coverage of the existing code _before_ starting a feature >>>> instead >>>> of when the patches are ready for merging should help a lot, before >>>> everyone is invested into patches already and mounting rebase pain >>>> looms >>>> large. > > >> Yeah, that would be a great way to bring up new people. The problem is >> a bit that on the kernel side we have a few disadvantages compared to >> mesa: We don't have a nice spec and we also don't have a fairly decent >> reference implementation (the nvidia blob). So ime writing kernel >> tests is much more open-ended than reading a gl extension spec and >> just nocking off all the new enums and api interface points. > > > Writing *meaningful* GL tests is much more open-ended than reading a gl > spec and knocking off each item. To really test some GL features, you > must be exceedingly clever and even have an understanding of the underlying > hardware implementation to test the significant corner cases. In that > sense, it's not too different from writing a kernel test case. > > My comment is intended to be positive rather than a negative correction. > The Mesa team frequently succeeds at creating good test coverage of > new GL features despite the difficulty. That fact hopefully confirms it > will be possible for the kernel team too. > > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@xxxxxxxxxxxxxxxxxxxxx > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Rodrigo Vivi Blog: http://blog.vivi.eng.br _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
