Re: [Intel-gfx] [RFC PATCH i-g-t 0/3] Test the plane formats on the Chamelium
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
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
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
