[Intel-gfx] [RFC PATCH i-g-t 0/3] Test the plane formats on the Chamelium
maxime.ripard at bootlin.com
Wed Mar 28 08:30:32 UTC 2018
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.
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: not available
More information about the Intel-gfx