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

[Lionel Landwerlin]

On 22/08/17 14:28, Chris Wilson wrote:
> 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
>

My debugging experience has been the following :

- I have no idea what's wrong, put traces in different places and hope 
to notice something fishy
- There are now too many traces and taking too long to figure anything 
from the logs

print_report is just a remaining utility function. I'm happy to drop it 
from the patch if that's too contentious.

-
Lionel