Re: [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  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
> >> ARGB. 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 ARGB.
> >> 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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Eric Anholt]

Maxime Ripard  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
>> ARGB. 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 ARGB.
>> 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.


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Maxime Ripard]

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

Any comments on these points?
Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Maxime Ripard]

Hi,

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?

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

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

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

Let me know what you think,
Thanks!
Maxime

Maxime Ripard (3):
  tests/chamelium: Move some functions and structures to a common place
  tests/chamelium: Add test case for plane formats
  tests: Add vc4 test suite

 tests/Makefile.am|   1 +
 tests/Makefile.sources   |  10 +
 tests/helpers_chamelium.c| 165 +
 tests/helpers_chamelium.h|  65 +++
 tests/kms_chamelium.c| 170 +
 tests/kms_chamelium_formats.c| 305 +++
 tests/meson.build|   1 +
 tests/vc4_ci/vc4-chamelium-fast.testlist |   4 +
 tests/vc4_ci/vc4-chamelium.testlist  |   9 +
 tests/vc4_ci/vc4.testlist|  35 
 10 files changed, 596 insertions(+), 169 deletions(-)
 create mode 100644 tests/helpers_chamelium.c
 create mode 100644 tests/helpers_chamelium.h
 create mode 100644 tests/kms_chamelium_formats.c
 create mode 100644 tests/vc4_ci/vc4-chamelium-fast.testlist
 create mode 100644 tests/vc4_ci/vc4-chamelium.testlist
 create mode 100644 tests/vc4_ci/vc4.testlist

-- 
2.14.3

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