From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Anholt Subject: Re: [RFC PATCH i-g-t 0/3] Test the plane formats on the Chamelium Date: Wed, 21 Mar 2018 10:10:00 -0700 Message-ID: <87zi31tkwn.fsf@anholt.net> References: <20180305142129.18352-1-maxime.ripard@bootlin.com> <20180321112517.bxxfp663yexjuihn@flea> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0815309261==" Return-path: Received: from anholt.net (anholt.net [50.246.234.109]) by gabe.freedesktop.org (Postfix) with ESMTP id 7C4AB6E964 for ; Wed, 21 Mar 2018 17:10:03 +0000 (UTC) In-Reply-To: <20180321112517.bxxfp663yexjuihn@flea> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Maxime Ripard , intel-gfx@lists.freedesktop.org Cc: Thomas Petazzoni , eben@raspberrypi.org List-Id: intel-gfx@lists.freedesktop.org --===============0815309261== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable 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. >>=20 >> 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. >>=20 >> * 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. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE/JuuFDWp9/ZkuCBXtdYpNtH8nugFAlqykekACgkQtdYpNtH8 nujw+A/8DGtfLv2Nhnt5fjKs5I+R6kjHioaM9evLe6BMLY6T61GwoXN6aa7RTbQt Rd3YwD9yWblVxnPH3o9FAENPds0NCdxGx4tWfwXxwmRR9Ro6P2EmBF5y6gUgnfdk rS59V/SnA4RbAm+x7ERNIlQnXjvzk3XzqDGZ6PwPgwQPkrly6BbiNJ8CaaeZh816 pLs0jofZQDK2Ui8Erxm9fw3iKuQFf1JFwPfO+ljA+2Sv47Ba2pmffzq9pgwv2olF jtwCmypeAVD8fSdinHsaqemMJdTtXHEbCVvHEw2ju8qxcq305PDWCiq9Ju+Lh2uI 057WpumiO4/lLDcY/SLlgb4Zx1APRrXhIkW7FcLNBu7gxiyjMjRoqxGxm1Cjg+x+ SSFjUqOL+QCnm2LhYoVqNGjgpbyqyyyqoZiAqk8yPbATl3zSmWaB+VvMbN0iN7fk 1tmKyYA5XtdaxsiE1qBSG+2krvnUtwNlE447RPZkIiIFn6EMTRz2Vmpoj7lXsqUv qbgqBSZIox3sdLmKxJPRKdUirarnp63frF9VeIF6GAwlSr43YmaX8cg6jwSKaD7d xweTUmxZRrWfY/ISYEDkDTnkZZGgcfoADMCqaZgBIOzF+oXs6TRXdnJvqYg3wpI3 FtjVCT4kDDLDZgXzau/zbMdzFMGCbqnH2dzlq+LPJwnHjywDYng= =G6+Y -----END PGP SIGNATURE----- --=-=-=-- --===============0815309261== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KSW50ZWwtZ2Z4 IG1haWxpbmcgbGlzdApJbnRlbC1nZnhAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vaW50ZWwtZ2Z4Cg== --===============0815309261==--