Am Freitag, den 30.11.2012, 09:44 +0200 schrieb Terje Bergström: > On 29.11.2012 14:14, Thierry Reding wrote: > > On Thu, Nov 29, 2012 at 10:09:13AM +0100, Lucas Stach wrote: > >> This way you would also be able to construct different handles (like GEM > >> obj or V4L2 buffers) from the same backing nvhost object. Note that I'm > >> not sure how useful this would be, but it seems like a reasonable design > >> to me being able to do so. > > > > Wouldn't that be useful for sharing buffers between DRM and V4L2 using > > dma-buf? I'm not very familiar with how exactly importing and exporting > > work with dma-buf, so maybe I need to read up some more. > > I would still preserve the dma-buf support, for exactly this purpose. > dma-buf is useful and should be preserved, as some userspace like gstreamer might rely on us being able to import/export dma-buf handles at some time. At the very latest we'll need it if someone wants to run a UDL device to scanout a buffer rendered to by the internal GPU. What I'm saying is just that with a common allocator we could cut down a lot on the usage of dma-buf, where not really necessary. Also you might be able to do some optimisations based on the fact that a dma-buf handle exported for some V4L2 buffer, which gets imported into DRM to construct a GEM object, is the very same nvhost object in the end. Regards, Lucas _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
