[Intel-gfx] [RFC PATCH i-g-t 0/3] Test the plane formats on the Chamelium

[Maxime Ripard]

Hi Eric,

Thanks for your input.

On Wed, Mar 21, 2018 at 10:10:00AM -0700, Eric Anholt wrote:
> Maxime Ripard <maxime.ripard at bootlin.com> writes:
> 
> > [ Unknown signature status ]
> > Hi,
> >
> > On Mon, Mar 05, 2018 at 03:21:26PM +0100, Maxime Ripard wrote:
> >> Here is an RFC at starting to test the plane formats using the
> >> Chamelium over the HDMI. This was tested using the vc4 DRM driver
> >> found on the RaspberryPi.
> >> 
> >> This is still pretty rough around the edges at this point, but I'd
> >> like to get feedback on a few issues before getting any further.
> >> 
> >>   * I've used pixman for now to convert back and forth the pattern and
> >>     the captured frame. While this worked quite well for the RGB
> >>     formats since pixman supports most (but not all) of them. However,
> >>     the long term plan is to also test YUV and more exotic (like
> >>     vendor specific) formats that pixman has 0 support for. So I
> >>     really wonder whether this is the right approach compared to:
> >>     - Using something else (but what?)?
> >>     - Rolling our own format conversion library?
> 
> Let's start with pixman and either extend pixman if we have formats we
> need (they should be pretty amenable for non-yuv channel layouts), or
> roll our own YUV bits.  For tiling, I think we can just take
> pixman-generated linear image content and do the tiling in igt.

Ok. I guess another alternative could be to use libv4lconvert that
already has a number of rgb to yuv conversions routines. I'm not sure
whether adding a new dependency is ok though.

> >>   * I've so far had a single big test that will test all the formats
> >>     exposed by the planes that have a pixman representation. I wonder
> >>     whether this is preferrable, or if we want to have a subtest per
> >>     format. I guess the latter will be slightly better since we would
> >>     be able to catch regressions in the number of formats exposed that
> >>     we wouldn't be able to with the former.
> 
> Yeah, exposing the formats as subtests is probably a good idea.

I'll do that then.

> >>   * Kind of related, I'm not sure what is the policy when it comes to
> >>     tests, and whether I should merge this tests with kms_chamelium or
> >>     leave it as a separate file.
> 
> I'll leave this up to the original test author.
> 
> >>   * One of the biggest challenge of the serie is to support formats
> >>     that have less bits than the reference frame. Indeed, the flow of
> >>     patterns is this one: the pattern will first be generated in
> >>     ARGB8888. It will then be converted to whatever format we want to
> >>     test, be fed into the display engine, that will output it, and the
> >>     Chamelium will capture it in ARGB8888.
> >>     However, when the plane format has less than 8 bits per color,
> >>     some upsampling will happen, where the less significant bits will
> >>     be filled with values that probably depend on the display
> >>     engine. Another side effect is that the CRC used in the Chamelium
> >>     tests cannot be used anymore.
> >>     The way I'm testing currently is that I'm retrieving the frame,
> >>     and then compare each pixels on their most significant bits. This
> >>     sounds inefficient, and it is, especially on the RPi that doesn't
> >>     have the best networking throughput out there.
> >>     I guess we could also generate a CRC for both an upsampling with
> >>     the lowest bits set to 1, and one for the lowest bits set to 0,
> >>     and try to see if one of them match. I guess this should cover
> >>     most of the situation.
> 
> I still think that we should expect the top bits to be replicated into
> the low bits, until we find hardware that just can't do that.

That works for me then.

I'll try to have all these changes, and send a new version then.

Thanks!
Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/intel-gfx/attachments/20180328/c28a60b7/attachment.sig>