[Intel-gfx] [PATCH i-g-t 02/11] tests/perf: add per context filtering test for gen8+

[Chris Wilson]

Quoting Lionel Landwerlin (2017-08-22 14:11:07)
> On 22/08/17 12:59, Chris Wilson wrote:
> > Quoting Lionel Landwerlin (2017-08-22 12:45:47)
> >> On 08/08/17 15:21, Matthew Auld wrote:
> >>> On 4 August 2017 at 12:20, Lionel Landwerlin
> >>> <lionel.g.landwerlin at intel.com> wrote:
> >>>>    static void
> >>>> @@ -1336,6 +1504,66 @@ print_reports(uint32_t *oa_report0, uint32_t *oa_report1, int fmt)
> >>>>    }
> >>>>
> >>>>    static void
> >>>> +print_report(uint32_t *report, int fmt)
> >>>> +{
> >>> I get an unused warning for this...
> >> Useful for really precise debugging. Putting under ifdef
> > Does it interfere that much with normal testing, or you could dump extra
> > details on unexpected events? If it is useful at some point, you will be
> > wishing you had the details from CI. The beauty of igt_debug() (at least
> > when --debug is not used by defaul!) is that it does give us the
> > portmortem output of the last N lines (where N is ~256?) without
> > flooding ourselves with irrelevant messages.
> > -Chris
> 
> The problem is that we get loooooads of reports.
> Most of the time you want to look at the deltas between them (which is 
> what most igt_debug() are about), only occasionally the actual values 
> (which is what this function dumps).

If you can't identify the right one to dump when you find the error, how
much is the cost of recording all the traces for a subtest and dumping
them compressed+encoded to the output? If we are only talking a few megs
of raw data and hope it compresses down to a few 100k, that's not too
unwieldy to include on stderr/whatever. All depends on how difficult it
will be to reproduce the eventual bug. Just my crystal ball is saying
that if you find print_report() useful, you will find it useful again in
the future where you may not even have access to the system.
-Chris