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