From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: nicolas.dufresne@collabora.corp-partner.google.com
Cc: "Maxime Ripard" <mripard@redhat.com>,
"Bryan O'Donoghue" <bryan.odonoghue@linaro.org>,
"Dmitry Baryshkov" <dmitry.baryshkov@linaro.org>,
"Hans de Goede" <hdegoede@redhat.com>,
"Sumit Semwal" <sumit.semwal@linaro.org>,
"Benjamin Gaignard" <benjamin.gaignard@collabora.com>,
"Brian Starkey" <Brian.Starkey@arm.com>,
"John Stultz" <jstultz@google.com>,
"T.J. Mercier" <tjmercier@google.com>,
"Christian König" <christian.koenig@amd.com>,
"Lennart Poettering" <mzxreary@0pointer.de>,
"Robert Mader" <robert.mader@collabora.com>,
"Sebastien Bacher" <sebastien.bacher@canonical.com>,
"Linux Media Mailing List" <linux-media@vger.kernel.org>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
linaro-mm-sig@lists.linaro.org,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
"Milan Zamazal" <mzamazal@redhat.com>,
"Andrey Konovalov" <andrey.konovalov.ynk@gmail.com>
Subject: Re: Safety of opening up /dev/dma_heap/* to physically present users (udev uaccess tag) ?
Date: Thu, 16 May 2024 14:27:20 +0300 [thread overview]
Message-ID: <20240516112720.GA12714@pendragon.ideasonboard.com> (raw)
In-Reply-To: <a3428b0c352c24d43a2d458d41819fbf4b6cce0f.camel@collabora.corp-partner.google.com>
Hi Nicolas,
On Wed, May 15, 2024 at 01:43:58PM -0400, nicolas.dufresne@collabora.corp-partner.google.com wrote:
> Le mardi 14 mai 2024 à 23:42 +0300, Laurent Pinchart a écrit :
> > > You'll hit the same limitation as we hit in GStreamer, which is that KMS driver
> > > only offer allocation for render buffers and most of them are missing allocators
> > > for YUV buffers, even though they can import in these formats. (kms allocators,
> > > except dumb, which has other issues, are format aware).
> >
> > My experience on Arm platforms is that the KMS drivers offer allocation
> > for scanout buffers, not render buffers, and mostly using the dumb
> > allocator API. If the KMS device can scan out YUV natively, YUV buffer
> > allocation should be supported. Am I missing something here ?
>
> There is two APIs, Dumb is the legacy allocation API, only used by display
Is it legacy only ? I understand the dumb buffers API to be officially
supported, to allocate scanout buffers suitable for software rendering.
> drivers indeed, and the API does not include a pixel format or a modifier. The
> allocation of YUV buffer has been made through a small hack,
>
> bpp = number of bits per component (of luma plane if multiple planes)
> width = width
> height = height * X
>
> Where X will vary, "3 / 2" is used for 420 subsampling, "2" for 422 and "3" for
> 444. It is far from idea, requires deep knowledge of each formats in the
> application
I'm not sure I see that as an issue, but our experiences and uses cases
may vary :-)
> and cannot allocate each planes seperatly.
For semi-planar or planar formats, unless I'm mistaken, you can either
allocate a single buffer and use it with appropriate offsets when
constructing your framebuffer (with DRM_IOCTL_MODE_ADDFB2), or allocate
one buffer per plane.
> The second is to use the driver specific allocation API. This is then abstracted
> by GBM. This allows allocating render buffers with notably modifiers and/or use
> cases. But no support for YUV formats or multi-planar formats.
GBM is the way to go for render buffers indeed. It has been designed
with only graphics buffer management use cases in mind, so it's
unfortunately not an option as a generic allocator, at least in its
current form.
--
Regards,
Laurent Pinchart
next prev parent reply other threads:[~2024-05-16 11:27 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-06 11:49 Safety of opening up /dev/dma_heap/* to physically present users (udev uaccess tag) ? Hans de Goede
2024-05-06 12:05 ` Maxime Ripard
2024-05-06 12:11 ` Hans de Goede
2024-05-06 13:38 ` Daniel Vetter
2024-05-06 14:01 ` Hans de Goede
2024-05-07 11:15 ` Daniel Vetter
2024-05-08 5:46 ` Daniel Stone
2024-05-08 8:33 ` Daniel Vetter
2024-05-08 8:38 ` Daniel Stone
2024-05-08 15:49 ` Daniel Vetter
2024-05-09 9:23 ` Daniel Stone
2024-05-16 10:18 ` Daniel Vetter
2024-05-13 13:51 ` Simon Ser
2024-05-16 10:13 ` Daniel Vetter
2024-05-16 11:49 ` Christian König
2024-05-07 13:34 ` Dmitry Baryshkov
2024-05-07 18:59 ` Laurent Pinchart
2024-05-22 13:34 ` Maxime Ripard
2024-05-23 9:41 ` Daniel Vetter
2024-05-07 13:32 ` Dmitry Baryshkov
2024-05-07 14:34 ` Hans de Goede
2024-05-07 15:09 ` Dmitry Baryshkov
2024-05-07 15:15 ` Bryan O'Donoghue
2024-05-07 15:19 ` Dmitry Baryshkov
2024-05-07 18:40 ` Laurent Pinchart
2024-05-07 19:59 ` Dmitry Baryshkov
2024-05-07 20:15 ` Laurent Pinchart
2024-05-08 8:39 ` Daniel Vetter
2024-05-08 21:54 ` Laurent Pinchart
2024-05-13 8:39 ` Maxime Ripard
2024-05-07 17:36 ` Daniel Vetter
2024-05-07 18:36 ` Laurent Pinchart
2024-05-07 20:07 ` Nicolas Dufresne
2024-05-08 8:36 ` Daniel Vetter
2024-05-08 21:51 ` Laurent Pinchart
2024-05-08 21:52 ` Laurent Pinchart
2024-05-13 8:29 ` Maxime Ripard
2024-05-13 8:34 ` Laurent Pinchart
2024-05-13 15:10 ` Nicolas Dufresne
2024-05-14 20:42 ` Laurent Pinchart
2024-05-15 17:43 ` nicolas.dufresne
2024-05-16 11:27 ` Laurent Pinchart [this message]
2024-05-16 17:11 ` nicolas.dufresne
2024-05-21 8:43 ` Maxime Ripard
2024-05-21 14:18 ` nicolas.dufresne
2024-05-16 7:00 ` Simon Ser
2024-05-16 11:20 ` Laurent Pinchart
2024-05-22 13:02 ` Nicolas Dufresne
2024-05-13 13:42 ` Nicolas Dufresne
2024-05-13 13:51 ` Maxime Ripard
2024-05-13 15:06 ` Nicolas Dufresne
2024-05-14 20:45 ` Laurent Pinchart
2024-05-14 20:52 ` Nicolas Dufresne
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240516112720.GA12714@pendragon.ideasonboard.com \
--to=laurent.pinchart@ideasonboard.com \
--cc=Brian.Starkey@arm.com \
--cc=andrey.konovalov.ynk@gmail.com \
--cc=benjamin.gaignard@collabora.com \
--cc=bryan.odonoghue@linaro.org \
--cc=christian.koenig@amd.com \
--cc=dmitry.baryshkov@linaro.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=hdegoede@redhat.com \
--cc=jstultz@google.com \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mripard@redhat.com \
--cc=mzamazal@redhat.com \
--cc=mzxreary@0pointer.de \
--cc=nicolas.dufresne@collabora.corp-partner.google.com \
--cc=robert.mader@collabora.com \
--cc=sebastien.bacher@canonical.com \
--cc=sumit.semwal@linaro.org \
--cc=tjmercier@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).