Requirements to merge new heaps in the kernel

[Maxime Ripard]

On Tue, Oct 22, 2024 at 01:58:47PM -0400, Nicolas Dufresne wrote:
> Hi,
> 
> Le mardi 22 octobre 2024 à 09:19 -0700, John Stultz a écrit :
> > On Tue, Oct 22, 2024 at 1:38 AM Maxime Ripard <mripard at redhat.com> wrote:
> > > 
> > > I wanted to follow-up on the discussion we had at Plumbers with John and
> > > T.J. about (among other things) adding new heaps to the kernel.
> > > 
> > > I'm still interested in merging a carve-out driver[1], since it seems to be
> > > in every vendor BSP and got asked again last week.
> > > 
> > > I remember from our discussion that for new heap types to be merged, we
> > > needed a kernel use-case. Looking back, I'm not entirely sure how one
> > > can provide that given that heaps are essentially facilities for
> > > user-space.
> > > 
> > > Am I misremembering or missing something? What are the requirements for
> > > you to consider adding a new heap driver?
> > 
> > It's basically the same as the DRM subsystem rules.
> > https://docs.kernel.org/gpu/drm-uapi.html#open-source-userspace-requirements
> > ie: There has to be opensource user for it, and the user has to be
> > more significant than a "toy" implementation (which can be a bit
> > subjective and contentious when trying to get out of a chicken and egg
> > loop).
> 
> If there is a generic logic to decide to use a carve-out when using some
> specific device on specific platform, it would not be a problem to make
> userspace for it. I'm happy to take DMABuf patches in GStreamer notably (which
> could greatly help ensuring zero-copy path).

Yeah, that's one of the things we discussed at Plumbers too. My
point-of-view was that userspace also had no way to tell which kind of
buffers it would get. We settled down on the heap name providing those
semantics, and it resulted in:

https://lore.kernel.org/r/20240930144057.453751-1-mripard@kernel.org

> But so far, all the proposals was just a base allocator, no way to know when to
> use it and for which device. The actual mapping of heaps and device was left to
> userspace, which to be honest would only work with a userspace Linux Allocator
> library, with userspace drivers, or inside mesa if the devices are GPUs/NPUs.
> This is a project Laurent Pinchard have hosted a workshop about during XDC.

Yeah, that's another issue that needs to be tackled at some point indeed.

> p.s. libcamera have device specific knowledge, and could of course be a shorter
> term user. Note that major distro are not happy that there is no memory
> accounting for dmabuf, bypassing sandboxes and limits.

Meh. The same argument could be said for v4l2 or DRM/KMS, and it never
bothered anyone.

Fortunately, we're tackling that issue as well:
https://lore.kernel.org/dri-devel/20241023075302.27194-1-maarten.lankhorst@linux.intel.com/

Maxime
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 273 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20241024/65f49f0d/attachment.sig>