On Wed, Oct 19, 2016 at 2:08 AM, James Jones <jajones@xxxxxxxxxx> wrote: >> * 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. > > How does this kernel-side metadata interact with userspace driver > suballocation, or application-managed suballocation in APIs such as Vulkan? Perfect point for why the kernel (well dma-buf) imo really shouldn't be in the business of handling the metadata. With explicit fencing (on android) suballocation makes perfect sense also for shared buffer, and then boom. So yes, we either need protocol-extension support for vendors like on Wayland, or backshoehorn it into existing stuff like dri3, but that where it needs to be. And given that part of the reasons for this is to allow cross-vendor interop the benefit of having something vendor specific like these amgpu metadata blobs is out of the window anyway. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
