Hi,
 
hwmem basically use the same concept of handle (or SecureID).
 
The problem with this approach is that the middleware must be aware of this handle and must provide a way to forward it between elements/component and upper level. Today isn't the case in GStreamer (maybe in 1.0 it will), EGL, X ... the list isn't complete.

Does one solution natively provide a way to not use a handle and to only get a virtual address to manage in middleware?
 
While talking with hwmem owners, I came to the idea that a solution could be to reserve, overs all process, a range of virtual address where only hwmem could mmap physical buffers so the virtual address of the buffer could become the "handle" of the underline buffer. 
 
Benjamin
 
2011/3/8 Jonghun Han <jonghun.han@samsung.com>

Thanks for interesting.

As I know, the purpose of UMP is the buffer sharing especially inter-process
.
Maybe ARM can explain it more detail.

High resolution video/image processing requires zero-copy operation.
UMP allows zero-copy operation using system unique key, named SecureID.
UMP supports memory allocation. (custom memory allocator can be used.)
It gives a SecureID for each buffer during allocation.
And user virtual address for each process can be made by SecureID.
Application can access the buffer using its own virtual address made by
SecureID.
So application can share the buffer without copy operation.

For example, video playback application can share the buffer even though it
consists of multiple process.

Best regards,
Jonghun Han

> -----Original Message-----
> From: linux-media-owner@vger.kernel.org [mailto:linux-media-
> owner@vger.kernel.org] On Behalf Of Kyungmin Park
> Sent: Tuesday, March 08, 2011 8:06 PM
> To: Hans Verkuil
> Cc: linaro-dev@lists.linaro.org; linux-media@vger.kernel.org; Jonghun Han
> Subject: Re: Yet another memory provider: can linaro organize a meeting?
>
> Dear Jonghun,
>
> It's also helpful to explain what's the original purpose of UMP (for GPU,
> MALI) and what's the goal of UMP usage for multimedia stack.
> Especially, what's the final goal of UMP from LSI.
>
> Also consider the previous GPU memory management program, e.g., SGX.
>
> Thank you,
> Kyungmin Park
>
> On Tue, Mar 8, 2011 at 5:13 PM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
> > Hi all,
> >
> > We had a discussion yesterday regarding ways in which linaro can
> > assist
> > V4L2 development. One topic was that of sorting out memory providers
> > like GEM and HWMEM.
> >
> > Today I learned of yet another one: UMP from ARM.
> >
> > http://blogs.arm.com/multimedia/249-making-the-mali-gpu-device-driver-
> > open-source/page__cid__133__show__newcomment/
> >
> > This is getting out of hand. I think that organizing a meeting to
> > solve this mess should be on the top of the list. Companies keep on
> > solving the same problem time and again and since none of it enters
> > the mainline kernel any driver using it is also impossible to upstream.
> >
> > All these memory-related modules have the same purpose: make it
> > possible to allocate/reserve large amounts of memory and share it
> > between different subsystems (primarily framebuffer, GPU and V4L).
> >
> > It really shouldn't be that hard to get everyone involved together and
> > settle on a single solution (either based on an existing proposal or
> > create a 'the best of' vendor-neutral solution).
> >
> > I am currently aware of the following solutions floating around the
> > net that all solve different parts of the problem:
> >
> > In the kernel: GEM and TTM.
> > Out-of-tree: HWMEM, UMP, CMA, VCM, CMEM, PMEM.
> >
> > I'm sure that last list is incomplete.
> >
> > Regards,
> >
> >        Hans
> >
> > --
> > Hans Verkuil - video4linux developer - sponsored by Cisco
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-media"
> > in the body of a message to majordomo@vger.kernel.org More majordomo
> > info at  http://vger.kernel.org/majordomo-info.html
> >
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
the
> body of a message to majordomo@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html


_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev