Re: [RFC/Draft] Testing requirements for upstream drm/i915 patches

[Chad Versace <chad.versace@linux.intel.com>]

On 10/30/2013 12:05 PM, Daniel Vetter wrote:
> On Wed, Oct 30, 2013 at 7:11 PM, Ian Romanick <idr@freedesktop.org> 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.