On Tue, Mar 3, 2015 at 10:15 PM, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> wrote:
> On Tue, Mar 03, 2015 at 11:23:53AM -0800, Jesse Barnes wrote:
>> On 03/03/2015 09:03 AM, Daniel Vetter wrote:
>> > This is useful for writing igts to make sure we don't break this,
>> > without being forced to own a one of these dinosaurs.
>> >
>> > Suggested-by: Jesse Barnes <jbarnes@xxxxxxxxxxxxxxxx>
>> > Cc: Matt Roper <matthew.d.roper@xxxxxxxxx>
>> > Signed-off-by: Daniel Vetter <daniel.vetter@xxxxxxxxx>
>> > ---
>> > drivers/gpu/drm/i915/i915_drv.h | 1 +
>> > drivers/gpu/drm/i915/i915_params.c | 8 +++++++-
>> > drivers/gpu/drm/i915/intel_crt.c | 6 ++++--
>> > 3 files changed, 12 insertions(+), 3 deletions(-)
>>
>> See below for comments.
>>
>> I think there's probably even more room for testing like this. E.g. the
>> tiled swapping test could be done this way rather than trying to force
>> swapping. Some of the races we try to induce could probably also be
>> done this way with code in the kernel to trigger the case we're worried
>> about...
>
> I am not wholly convinced. The primary purpose of the test suite is
> prevent bugs of tomorrow, not to chase bugs of yesterday. If we focus too
> much on bugs we have fixed, I worry we won't serendipitously detect bugs
> early. Yes, bugs cluster and a mistake once made is likely to be made
> again (so regression testing is vital) but I think we cross a line if
> igt only exercises code written for conformance testing.
Also swapping tests are a solved problem really, we've had an "mlock
most of mem" todo since years and Thomas Wood is implementing it. Well
it's committed for gem_tiled_swapping already
commit 42b02c284ed24871528df8f1b3eaad7fe1554fd9
Author: Thomas Wood <thomas.wood@xxxxxxxxx>
Date: Mon Dec 8 11:12:51 2014 +0000
lib: add a function to lock memory into RAM
what's missing is rolling this out for other tests.
Now I love igt bashing as much as the next person, but maybe check
occasionally whether your rant-du-jour is still relevant ...
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
