Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Tue, 29 Nov 2022 12:48:59 +0200
From:   Pekka Paalanen <ppaalanen@gmail.com>
To:     Hsia-Jun Li <randy.li@synaptics.com>
Cc:     dri-devel@lists.freedesktop.org, linux-media@vger.kernel.org,
        hverkuil@xs4all.nl, tfiga@chromium.org, nicolas@ndufresne.ca,
        maarten.lankhorst@linux.intel.com, mripard@kernel.org,
        tzimmermann@suse.de, airlied@gmail.com, daniel@ffwll.ch,
        linux-kernel@vger.kernel.org, ayaka@soulik.info
Subject: Re: [RFC] drm/fourcc: Add a modifier for contiguous memory
Message-ID: <20221129124859.6aa3ff00@eldfell>
In-Reply-To: <20221129101030.57499-1-randy.li@synaptics.com>
References: <20221129101030.57499-1-randy.li@synaptics.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="Sig_/CjiU_jGWnjlPQD5JQ_UkV.O";
 protocol="application/pgp-signature"; micalg=pgp-sha256
Precedence: bulk

--Sig_/CjiU_jGWnjlPQD5JQ_UkV.O
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

On Tue, 29 Nov 2022 18:10:30 +0800
Hsia-Jun Li <randy.li@synaptics.com> wrote:

> From: "Hsia-Jun(Randy) Li" <randy.li@synaptics.com>
>=20
> Hello All
>=20
> Currently, we assume all the pixel formats are multiple planes,

Hi,

that's not true for any definition of "multiple planes" that I know of.

For example, DRM_FORMAT_XRGB8888 is a single-plane format by definition.

=46rom below it sounds like you mean "physically non-contiguous". But no,
pixel formats make no such assumption at all. Contiguous or not is
independent of pixel formats.

> devices
> could support each component has its own memory plane.
> But that may not apply for any device in the world. We could have a
> device without IOMMU then this is not impossible.
>=20
> Besides, when we export an handle through the PRIME, the upstream
> device(likes a capture card or camera) may not support non-contiguous
> memory. It would be better to allocate the handle in contiguous memory
> at the first time.
>=20
> We may think the memory allocation is done in user space, we could do
> the trick there. But the dumb_create() sometimes is not the right API
> for that.
>=20
> "Note that userspace is not allowed to use such objects for render
> acceleration - drivers must create their own private ioctls for such a
> use case."
> "Note that dumb objects may not be used for gpu acceleration, as has
> been attempted on some ARM embedded platforms. Such drivers really must
> have a hardware-specific ioctl to allocate suitable buffer objects."
>=20
> We need to relay on those device custom APIs then. It would be helpful
> for their library to calculate the right size for contiguous memory. It
> would be useful for the driver supports rendering dumb buffer as well.
>=20
> Signed-off-by: Hsia-Jun(Randy) Li <randy.li@synaptics.com>
> ---
>  include/uapi/drm/drm_fourcc.h | 5 +++++
>  1 file changed, 5 insertions(+)
>=20
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index bc056f2d537d..ec039ced8257 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -473,6 +473,11 @@ extern "C" {
>   */
>  #define DRM_FORMAT_MOD_LINEAR	fourcc_mod_code(NONE, 0)
> =20
> +/*
> + * Contiguous memory
> + */
> +#define DRM_FORMAT_MOD_CONTIG_MEM	fourcc_mod_code(NONE, 1)

NAK. This is not what modifiers are for.

This also would not work in practise, because if this was a modifier,
you would not be able to use the actual modifiers.


Thanks,
pq

> +
>  /*
>   * Deprecated: use DRM_FORMAT_MOD_LINEAR instead
>   *


--Sig_/CjiU_jGWnjlPQD5JQ_UkV.O
Content-Type: application/pgp-signature
Content-Description: OpenPGP digital signature

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEJQjwWQChkWOYOIONI1/ltBGqqqcFAmOF45sACgkQI1/ltBGq
qqcRPQ//TKyVghVjJvbngGkpqrp0wLr2vTN2hZZNRZ+2ZW7siUbaHrDk7D88M4S5
oLOBZRm6RSgiarBfHpOIJ9xIbmjM+QbxzGeJeU2a0OgMYc9zMkfi3ohLmOjARq8u
4EZUGCEDUxUKmA1Z8mBTePUHJ1aEPeEqxIv3oy6ewNFHEzP2h9G4G8s09eFvBlzo
K8bdZuuVrsssxt+1jN1pQpVGCOXNVewyT2kwDjR5ZEBfEn4sxDiiB2cYpBBOqx5A
xymiID7dF8qvilEWUfYrJZJAKyJ372z3PozQ18pHOezEoiN+fRJoJRRuUt0r3nWh
QGZskfdWSWBKAZ5AFzmdb2dBpXX78M7KmmcjMVgTeM7ML81SCx5Sb2gHkXTctJYA
Aujwu+q++Q+nZlNCaOMV3C7eCEnSiIERaPV518Hm4Po3WU3qSRM1Wat3bTSA9R3E
FIwq+PRb7tM4BwsyQefdg8pVOsZ45yfSHNdQft1dKLVfIIm7pE2F4C5mc+i8lynr
IaGxWGXmUPVop2kUBW+cfBRu1qzvg9SGQEmuwfeNkfeAr8e1tWlcHTERuAn/LQGT
SgvogKeSqufFArePHMxM6ajE+sIXZOJlD7Tc1RisQrNkzre3Hr6L5xN7OE5jlfg2
wKhgc8n5o4C4gT6cK5XMuDm81aFV0wrMtT6t0jOeyA+qNaGvdHE=
=QEkC
-----END PGP SIGNATURE-----

--Sig_/CjiU_jGWnjlPQD5JQ_UkV.O--