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@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).

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.

Nicolas

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.