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
