Re: Unix Device Memory Allocation project

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Am 19.10.2016 um 08:23 schrieb Daniel Vetter:
On Wed, Oct 19, 2016 at 1:40 AM, Marek Olšák <maraeo@xxxxxxxxx> 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.

Actually we didn't started to do it like this with amdgpu. Radeon works exactly the same way.

Additional to that there is a really good reason to do it like this: The kernel needs this information to program the CRTC for scanning out tilled surfaces as well.

So you either end up with additions to the mode setting call to transport all the device specific information about the data layout in the buffer or you attach this information directly to your buffer handle.

We choose the later and I think that this is a rather nice solution compared to all the headache you run into pushing this information through all the different protocols and APIs (DRI2,DRI3,Wayland,Modeset).

Regards,
Christian.

-Daniel


_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux