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. >> * 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:
signature.asc
Description: PGP signature
_______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
