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@xxxxxxxxxxxxxxx [mailto:linux-media- > owner@xxxxxxxxxxxxxxx] On Behalf Of Kyungmin Park > Sent: Tuesday, March 08, 2011 8:06 PM > To: Hans Verkuil > Cc: linaro-dev@xxxxxxxxxxxxxxxx; linux-media@xxxxxxxxxxxxxxx; 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@xxxxxxxxx> 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@xxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
