[Intel-gfx] [RFC PATCH i-g-t 0/3] Test the plane formats on the Chamelium
eric at anholt.net
Wed Mar 21 17:10:00 UTC 2018
Maxime Ripard <maxime.ripard at bootlin.com> writes:
> [ Unknown signature status ]
> 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.
>> * 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.
>> * 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 832 bytes
Desc: not available
More information about the Intel-gfx