[Intel-gfx] [RFC/Draft] Testing requirements for upstream drm/i915 patches

[Rodrigo Vivi]

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 at linux.intel.com> wrote:
> On 10/30/2013 12:05 PM, Daniel Vetter wrote:
>>
>> On Wed, Oct 30, 2013 at 7:11 PM, Ian Romanick <idr at 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.
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx



-- 
Rodrigo Vivi
Blog: http://blog.vivi.eng.br