Hi Eric, Thanks for your input. On Wed, Mar 21, 2018 at 10:10:00AM -0700, Eric Anholt wrote: > Maxime Ripard <maxime.ripard@xxxxxxxxxxx> 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. Thanks! Maxime -- Maxime Ripard, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
