On Fri, May 21, 2010 at 11:22 AM, Ohad Ben-Cohen <o...@wizery.com> wrote: > On Fri, May 21, 2010 at 9:14 AM, Felipe Contreras > <felipe.contre...@gmail.com> wrote: >> On Fri, May 21, 2010 at 12:22 AM, Ohad Ben-Cohen <o...@wizery.com> wrote: >>> On Wed, May 19, 2010 at 7:50 PM, Felipe Contreras >>> <felipe.contre...@gmail.com> wrote: >>>> I don't know what VM_IO means, but essentially we don't want to go >>>> find each and page when we know the memory is contiguous. Although the >>>> fact that the memory is writecombine would help us avoid unnecessary >>>> flushes as well :) >>> >>> Yes, I guess you can remove those calls from the application :) >> >> Can't. From GStreamer point of view the decoder is independent of the >> renderer, so we have no way to know that. > > Can you please elaborate on this a little ?
GStreamer has a plug-in architecture. So one plug-in (libgstdsp.so) issues a request for a zero-copy buffer (gst_pad_alloc_buffer()) to the next element in the chain. We don't know who that is, nor care, and there might be elements in the middle that pass the buffer along. The memory could be part of the framebuffer, or randomly allocated by user-space. One element (omapxvimagesink) might always return memory from omapfb, another one (omapfbsink), might allocate a separate buffer if all the omapfb memory is being used currently. In the end, the decoder element has no idea about that. Just the GstBuffer which has a data pointer, and a size, and that's it. There are even more complicated use-cases like video recording directly on the framebuffer. Other pluggable MM frameworks like OpenMAX IL would have similar problems. >> Perhaps if the memory map >> operation returned some information we can avoid those calls. > > I don't think it should; relying on the map call to tell us what type > of buffer we just gave it smells like a bad interface. After all, it > is the application who originally called mmap() to get access to that > buffer, so it already knows if it's a framebuffer of not. Well, requesting DMA operations from user-space is already bad interface. It's the job of the driver to do that. Due to bad design of the driver we'll have to do them, but if there's a way to know if such operations are redundant or not, it would have to be returned through map call, otherwise we'll be wasting ioctl calls. > Anyway it's not that an important optimization to do: the ioctl will > just fail. The negative side is that the application will have no way > to know if this is really a failure (did I just give a wrong buffer > address to dspbridge ?) or not (oh it's the framebuffer, there's no > mapping for that). Exactly; we will not know when operations fail. But also, ioctl() calls would be wasted. > Performance-wise, it's better than the previous implementation which > would have executed redundant cache operation on the buffer. Indeed. Although I'm still worried that VM_IO != write-combine, but I guess it's a safe assumption to do for now. Cheers. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
