[Intel-gfx] [PATCH] igt/gem_workarounds: igt to test workaround registers

Chris Wilson chris at chris-wilson.co.uk
Thu Aug 28 07:55:37 CEST 2014


On Wed, Aug 27, 2014 at 11:30:35PM +0100, Damien Lespiau wrote:
> On Wed, Aug 27, 2014 at 06:52:57PM +0100, Chris Wilson wrote:
> > > Just to clarify, he was not ok because the list we maintain in the
> > > test can get out of sync with the workarounds we apply in the driver
> > > which can be avoided if it is generated by the kernel itself.
> > 
> > Test driven development would suggest that the test itself maintains its
> > list. Something I heard Daniel say himself before ;-)
> >  
> > > It may be ok to maintain the list in the test in this case
> > > considering the list is fairly small but it is not my call.
> > 
> > The best thing about independent testing is that it is independent...
> 
> Well also depends on what you're testing I suppose. It's hard enough to
> have a complete list of W/As, so two of them is bound to end up in
> tears. If we are testing that the list of W/As the kernel knows about is
> indeed applied correctly at init/reset/suspend resume, that's already a
> good step.
> 
> Also, that second list in i-g-t is not going to be implemented in
> complete independence from the kernel tree, it's likely to be the same
> person doing both sides, ending up copy/pasting a file anyway, no value
> in doing that. The two lists argument works well if 2 different
> engineers/teams implement the 2 sides, effective cross-checking the list
> of W/As as a result, but we don't quite have the people to do that.

The point of the independent test is more that you can ask people to run
and see if it reports strange things on unknown kernels that might
explain bugs. There has to be an external list anyway just so that you
can check off the appropriate w/a.

Putting that second list in the kernel just leads to bugs in the kernel
as aptly demonstrated by the patch and doesn't lead to those warm fuzzy
feelings.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre



More information about the Intel-gfx mailing list