Unix Device Memory Allocation project

[Marek Olšák]

On Oct 19, 2016 8:24 AM, "Daniel Vetter" <daniel at ffwll.ch> wrote:
>
> On Wed, Oct 19, 2016 at 1:40 AM, Marek Olšák <maraeo at gmail.com> wrote:
> > - The producer-consumer interop API doesn't know about the metadata.
> > All you need to pass around is a buffer handle. (KMS, DMABUF, etc.)
> >   * There was a note during the talk that DMABUF doesn't have any
> > metadata. Well, I just told you that it has, but it's private to
> > amdgpu and possibly accessible to other kernel drivers too.
> >   * We can build upon this idea. I think the worst thing to do would
> > be to add metadata handling to driver-agnostic userspace APIs. Really,
> > driver-agnostic APIs shouldn't know about that, because they can't
> > understand all the hw-specific information encoded in the metadata.
> > Also, when you want to change the metadata format, you only have to
> > update the affected drivers, not userspace APIs.
>
> That's a bit a surprise to hear, since "can't we just add a bit of
> opaque metadata to dma-buf" came up all the time over the past years,
> and died all the time again. dma-buf shouldn't imo be just yet another
> linux IPC mechanism and protocol, which is pretty much what you end up
> doing when you add this stuff. DRM runs all kinds of compositors with
> all kinds of existing userspace proto, and with reasonable ones like
> Wayland vendors can add whatever extensions they want. Plus there's
> all the interop with v4l and every other kernel subsytem. Trying to
> standardize that into some blob that works for everyone is imo nigh
> impossible.
>
> On top of that dma-buf is the wrong thing - you don't want this on
> buffers, but on surfaces. At least when it's time to reallocate. And
> oh dear I have seen what happens when soc vendors extend this design
> to cover that use-case, plus dynamic reallocation and all that. Imo
> there should be no way at all this ever comes close to dma-buf itself.
>
> And tbh I think it's a bit silly that amd snuck this in through
> amdgpu. But as long as you don't expect this to spread I guess it'll
> be fine.

LOL. It's not per DMABUF, it's per buffer, so you need a KMS handle to
access it from userspace.

We've had per buffer metadata in Radeon since KMS, which I believe first
appeared in 2009. It's 4 bytes large and is used to communicate tiling
flags between Mesa, DDX, and the kernel display code. It was a widely
accepted solution back then and Red Hat was the main developer. So yeah,
pretty much all people except Intel were collaborating on "sneaking" this
in in 2009. I think radeon driver developers deserve an apology for that
language.

Amdgpu extended that metadata to 8 bytes and it's used in the same way as
radeon. Additionally, amdgpu added opaque metadata having 256 bytes for use
by userspace drivers only. The kernel driver isn't supposed to read it or
parse it. The format is negotiated between userspace driver developers for
sharing of more complex allocations than 2D displayable surfaces.

Marek


> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161019/f4e50c12/attachment-0001.html>