On Wed, Oct 19, 2016 at 4:10 PM, Daniel Vetter <daniel@xxxxxxxx> wrote: > On Wed, Oct 19, 2016 at 03:15:08PM +0200, Marek Olšák wrote: >> On Oct 19, 2016 8:24 AM, "Daniel Vetter" <daniel@xxxxxxxx> wrote: >> > 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. >> >> LOL. It's not per DMABUF, it's per buffer, so you need a KMS handle to >> access it from userspace. > > Seems to be on gem buffers, not any KMS object (like framebuffers). For > cross driver that corresponds to dma-buf, and the discussion here is about > cross-driver/vendor buffer sharing. > >> 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. > > Metadata needed for kms (what Christian also pointed out) is what everyone > did (intel included) and I think that's perfectly reasonable. And I was > aware of that radeon is doing that since the dawn of ages since forever. > > What I think is not really ok is opaque metadata blobs that the kernel > never ever inspect, but just carries around. That essentially means you're > reimplementing some bad form of IPC, and I dont think that's something the > drm subsystem (or dma-buf) really should be doing. Because you still have > that real protocol in userspace (dri2/3, wayland, whatever), but now with > a side channel with no documented ordering and synchronization. It gets > the job done for single-vendor buffer metadata transport, but as soon as > there's more than one vendor, or as soon as you need to reallocate buffers > dynamically because the usage changes it gets bad imo (and I've seen what The metadata is immutable after allocation, so it's not a communication channel. There is no synchronization or ordering needed for immutable metadata. That implies that a shared buffer can't be reused for an entirely different purpose. It can only be used as-is or freed. For suballocated memory, the idea is to reallocate it as a separate buffer on the first "handle" export, so that shared suballocated buffers don't exist. > that looks like on android in various forms). And that consensus (at least > among folks involved in dma-buf) goes back to the dma-buf kickoff 3-day > meeting we've had over 5 years ago. Not sure we're gaining anything with a > "who's older" competition. > > Anyways it's there and it's uabi so will never disappear. Just wanted to > make sure it's clear that for dma-buf we've discussed this years ago, and > decided it wasn't a great idea. And I think that's still correct. The arguments against blob metadata sound reasonable to me. I'm pretty sceptic that window system protocols will make driver-specific metadata blobs redundant anytime soon though. It seems the protocols don't get much attention nowadays and there is no incentive to do things differently in that area. At least that's how it appears to me, but I'm not involved in that. Marek _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
