[Linaro-mm-sig] [RFC v3] dma-buf: Add buffer sharing framework
sumit.semwal at linaro.org
Tue Oct 11 05:46:24 UTC 2011
On 11 October 2011 01:45, Daniel Vetter <daniel at ffwll.ch> wrote:
> On Mon, Oct 10, 2011 at 10:06:09PM +0530, Sumit Semwal wrote:
> > On 10 October 2011 02:13, Clark, Rob <rob at ti.com> wrote:
> > > hmm, random though..
> > >
> > > should we define CPU_PREP/CPU_FINI type ioctl's?
> > >
> > > At least in the GStreamer case, we could cache the userspace mmap'ing,
> > > and use the extra ioctls so the kernel side would know when cache
> > > clean/invalidate is needed. That would be a bit more efficient than
> > > forcing userspace to map/unmap all the time, and could hook into
> > > sync-objects of the allocator in cases where you have CPU access after
> > > GPU renders to a buffer..
> > >
> > So, you think we could post the RFC to upstream lists without this,
> > mentioning it as the immediate next TODO item? Or is it essential to add
> > for v1 of RFC?
> I think th "That would be a bit more efficient than ..." is a dead
> giveaway: Imo performance optimisation for future extensions ;-)
> Otherwise I'm pretty satisfied with what the patch currently looks like
> now. I think the next step is to proof-of-concept actual use-cases. I'm
> hoping to be able to help there by porting Dave Airlie's PRIME drm buffer
> sharing work onto this (the necessary hw is already here to make something
> work on i915). But I can't promise much, unfortunately - too much other
> stuff going on.
Thanks Rob and Daniel,
I would then post out the RFC to the upstream lists today. [I would post to
linux-arm-kernel, linux-kernel, linux-mm, dri-devel, linux-media. Any other
lists that should be part of this post you reckon?
> Yours, Daniel
> Daniel Vetter
> Mail: daniel at ffwll.ch
> Mobile: +41 (0)79 365 57 48
Thanks and regards,
Linaro Kernel Engineer - Graphics working group
Linaro.org <http://www.linaro.org/>* **│ *Open source software for ARM SoCs*
Follow *Linaro: *Facebook <http://www.facebook.com/pages/Linaro> |
| Blog <http://www.linaro.org/linaro-blog/>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Linaro-mm-sig