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....@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-ow...@vger.kernel.org [mailto:linux-media- > > ow...@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-me...@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 <hverk...@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 majord...@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 majord...@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 >
_______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
