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

[Eric Anholt <eric@anholt.net>]

[-- Attachment #1.1: Type: text/plain, Size: 3394 bytes --]

Maxime Ripard <maxime.ripard@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.

>>   * 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.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx