[Intel-gfx] [PATCH i-g-t v3 4/4] chamelium: Dump obtained and reference frames to png on crc error

Martin Peres martin.peres at linux.intel.com
Mon Jul 10 13:56:04 UTC 2017


On 10/07/17 15:06, Paul Kocialkowski wrote:
> On Mon, 2017-07-10 at 13:33 +0300, Martin Peres wrote:
>> On 10/07/17 13:31, Paul Kocialkowski wrote:
>>> On Thu, 2017-07-06 at 17:57 -0400, Lyude Paul wrote:
>>>>
>>>> As well, one advantage we do have here from the chamelium end is
>>>> that
>>>> you can only really be screen grabbing from one port at a time. So
>>>> you
>>>> could actually just track stuff internally in the igt_chamelium
>>>> API
>>>> and when a user tries to download a framedump that we've already
>>>> downloaded, we can just hand them back a cached copy of it.
>>>
>>> I forgot to answer this point. I think this bring way too much
>>> overhead
>>> and is not really necessary anyway. With the solution I proposed in
>>> my
>>> previous email on this thread, the two wrapper functions (one for
>>> CRC,
>>> one for analogue frame comparison) will either dump the frame for
>>> CRC
>>> comparison (because it was never dumped before) or use the provided
>>> one
>>> for analogue comparison, so there is no particular need to track
>>> what
>>> was or wasn't dumped before.
>>
>> No need to track, just encode it in the filename:
>> $test-$subtest-error-crc-$crc.png
>>
>> Just do not override existing files, and you are done :)
> 
> I suppose it would be best to have predictible filenames (so not
> including the crc) to make it easier to grab the frame for an automated
> testing framework, right? >
> So what about: frame-$test-$subtest-$qualifier.png, with $qualifier
> being either "reference" or "dump". I don't think it's necessary to
> indicate whether the error comes from crc or analogue frame testing:
> this will already be contained in the subtest name.
> 

Well, predictable is actually problematic, since automated systems try 
to reproduce issues, and your idea will lead to overriding (which is 
only not a problem if the CRC is the same).

In the end, what we want is to say in the logs what are the files 
(reference and dump). We'll need to agree on a format, so as an 
automated system can pick it up :)


More information about the Intel-gfx mailing list