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

[Paul Kocialkowski <paul.kocialkowski@linux.intel.com>]

On Thu, 2017-07-06 at 17:57 -0400, Lyude Paul wrote:
> --snip--
> (also sorry this one took a while to get to, had to do a lot of
> thinking because I never really solved the problems mentioned here
> when
> I tried working on this...)
> 
> On Thu, 2017-07-06 at 16:33 +0300, Paul Kocialkowski wrote:
> > On Thu, 2017-07-06 at 14:31 +0300, Paul Kocialkowski wrote:
> > > > 
> > > > There's lots of potential here for copy pasta to form in the
> > > > future,
> > > > since the API here puts a lot of work on the caller to set
> > > > things
> > > > up
> > > > for frame dumping. IMO, it would be worth it to teach the CRC
> > > > checking
> > > > functions to automatically do frame dumps on mismatch if the CRC
> > > > source
> > > > supports it. This will save us from having to have separate
> > > > frame
> > > > dump
> > > > APIs in the future if we ever end up adding support for other
> > > > kinds
> > > > of
> > > > automated test equipment.
> > > 
> > > I don't think it makes so much sense to do this in the CRC
> > > checking
> > > functions,
> > > just because they are semantically expected to do one thing: CRC
> > > checking, and
> > > doing frame dumps seems like going overboard.
> > > 
> > > On the other hand, I do agree that the dumping and saving part can
> > > and
> > > should be
> > > made common, but maybe as a separate function. So that would be
> > > two
> > > calls for
> > > the tests: one to check the crc and one to dump and save the
> > > frame.
> > 
> > A strong case to support this vision: in VGA frame testing, we have
> > already dumped the frame and don't do CRC checking, yet we also need
> > to
> > save the frames if there is a mismatch.
> > 
> > It would be a shame that the dumping logic becomes part of the CRC
> > functions, since that would mean duplicating that logic for VGA
> > testing
> > (as it's currently done in the version I just sent out).
> 
> That is a good point, but there's some things I think you might want
> to
> consider. Mainly that in a test that passes, we of course don't write
> any framedumps back to the disk since nothing failed. IMO, I would
> -think- that we care a bit more about the performance hit that happens
> on passing tests vs. failing tests, since tests aren't really supposed
> to fail under ideal conditions anyway. Might be better to verify with
> the mupuf and the other people actually running Intel's CI though,
> since I'm not one of them.
> 
> 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.

> > In spite of that, I think having a common function, called from the
> > test
> > itself is probably the best approach here.
> 
> Not sure if I misspoke here but I didn't mean to imply that I'm
> against
> having functions for doing frame dumping exposed to the callers. I had
> already figured there'd probably be situations where just having the
> CRC checking do the frame dumping wouldn't be enough.
> 
> This being said though, your viewpoint does make me realize it might
> not be a great idea to do autoframe dumping in -all- crc checking
> functions necessarily, but also makes me realize that this might even
> be a requirement if we still want to try keeping around
> igt_assert_crc_equal() and not just replace it outright with a
> function
> that doesn't fail the whole test (if we fail the test, there isn't
> really a way we can do a framedump from it afterwards). So I would
> think we can at least exclude igt_check_crc_equal() from doing
> automatic framedumping, but I still think it would be a good idea to
> implement igt_assert_crc_equal().
> 
> As for the what you're talking about, e.g. doing frame dump
> comparisons
> on VGA, I think the solution might be not to make any of the code for
> doing the actual frame comparisons chamelium specific either (except
> maybe for the part where we trim the framebuffer we get so it only
> contains the actual image dump).
> 
> So how about this: let's introduce a generic frame comparison API
> using
> the code you've already written for doing this on VGA with the
> chamelium. Make it part of the igt library, and have it just accept
> normal pixman images and perform fuzzy comparisons between them. In
> doing that, we can introduce a generic dump-frames-on-error API
> through
> there much more easily.
> 
> My big aim here is just to make it so that people using igt don't have
> to do anything to get frame dumping in their tests, it just "works".
> 
> > 
> > > I have also duplicated that logic in upcoming VGA frame testing,
> > > so
> > > there is definitely a need for less duplication.
> > > 
> > > > As well, I like how you removed the redundancy between
> > > > test_display_crc_single() and test_display_crc_multiple().
> > > > However
> > > > since those are somewhat unrelated changes to the code path for
> > > > these
> > > > tests it would be better to have that re-factoring as a separate
> > > > patch
> > > > so as to make it easier for anyone who might need to bisect this
> > > > code
> > > > in the future.
> > > 
> > > Fair enough, it just felt weird to commit two functions that were
> > > nearly the
> > > exact same, but I have no problem with doing this in two separate
> > > patches.
> > > 
> > > > >  
> > > > >  		free(expected_crc);
> > > > >  		free(crc);
> > > > > @@ -644,10 +618,10 @@ igt_main
> > > > >  							edid_
> > > > > i
> > > > > d,
> > > > > alt_edid_id);
> > > > >  
> > > > >  		connector_subtest("dp-crc-single",
> > > > > DisplayPort)
> > > > > -			test_display_crc_single(&data, port);
> > > > > +			test_display_crc(&data, port, 1);
> > > > >  
> > > > >  		connector_subtest("dp-crc-multiple",
> > > > > DisplayPort)
> > > > > -			test_display_crc_multiple(&data,
> > > > > port);
> > > > > +			test_display_crc(&data, port, 3);
> > > > >  	}
> > > > >  
> > > > >  	igt_subtest_group {
> > > > > @@ -698,10 +672,10 @@ igt_main
> > > > >  							edid_
> > > > > i
> > > > > d,
> > > > > alt_edid_id);
> > > > >  
> > > > >  		connector_subtest("hdmi-crc-single", HDMIA)
> > > > > -			test_display_crc_single(&data, port);
> > > > > +			test_display_crc(&data, port, 1);
> > > > >  
> > > > >  		connector_subtest("hdmi-crc-multiple", HDMIA)
> > > > > -			test_display_crc_multiple(&data,
> > > > > port);
> > > > > +			test_display_crc(&data, port, 3);
> > > > >  	}
> > > > >  
> > > > >  	igt_subtest_group {
-- 
Paul Kocialkowski <paul.kocialkowski@linux.intel.com>
Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo, Finland
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx