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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 :)
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux