From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tomi Valkeinen Subject: Re: [PATCH 02/23] drm: omapdrm: fb: Don't store format BPP for each plane Date: Tue, 10 May 2016 10:34:40 +0300 Message-ID: <57318F10.70407@ti.com> References: <1461702945-14185-1-git-send-email-laurent.pinchart@ideasonboard.com> <1461702945-14185-3-git-send-email-laurent.pinchart@ideasonboard.com> <57277593.10303@ti.com> <2039595.vnu1mErabq@avalon> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0661131366==" Return-path: Received: from devils.ext.ti.com (devils.ext.ti.com [198.47.26.153]) by gabe.freedesktop.org (Postfix) with ESMTPS id 0CF506E584 for ; Tue, 10 May 2016 07:34:46 +0000 (UTC) In-Reply-To: <2039595.vnu1mErabq@avalon> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Laurent Pinchart Cc: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org --===============0661131366== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="emBxXTRcExoEmRpofinEt6IRV5DuaTdU0" --emBxXTRcExoEmRpofinEt6IRV5DuaTdU0 Content-Type: multipart/mixed; boundary="xbJuDjnW2Uvl1bPaTNmAwUriHogupE3vB" From: Tomi Valkeinen To: Laurent Pinchart Cc: dri-devel@lists.freedesktop.org, Rob Clark Message-ID: <57318F10.70407@ti.com> Subject: Re: [PATCH 02/23] drm: omapdrm: fb: Don't store format BPP for each plane References: <1461702945-14185-1-git-send-email-laurent.pinchart@ideasonboard.com> <1461702945-14185-3-git-send-email-laurent.pinchart@ideasonboard.com> <57277593.10303@ti.com> <2039595.vnu1mErabq@avalon> In-Reply-To: <2039595.vnu1mErabq@avalon> --xbJuDjnW2Uvl1bPaTNmAwUriHogupE3vB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 09/05/16 23:55, Laurent Pinchart wrote: >> To be honest, I'd rather go into more complex struct than simpler one.= >> The current one is already confusing, I think, and your version is too= =2E >> The main issue is that the sub_x is encoded into the stride_bpp. In >> kmsxx I used this format: >> >> { PixelFormat::NV12, { 2, { { 8, 1, 1, }, { 8, 2, 2 } }, } }, >> >> The first number is the number of planes, and for each plane, bitspp, >> xsub and ysub. It's more verbose, but (I think) easier to understand. >=20 > I'm fine with that assuming we'd have a use for it :-) Shouldn't we aim= for a=20 > simpler structure to save memory by only storing the information we nee= d,=20 > compared to a more verbose structure that duplicates information or sto= res=20 > data that we don't need ? Well, my take is: if we save a few bytes by obfuscating the code, it's not worth it. "Obfuscating" is, of course, relative, but a "stride_bpp" is confusing to me. If it's a common term, I'm fine with using it and I just need to learn it =3D). Also, I like tables like these to be somewhat generic, so that if and when we get new color formats, the whole table doesn't need to be rewritt= en. That said, the kmsxx format above is not super clear either, as the bitspp for the second plane is 8, i.e. it also has the sub_x encoded... I don't remember why I made it like that. So, in the end, all I know is that describing pixel formats well is not easy =3D). Tomi --xbJuDjnW2Uvl1bPaTNmAwUriHogupE3vB-- --emBxXTRcExoEmRpofinEt6IRV5DuaTdU0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXMY8QAAoJEPo9qoy8lh71EecQAIilh52gflUs3ZAZ27kBeB7G se0rVJm/uVRRGT2pZajTRhlbfpefS3vXQhMQN6ct2Sb8yoThUwqKYnYZ4HM1v5o2 YtVag/YJENvomHolQK2p9xOHPvqSAqHVaGiY+Ts9k1Zmh+lFVbl3v9bh+xxweuQD cXbGj+TTtxByYsvgGJKVHbsIHOTt3eZWAi2sq57veK+DsUXpqP8+vvQWtljRGD69 DUUVBZksh6mYBSG6CJxp26K3eOAajUHkFHXk+cf0RGRRwCE63KbWq1/aE1y669lF s3t8zFklWrftRRSJOauJUkFbh78mqfJUR/tvP871iXdyHeorlT/MpgV5I1ldOoBL OeiDa7iUmzmZwUsODKeyJtEAALdpZtFrxq7BH51GVywHzJ3U8uqLc/cAS5vY5peK yvnyxeKJEIXXp+Uqo3VFD6Jy/VYNP99xZivBvIvnAiDjRzyg358yqYF1NxYWVgET /uwXAfz8GEPaq5Gk9mGIRrwdkpaRy7biKz+fiJ1n/ykpHnCF9eyw9fvLcOfwmpRk WjJbQRBpkZCQBhujA1gm1X64SfOViv7qwYhnCazgfketL35+/FgWVYA9Mv93x39r W0pLqhAiQ73mAR1PDXcMsHOTysdeTScBawdu2GRNt7uf35/77UDcvy6tBvng20Cn DJ0PvJ3D7GQ6oOJX3EWg =rXcz -----END PGP SIGNATURE----- --emBxXTRcExoEmRpofinEt6IRV5DuaTdU0-- --===============0661131366== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== --===============0661131366==--