From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alyssa Rosenzweig Subject: Re: [PATCH v2] drm/fourcc: add ARM GPU tile format Date: Mon, 11 Mar 2019 09:39:28 -0700 Message-ID: <20190311163928.GA1412@kevin> References: <20190309140902.9871-1-yuq825@gmail.com> <20190311160009.GA11281@arm.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1553532331==" Return-path: In-Reply-To: <20190311160009.GA11281@arm.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Ayan Halder Cc: "lima@lists.freedesktop.org" , Maxime Ripard , "dri-devel@lists.freedesktop.org" , David Airlie , Qiang Yu , nd , Sean Paul List-Id: dri-devel@lists.freedesktop.org --===============1553532331== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="GvXjxJ+pjyke8COw" Content-Disposition: inline --GvXjxJ+pjyke8COw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > You might want to re-use the exisiting modifier > AFBC_FORMAT_MOD_BLOCK_SIZE_16x16. >=20 > I would suggest you to have a look at the exisiting AFBC modifiers > (denoted by AFBC_FORMAT_MOD_XXX ) and let us know if there is > something you cannot reuse. So, the "tiled" format in question (that Qiang needs to import/export BOs in) is *uncompressed* but tiled with an Arm-internal format (for the GPUs). Here's a software implementation for encoding this format: https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/panfrost/pa= n_swizzle.c For Midgard/Bifrost, we use this tiling internally for uploading bitmap textures, but we only render to AFBC (or linear). So for Panfrost, we'll always be importing/exporting AFBC buffers, never uncompressed tiled. But Utgard does not seem to support AFBC (?), so Qiang needs the uncompressed tiled for the same purpose Panfrost uses AFBC. Is it possible that this is the same tiling used internally by AFBC_FORMAT_MOD_BLOCK_SIZE_16x16, only without any compression? AFBC is blackbox for us, so this isn't something we can figure out ourselves, but that influences whether it's appropriate to reuse the modifier. If this is the same tiling scheme, perhaps that's the answer. If it's not (I don't know how AFBC tiling works), we probably do need a separate modifier to avoid confusion. Thanks, Alyssa --GvXjxJ+pjyke8COw Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEQ17gm7CvANAdqvY4/v5QWgr1WA0FAlyGjz8ACgkQ/v5QWgr1 WA1JHA/+MKO3rf6htnd48EVnXtEhsSqoDatDVb2c13k5/oxutrAQqR29K1Tl/Wkp 6HebJD4sBafutBroyGenIz5cLnY3AG3zy1zxzOgdvkXpNuVcXgtpL4HXjEaInueD ZtssXso4gjRZyD6kuW5fe97TvvRTPknEsMXpWwBgcgP+FxUrrwVqEPo6il3rhMvN E4NBHkqoX8GtLWB9p/YUcUWMHJ2YhEIo04Vi3tWw7t2TniHrJw7wZDVPXoKhoX9/ wsu0iZ4XEoL3FPtK1v/S6gWkDq0xDTzHeZOBJKYC94RiH93S+Q7maLzH5fTB9lXt DsF2zJkEj6tHZJCi0f0JzEcuXiAzZKKVLbKD1KoL6ORKZePRraJRzoTHFU1XknyR e9Uv3JuO2RwZxicfdgdArgzR9wrM2PL9kPzGsLtaYISQ6hs/vNbu2lgNPUzaX0Az xvMu/ZW9cbO+XKeilGoOYR8ON0Zyw9zmUSrnd5aRwwk07rvQElz7csFBGeH7QTg5 p5GTF5QcipZ6JpB3VSYxbJPJx2rEmg8/lTGUuWCB553sdbStPk/rKFAKszgqp6Cw 8AUktXmPv1Unwsnk46VF8WXJFtIldRjm8ErFRzbSDqyEO1kxPR+wH+6XBrS1iiYS 3Y7KoRUHLsQk6pk7q4RgVRYe2MCJe3jVeQNL1gZ6Qha3Dzbxymc= =Prus -----END PGP SIGNATURE----- --GvXjxJ+pjyke8COw-- --===============1553532331== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVs --===============1553532331==--