On 04/20/2011 06:23 AM, Tom Cooksey wrote:
-----Original Message----- From: linaro-mm-sig-bounces@lists.linaro.org [mailto:linaro-mm-sig- bounces@lists.linaro.org] On Behalf Of Daniel Vetter Sent: 20 April 2011 07:56 To: Arnd Bergmann Cc: linaro-mm-sig@lists.linaro.org Subject: Re: [Linaro-mm-sig] Memory Management Discussion
On Wed, Apr 20, 2011 at 8:25 AM, Arnd Bergmannarnd@arndb.de wrote:
On Wednesday 20 April 2011 03:52:53 Clark, Rob wrote:
From DRI perspective.. I guess the global buffer name is restricted to a 4 byte integer, unless you change the DRI proto..
I still like the idea of using file handles to pass the buffers between kernel subsystems. Maybe there could be an ioctl to encapsulate a buffer from DRI in a file so we can give it to another subsystem, and/or an ioctl to register a buffer from a file handle with DRI.
That's been the original design of gem, i.e. using fd handles (and perhaps even passing them around in unix domain sockets). There's one small problem with that approach: You're quickly running out of fds with the linux default limit of 1024. Hence the roll-your-own approach.
There's a big difference between GEM and what we're trying to do. GEM is designed to manage _all_ buffers used by the graphics hardware. What I believe we're trying to do is only provide a manager which allows buffers to be shared between devices. Of all the buffers and textures a GPU needs to access, only a tiny fraction of them need to be shared between devices and userspace processes. How large that fraction is I don't know, it might still be approaching the 1024 limit, but I doubt it...
I don't think that is an accurate characterization.
Sharing *is* important, but at least this vendor is looking for a way to allocate all multimedia related buffers, shared or not. Even if you never shared a single buffer between processes everything else we've put on the table re memory management is still a concern: cache policy, contiguous vs paged, IOMMU, etc, etc. I'm in the market for one memory manager to rule them all.
Jordan